What is PAM (privileged access management)?

This is exactly the scenario privileged access management (PAM) exists for. And it is probably the reason you are reading this article.

The problem is not with the ordinary user

In most organisations, identity management for the average employee is reasonably in order by now. People log in through single sign-on, MFA is on, joiners-movers-leavers runs largely off HR data. IT Ops knows how it works and the CISO has a grip on it.

But then there are those other accounts. The domain administrator. The service account that runs the backup software. The local admin password on 800 workstations that is the same on all 800. The break-glass account for when everything is down. The external supplier who has to log in to the ERP every Monday morning to run a job.

Those accounts often fall outside the regular identity process. And those are exactly the accounts attackers are after. A phishing email that compromises an ordinary account is annoying. A phishing email that compromises a domain admin is a data breach.

Why the current approach falls short

Most organisations manage privileged accounts in three ways at once, and none of those ways works well.

The first layer is a password vault, often something like KeePass or a shared 1Password vault. Works fine for one person, breaks the moment four people need to use the same admin password at the same time. Rotating passwords rarely happens, because nobody knows which scripts depend on them.

The second layer is hoping it works out. Domain administrators get fixed accounts with permanent rights, because handing out and revoking temporary rights feels too cumbersome. Just-in-time access has been in every audit report since 2018, but in practice four people log in every day as enterprise admin because it is simply convenient.

The third layer is hoping that logging works. On paper, Active Directory records who does what. In practice, log retention is set to 30 days, nobody looks at it unless something goes wrong, and shared accounts make it impossible to tie an action to a person anyway.

The real problem is not that there are no tools. The problem is that privileged access is treated as an exception in most organisations, while in practice it is a daily routine. A PAM strategy treats it as what it is: a process that runs continuously and has to be able to account for itself.

What does PAM actually do?

PAM stands for privileged access management. Some sources also use privileged account management. In practice the term covers both meanings: managing the accounts themselves and managing what those accounts may do, when and with what verification.

A mature PAM approach combines four elements.

Credential vaulting. Passwords, SSH keys and API tokens for privileged accounts sit in a central, encrypted vault. Nobody knows the actual password. You check it out, use it and it is rotated straight afterwards. In Microsoft terminology this is called automated password management.

Just-in-time access. Someone does not have permanent admin rights. Someone requests rights, gets them for a defined period (an hour, a working day, a specific change window), and afterwards they expire automatically.

Session monitoring and recording. Every session in which raised rights are used is recorded. Not just which command, but the full session. After an incident you do not have to reconstruct what happened, you can play it back.

MFA on everything privileged. No exceptions for service accounts or break-glass. MFA is always on, always required.

What this solves for you as a CISO is not a technology problem. It solves an accountability problem. During an audit you can show who used which rights when, on what grounds and what happened during that session. That is the scope of, for example, ISO 27001 and NEN 7510, two frameworks that set explicit requirements for the management of privileged access.

Which accounts fall under PAM?

A misconception: PAM is not only about IT staff. Microsoft distinguishes eight categories of privileged accounts. Organisations still tend to see a few of them: domain administrators and local administrators, application administrators with full access to an application and its data, superuser accounts with unlimited rights.

But these are often forgotten:

• Service accounts. Applications that talk to each other through accounts with fixed credentials. Often never rotated, often used by several systems at once, often with more rights than needed.
• Emergency accounts (break-glass). Meant for the moment when all other access fails. Should never be used day to day, but without monitoring you do not know whether that is the case.
• External suppliers and consultants. The freelancer who has to log in once a month for maintenance. Do they still have rights when the engagement ends? In how many organisations is that tracked in any structured way?
• Business privileged accounts. A finance director with approval rights on payments. Technically not an IT account, but functionally just as privileged.

The first thing we do in a PAM project is map this out. Almost always, accounts come to light that nobody knew existed, or that are in the name of someone who left three years ago.

How we approach PAM

We are not a PAM vendor. We have been identity architects for 18 years and we are an Okta Apex Partner, the highest partner tier in the Benelux. In 2025 we were named Okta Partner of the Year for the Benelux. We implement PAM based on what we have seen work and not work across our 40+ identity implementations.

Our approach to PAM rests on four pillars.

Inventory first, tooling second. Installing a PAM tool without first knowing which accounts exist produces an expensive illusion of control. We start with an inventory: which privileged accounts exist, who uses them, for what, at what frequency and what the dependencies are. Only then do we choose which accounts go into scope for the first phase.

Start with the highest-impact accounts. Not everything at once. We usually start with domain admins and service accounts in the production environment. That is where the most risk and the most audit pressure sit. We phase in the rest.

Just-in-time where it can, vault where it must. For human users we move to temporary rights as much as possible. For service accounts and shared accounts it is more often vaulting with automatic rotation. We choose what fits per account type, not one model for everything.

Integration with your existing IGA process. PAM does not stand apart from the rest of your identity landscape. Joiners-movers-leavers, access reviews, certification. That all has to work together. So we hang PAM off the same source data (HR, contract management) as the rest of your identity governance administration. One workflow, one review process, one audit trail.

For customers running on Okta, Okta Privileged Access is often the logical choice. It integrates with the existing Okta tenant, uses the same MFA policies, and offers JIT access for servers, vaulting for accounts and session recording for compliance. For customers with a different stack we look more broadly. It is not about a product, it is about whether the solution fits your infrastructure and your process.

We work in MVP cycles of 10 to 30 days, the same approach as in our Okta implementations. No year-long programmes, no Big Bang. First a defined scope live, then the next.

What this delivers

What we see in practice at organisations that set up PAM well:

• Audit evidence without digging. A question from the auditor about who was on the production server three months ago between 20:00 and 22:00 is something you answer in five minutes instead of five days. Session recording included.
• Workable just-in-time flows. People request rights through a process that takes 30 seconds, not through a ticket that sits for a week. Permanent admin rights disappear, without work grinding to a halt.
• Compliance claims that hold up. ISO 27001 chapter 9 (access control) and NEN 7510 for healthcare get actual substantiation instead of a procedure document nobody follows.
• Service accounts under control. Passwords rotate automatically, nobody knows them in plaintext anymore, and when a script uses an account somewhere you see it in the audit trail.
• A workable supplier process. Externals get temporary rights through a request flow, use them for the agreed job and see their rights expire automatically afterwards.

When is this worth taking seriously now?

There are a few situations where we advise not waiting any longer. The most concrete is an announced audit where you know the current logging on privileged accounts does not produce enough evidence. A second situation is a recent incident involving a privileged account, or a sector incident that affects you and that you can no longer hold off your board with. A third, and perhaps the most common, is a cloud migration. The privileged accounts in a hybrid environment are more complex than in a purely on-prem situation, and the old controls often no longer work in a world of dynamic infrastructure.

Do you have the sense that PAM applies to you, but you do not know where to start? Book a call. We look at your situation and give an honest assessment of what is feasible and in what order, the way we do with all our customers, at the speed of business.