PAM projects rarely get stuck on the technology. They get stuck on scope. Our approach: an MVP within 10 to 30 days, then iterative expansion based on what the organisation can handle.
A CIO drops by with an audit landing in six weeks. The auditor wants to know who has root access on the production servers, who runs the service accounts behind the payment integration and when someone last revoked a privilege. The answers are not in a system. They are in people’s heads, in an Excel file someone kept two years ago and in an SSH key still sitting on the laptop of an external who left in 2024.
This is the real starting point for most PAM projects we get involved in. Not a clean greenfield architecture, but an organisation that knows it cannot go on like this and wants to see results quickly without an 18-month project.
PAM projects rarely get stuck on the technology. They get stuck on scope. A traditional implementation tries to cover everything in one move: a vault for passwords, session recording, governance, just-in-time elevation, integration with SIEM, integration with IGA, integration with the service desk. The business case looks good on paper. After nine months there is a vault nobody works in yet and the project team is already exhausted halfway through the scope.
We see three patterns that cause this.
The first is that the organisation has no clear picture of which privileged accounts exist. The inventory is underestimated, turns out larger than expected halfway through, and the design is reworked. That costs weeks.
The second pattern is that the project is pulled apart from the existing IAM environment. A PAM product alongside Okta or alongside Active Directory produces two policy engines, two places where you revoke access and two sources the auditor has to look at. Operational debt instead of control.
The third pattern is excessive scope ambition. The wish to have session recording, vault, JIT and governance live in phase one, while the organisation does not even have a reliable list of admins yet.
Our approach to PAM follows the same line we use for Okta implementations and for automated provisioning. We work with an MVP that goes live within 10 to 30 days and then expands iteratively. That is not a marketing promise, that is how we have learned over 18 years that this type of project actually lands.
In concrete terms, that means the following.
We do not start with a tool, we start with data. Which server environments, which SaaS applications with admin roles, which service accounts, which shared accounts are actually in use? Often we discover accounts here that nobody knows anymore and that are still active. That is not a pleasant conversation, but it is the honest conversation that speeds up the project afterwards.
Most organisations have the most pain in one of these three places: Linux and Windows server management, SaaS service accounts or secrets and passwords for break-glass scenarios. Together with your security and operations team we choose the pillar where the ROI becomes visible fastest and the audit pressure is highest. The other pillars follow in later iterations.
If the organisation works with Okta, we connect Okta’s PAM solution (officially Okta Privileged Access) to the same policy engine that drives SSO and MFA. That saves a second management interface and ensures an offboarding through HR also revokes privileged access straight away. If you do not work with Okta, we assess which PAM vendor fits your IAM foundation best. We are an Okta Apex Partner and Okta Partner of the Year 2025 in the Benelux, so our experience runs deepest on that side, but we advise what fits.
After the first 30 days you have something that works: a defined group of admins who log in through a vaulted route, sessions that are recorded and a dashboard the CISO and the auditor can look into. From that point we expand. Just-in-time elevation, governance workflows, integration with access reviews, certification for service accounts. One at a time, with measurable outcomes.
Honestly: PAM is not a quick fix. What we do not do is promise in phase one that all 800 servers and all 60 SaaS apps are under management in one go. That is technically possible but organisationally unwise. People have to learn to work with a new login route. Administrators have to get used to session recording. Auditors have to learn where to pull the logs. Rolling out too fast leads to workarounds, and workarounds lead to exactly the shadow IT you were trying to solve.
We also do not do standalone PAM projects without context. If your IAM foundation is shaky, we fix that first. PAM on top of an unreliable source is an expensive way to give a wrong answer automatically.
At organisations that go through this approach you see a few recurring patterns in practice:
None of these outcomes is spectacular on its own. Together they are the difference between “we hope it is in order” and “we know it is in order, and we can show it”.
A PAM project always starts with us through a short conversation about what you have now and what is most urgent. No pre-filled scope, no standard quote. We want to know where the pain is, which audit is coming and which decisions have already been made about your IAM stack. From that conversation we work towards an MVP that delivers measurable results within 30 days, at the speed of business.