What do security teams get wrong about PAM when preparing for DORA audits?

Why Security Teams Misread PAM Under DORA

Preparing for a DORA audit is not just about proving that privileged credentials are stored somewhere secure. Auditors are looking for evidence that privileged access is governed, reviewed, and traceable across the full access lifecycle, including administrative accounts, emergency access, third-party support paths, and service credentials. If PAM is treated as a vaulting tool only, teams may miss the control evidence DORA expects around accountability and resilience.

DORA places pressure on operational discipline, so the question is whether privileged access can be explained, justified, and reconstructed when something goes wrong. That means the control must show who can use privileged access, when they can use it, how it is monitored, and how exceptions are approved. The practical weakness is often not the absence of a vault, but the absence of reliable review and audit evidence around what the vault does. EU Digital Operational Resilience Act (DORA)

NHIMG research also shows how often teams still struggle with the basics of privileged visibility: only 5.7% of organisations report full visibility into service accounts. In practice, many security teams discover the audit gap only after they are asked to prove that privilege was continuously governed rather than merely provisioned.

How PAM Has to Work in Practice

For DORA readiness, PAM should be understood as an operational control layer that covers access assignment, session use, logging, review, and revocation. That matters because privileged access can create resilience risk even when credentials are technically protected. If a privileged account is active but not monitored, or if an exception is left in place without expiry, the organisation may be unable to demonstrate effective control during audit or incident review.

A useful way to think about PAM for this context is to ask whether each privileged path is both necessary and explainable. Teams should be able to identify:

• Which human, service, and third-party accounts hold privilege
• Which access paths are standing, temporary, or break-glass
• Which sessions are recorded or logged with enough detail for later review
• Which approvals, recertifications, and exception decisions are retained as evidence

DORA does not reward surface-level hardening if the organisation cannot show control operation over time. That is why review cadence, alerting, and evidence retention matter as much as password storage. The relevant point is not simply that access exists, but that access can be justified and traced across systems and vendors. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it frames access as a lifecycle problem rather than a one-time provisioning task.

For teams mapping this to control evidence, the strongest pattern is a repeatable chain from request to approval to use to review to revocation. Current guidance suggests that when any one of those steps is missing, PAM becomes difficult to defend as a resilience control rather than an access repository. These controls tend to break down when emergency access, outsourced administration, or machine credentials are managed outside the same review and logging model because the evidence becomes fragmented across teams and tools.

Common Audit Gaps and Control Edge Cases

Tighter privileged control often increases operational overhead, so teams have to balance auditability against the need for fast recovery and support. That trade-off is most visible with break-glass accounts, third-party administrators, and shared service credentials, where organisations sometimes loosen process to preserve availability.

The edge case is that these exceptions are exactly where DORA scrutiny becomes hardest to satisfy. If a privileged account is exempt from normal review, or if a vendor can access production without a recorded session, the organisation may still be exposed even though PAM exists in name. Best practice is evolving, but the audit expectation is clear: exceptions should be bounded, time-limited, and visible enough to reconstruct later.

Another common gap is assuming that a vault record alone proves control. It does not. Auditors will usually care more about whether the organisation can show active monitoring, access review, and timely revocation than whether the password was ever stored centrally. The operational test is whether the control still works when a user leaves, a vendor contract ends, or an emergency credential is used outside normal hours.

Where teams get caught out is scale and fragmentation. A PAM program that looks strong for a handful of administrator accounts can still fail when it has to cover service accounts, third parties, and short-lived operational exceptions across many environments. In practice, the control breaks down when privilege is spread across systems faster than the organisation can review, log, and evidence it.

Practitioner Guidance

What to prioritise: Focus first on whether privileged access can be evidenced end to end, not on whether it is merely stored in a central tool. If you cannot show review, session traceability, and revocation for high-risk access paths, the audit risk remains high even if the vault is well managed.

What to verify: Check that break-glass access, third-party admin paths, and service credentials sit inside the same governance model as human administrator access. Verify that every exception has an owner, an expiry, and a retained approval record, because unowned exceptions are the fastest way for PAM to fail an audit.

Practitioner takeaway: The strongest PAM posture for DORA is the one that can prove control over time, across people, vendors, and machines, with enough evidence to reconstruct privilege use after the fact.

Related resources from NHI Mgmt Group

• What do teams get wrong about building an identity security programme across multiple vendors and environments?
• What do security teams get wrong about PAM during post-merger integration?
• What do security teams get wrong about lifecycle audits?
• What do security teams get wrong about PAM and IGA coverage?