Criteria catalog · Privileged Access Management
PAM selection: the criteria that matter under NIS2 and DORA
Most PAM evaluations check whether passwords can be vaulted and sessions recorded. The decision that matters is what happens with the accounts nobody listed, the admins who route around the tool, and the day the PAM itself is down.
Independent criteria reference · 12 criteria · Last updated August 2026 · Not sponsored by any vendor
Privileged access is where most serious incidents end up, whatever they started as. NIS2 Article 21 expects access control and multi-factor authentication as part of the baseline measures, and DORA expects a financial entity to prove who could do what on its critical ICT systems. A PAM tool promises exactly that proof. But a vault that covers half the privileged accounts, session recordings that live outside the EU, or a rollout that administrators quietly work around gives you the audit artefact without the control. These criteria separate the two.
Coverage and control
Criterion 01
Vault coverage beyond human admins
Why it matters
Human administrator accounts are the easy part. The privileged credentials that actually cause incidents sit in service accounts, scheduled jobs, CI/CD pipelines, database connection strings and OT or legacy systems that no modern agent supports. A vault that rotates only what humans check out leaves the larger half of the attack surface untouched.
What to ask
Ask for a written list of the account types the product can discover, vault and rotate automatically, by platform, and ask specifically which of your service accounts, pipeline secrets and legacy or OT targets it cannot rotate and what the vendor proposes for those.
The trap
"Supports all major platforms" refers to the connectors for interactive sessions, not to automatic rotation. Rotation of a service account also requires updating every place that uses the credential, and that dependency mapping is where most vaults stop.
Criterion 02
Just-in-time access, not just a safer vault
Why it matters
A vault-only deployment still leaves standing privileged accounts that exist around the clock and only need one leaked credential to be abused. Just-in-time elevation, where the privilege is granted for a task and removed afterwards, is what actually reduces exposure. It is also the model auditors increasingly expect when they ask for least privilege.
What to ask
Ask whether the product can grant time-boxed privileges that are created and revoked per request, for which target platforms, and what remains standing after the session ends. Ask to see the approval and expiry flow in the demo, not the roadmap.
The trap
"Zero standing privilege" on the slide often means the password is rotated after checkout while the account itself, with all its rights, keeps existing. Rotating a permanent admin account is not the same as not having one.
Criterion 03
Discovery of unknown privileged accounts
Why it matters
You cannot vault what you do not know exists. Every environment carries privileged accounts nobody listed: local admins created during a migration, shared credentials in scripts, cloud roles granted for a project that ended years ago. Coverage that is measured only against the accounts you knew about is not coverage.
What to ask
Ask how the product finds privileged accounts you have not onboarded, across on-premises directories, cloud identity, databases and local machine accounts, and how often that scan runs. Ask for a discovery run against a segment of your own environment during the pilot.
The trap
Discovery is often an initial onboarding wizard rather than a continuous process. The accounts that matter are the ones created next month by a contractor under deadline pressure, and a one-time scan never sees them.
Criterion 04
Session recording with evidential value
Why it matters
Session recording is the feature every buyer checks and few examine. Under NIS2 Article 23 and the DORA incident reporting regime you may have to reconstruct what a privileged user did, within days, in a form you can hand to a supervisor or a forensic team. A video nobody can search, export or prove unaltered does not deliver that.
What to ask
Ask whether recordings are searchable by command and keystroke, how long the export of a full session takes, in what format, and how integrity of a recording is protected so it can be shown not to have been edited after the fact.
The trap
"Full session recording" frequently means a screen video for graphical sessions and nothing for API calls, tunnelled protocols or the automation that uses the same credentials. The sessions that go unrecorded are usually the ones an attacker prefers.
Criterion 05
Break-glass when the PAM is down
Why it matters
Once every administrative path runs through the PAM, the PAM becomes the single point through which you lose the ability to fix anything, including the PAM. DORA expects ICT continuity for critical functions, and NIS2 expects business continuity in the baseline measures. A PAM outage during an incident is a plausible scenario, not a corner case.
What to ask
Ask what the documented emergency access procedure looks like when the vault, its database or its identity dependency is unavailable, who holds the sealed break-glass credentials, how their use is detected afterwards, and when the vendor last tested this with a customer.
The trap
High availability is presented as the answer to break-glass, but an HA pair with a corrupted database or a lost signing key fails on both nodes. Break-glass is a process with envelopes and audit trails, not a second server.
Compliance and jurisdiction
Criterion 06
EU residency of the vault and the recordings
Why it matters
A PAM holds the most sensitive data in your organisation twice over: every privileged credential, and a recording of everything done with it. Where that data is stored and where it can be accessed from decides your GDPR position and, for a financial entity, what goes into the DORA register of information. A recording that leaves the EU for analysis is a transfer.
What to ask
Ask where the vault, the session recordings and the backups of both are stored, whether an EU-only region is the default or an add-on, and whether vendor support and engineering staff outside the EU can access customer data for troubleshooting.
The trap
"Hosted in the EU" covers the primary storage and stays silent about support access, telemetry and the analytics service that indexes recordings for search. Residency of storage is not residency of access, and this is a category where access is the whole point.
Criterion 07
Who holds the master key
Why it matters
Every vault encrypts its contents with a key. Whoever controls that key can read every privileged credential you own. In a SaaS PAM the vendor often does, in a self-hosted one you do, and in between there are customer-managed key options with very different guarantees. This is the question a supervisor asks when third-party dependency is on the table, and it maps directly to DORA Article 28 expectations on managing ICT third-party risk.
What to ask
Ask who can technically decrypt the vault without the customer's participation, whether the master key can live in a hardware security module you control, and what the vendor can and cannot produce if served a legal order for your data.
The trap
"Encrypted at rest with customer-specific keys" means nothing if the vendor's platform holds and uses those keys on your behalf. The test is not whether a key exists but whether the vendor could hand over readable credentials without you.
Criterion 08
Vendor jurisdiction and ownership
Why it matters
The vendor's legal seat decides which laws can compel it to disclose data, regardless of where the data sits. For a tool that holds every administrative credential, a headquarters under the US CLOUD Act or similar extraterritorial rules deserves a documented review under GDPR and Schrems II, and the answer belongs in your DORA contractual and register documentation.
What to ask
Ask where the vendor is legally headquartered, who owns it today, which entity signs your contract and which entities operate the service. This is a factual question with a factual answer.
The trap
PAM vendors change hands often. A European founding story on the website may sit on top of a current owner in another jurisdiction. Check the present ownership chain and the operating entity, not the brand history.
Criterion 09
Integration with your identity provider and SIEM
Why it matters
A PAM that runs its own user directory and its own MFA becomes a second identity system with its own joiner and leaver gaps. The privileged sessions it records are also the most valuable events your SIEM can receive. Under NIS2 Article 21, MFA and access control are baseline measures, and they only hold if the PAM enforces the identity your central provider already governs.
What to ask
Ask whether the PAM authenticates every user, including administrators of the PAM itself, through your identity provider with your MFA policy, whether access removal there revokes PAM access immediately, and which session and checkout events reach your SIEM in a documented schema.
The trap
"Integrates with your IdP" often covers single sign-on for end users while the PAM's own administrators keep local accounts with their own passwords, which are precisely the accounts an attacker targets first.
Operations and cost
Criterion 10
Administrator experience and adoption
Why it matters
A PAM only controls what runs through it. If the checkout flow adds minutes to every routine task, administrators find a way around it: a locally cached credential, a direct SSH key, a shared account that never made it into the vault. Every workaround is an unrecorded privileged path, and the audit report will still say the PAM is in place.
What to ask
Ask two of your own administrators to complete a normal day of tasks through the product during the pilot and count the extra steps. Ask the vendor for reference customers who can say how long enforcement took and how many exceptions are still open.
The trap
Adoption numbers quoted by vendors count licensed users, not the share of privileged sessions that actually pass through the PAM. A tool with a hundred licensed admins and thirty percent session coverage is a compliance artefact, not a control.
Criterion 11
Deployment model and operational burden
Why it matters
Self-hosted PAM gives you the master key and the residency question on your own terms, and it makes you the operator of one of your most critical systems, with its patching, high availability and backups. SaaS removes that burden and moves the trust question to the vendor. Neither is wrong, but the choice decides who is accountable for what in your DORA contract and in your continuity planning.
What to ask
Ask what a fully patched, highly available, backed-up deployment requires in staff time per month for your size, and for SaaS ask which operational duties remain with you, including backup verification, key custody and disaster recovery testing.
The trap
The cheaper deployment on the quote is often the one where the ongoing operations are silently yours. A PAM that is six patches behind because nobody owns it is a privileged access risk in its own right.
Criterion 12
Licensing model and total cost
Why it matters
PAM vendors license by named user, by managed account, by target system or by concurrent session, and the same environment can cost a multiple depending on which metric applies. Service accounts and discovery can push managed account counts far above the initial estimate. Add professional services for onboarding, connector development and the inevitable second rollout wave, and the first quote is rarely the real number.
What to ask
Ask for a three-year total cost based on your actual counts of privileged users, accounts and targets, with the metric used stated explicitly, price caps at renewal, and a fixed-price scope for onboarding services that names what is out of scope.
The trap
"Unlimited targets" or "per user" pricing is attractive until the module you actually need, such as secrets management for pipelines or session recording for cloud consoles, turns out to be licensed on a different metric. Price the configuration you will run, not the tier that wins the comparison table.
Which obligation each criterion covers
The regulatory map of this catalog: the obligation, where it comes from, and the criteria that address it. Use it to show an auditor that the requirement list was built from the rules, not from a vendor deck.
| Obligation | Source | Covered by |
|---|---|---|
| Access control and multi-factor authentication as a baseline measure | NIS2 Art. 21(2)(i), (j) | |
| Incident handling and reconstruction of privileged activity | NIS2 Art. 21(2)(b), Art. 23 | |
| Business continuity and crisis management when the control itself fails | NIS2 Art. 21(2)(c), DORA Art. 11 | |
| Cryptography and control over encryption keys | NIS2 Art. 21(2)(h), GDPR Art. 32 | |
| ICT third-party risk and the register of information | DORA Art. 28 | |
| Contractual provisions for ICT services supporting critical or important functions | DORA Art. 30 | |
| Processor contract and international transfers | GDPR Art. 28, Art. 44 ff., US CLOUD Act | |
| Management responsibility for the effectiveness of measures | NIS2 Art. 20 |
The question sheet
Every vendor question of this catalog in one list, in the order of the criteria. Put the same questions to every vendor in the same words and write the answers next to each other.
- Vault coverage beyond human admins
Ask for a written list of the account types the product can discover, vault and rotate automatically, by platform, and ask specifically which of your service accounts, pipeline secrets and legacy or OT targets it cannot rotate and what the vendor proposes for those.
- Just-in-time access, not just a safer vault
Ask whether the product can grant time-boxed privileges that are created and revoked per request, for which target platforms, and what remains standing after the session ends. Ask to see the approval and expiry flow in the demo, not the roadmap.
- Discovery of unknown privileged accounts
Ask how the product finds privileged accounts you have not onboarded, across on-premises directories, cloud identity, databases and local machine accounts, and how often that scan runs. Ask for a discovery run against a segment of your own environment during the pilot.
- Session recording with evidential value
Ask whether recordings are searchable by command and keystroke, how long the export of a full session takes, in what format, and how integrity of a recording is protected so it can be shown not to have been edited after the fact.
- Break-glass when the PAM is down
Ask what the documented emergency access procedure looks like when the vault, its database or its identity dependency is unavailable, who holds the sealed break-glass credentials, how their use is detected afterwards, and when the vendor last tested this with a customer.
- EU residency of the vault and the recordings
Ask where the vault, the session recordings and the backups of both are stored, whether an EU-only region is the default or an add-on, and whether vendor support and engineering staff outside the EU can access customer data for troubleshooting.
- Who holds the master key
Ask who can technically decrypt the vault without the customer's participation, whether the master key can live in a hardware security module you control, and what the vendor can and cannot produce if served a legal order for your data.
- Vendor jurisdiction and ownership
Ask where the vendor is legally headquartered, who owns it today, which entity signs your contract and which entities operate the service. This is a factual question with a factual answer.
- Integration with your identity provider and SIEM
Ask whether the PAM authenticates every user, including administrators of the PAM itself, through your identity provider with your MFA policy, whether access removal there revokes PAM access immediately, and which session and checkout events reach your SIEM in a documented schema.
- Administrator experience and adoption
Ask two of your own administrators to complete a normal day of tasks through the product during the pilot and count the extra steps. Ask the vendor for reference customers who can say how long enforcement took and how many exceptions are still open.
- Deployment model and operational burden
Ask what a fully patched, highly available, backed-up deployment requires in staff time per month for your size, and for SaaS ask which operational duties remain with you, including backup verification, key custody and disaster recovery testing.
- Licensing model and total cost
Ask for a three-year total cost based on your actual counts of privileged users, accounts and targets, with the metric used stated explicitly, price caps at renewal, and a fixed-price scope for onboarding services that names what is out of scope.
These criteria are the starting point. Not the decision.
A criteria list tells you what to look at. It does not weigh them against your specific situation, check them against your hard constraints, or produce the memo your board and auditor need. DecisionOS takes these criteria, weights them for your decision, and builds a defensible record. In days, not months.
Continue with the decision guide
Related criteria catalogs
- Identity and Access ManagementIAM selection: the criteria that matter under NIS2 and DORA23 criteria
- Endpoint Detection and ResponseEDR selection: the criteria that matter under NIS2 and DORA23 criteria
- Security Information and Event ManagementSIEM selection: the criteria that matter under NIS2 and DORA23 criteria
Print this catalog or save it as PDF for the meeting