DORA Privileged Access Requirements: What Article 9 Actually Says

What Article 9(4) Actually Requires

DORA Article 9 covers ICT protection and prevention. Section 9(4) addresses access management specifically, and it is more prescriptive than many practitioners realise. The article requires financial entities to develop, document, and implement policies and measures that include:

• Access rights granted on the basis of need-to-know and least privilege
• Regular — and at minimum annual — reviews of all access rights
• Dedicated, separate accounts for privileged access functions, distinct from standard user accounts
• Strong authentication mechanisms — the RTS specifies MFA — for all privileged access and access to systems supporting critical or important functions
• Prohibition on shared credentials for privileged access
• Prompt revocation of access when it is no longer required

The RTS on ICT risk management, which entered into force alongside DORA, adds technical specificity. It requires entities to maintain a documented inventory of privileged accounts including service accounts, to apply access controls commensurate with the sensitivity of the systems accessed, and to ensure that privileged access sessions are logged and that logs are retained and reviewable.

These are not aspirational principles. They are technical standards with legal force, and supervisors are examining against them directly.

The Three Most Common Privileged Access Gaps

Across organisations assessed against DORA's privileged access requirements, three gaps appear with notable consistency. None of them are obscure technical failures — they are governance failures that developed gradually and were never corrected.

Gap 1: Shared Administrative Accounts

Article 9(4) explicitly prohibits shared credentials for privileged access. The requirement for dedicated, individual accounts for privileged functions is unambiguous. Yet shared admin accounts — a single "Administrator" or "svc-admin" account whose credentials are known to multiple people — remain common, particularly in organisations with legacy infrastructure or smaller IT teams.

The compliance problem is straightforward: a shared account cannot be attributed to an individual, its use cannot be audited against a named person, and its password cannot be managed on a per-person basis. It fails the dedicated account requirement, the audit trail requirement, and in practice almost always fails the MFA requirement as well.

Gap 2: Service Accounts with Excessive Privilege

Service accounts are frequently created with broad permissions — sometimes domain admin, sometimes broad Azure roles — because it was easier at the time and no one subsequently reviewed them. Over time they accumulate. A service account created for a specific integration five years ago may now have permissions that extend far beyond anything its current function requires.

The DORA problem: service accounts are within scope for the privileged account inventory and access review requirements. An unreviewed service account with excessive permissions that has no documented owner is a compliance gap and a genuine security exposure. Attackers target service accounts specifically because they frequently have high privilege and are not monitored for anomalous behaviour.

Gap 3: No Just-in-Time Access

Standing privileged access — accounts that have elevated permissions continuously, regardless of whether any privileged task is being performed — represents unnecessary risk exposure. Just-in-time access, where elevated permissions are granted only for the duration of a specific task and then automatically revoked, significantly reduces the window of opportunity for a compromised account to cause damage.

DORA does not use the term "just-in-time" explicitly, but the combination of least-privilege requirements and access review obligations creates a strong regulatory expectation towards it. An account that holds Global Administrator rights 24 hours a day, 365 days a year, is difficult to defend as compliant with a least-privilege principle — particularly when JIT mechanisms are readily available in both Microsoft Entra ID and third-party PAM platforms.

What a DORA Supervisor Expects as Evidence

The distinction between policy and evidence is central to how DORA supervisors approach privileged access. They are not evaluating whether your policy document says the right things. They are evaluating whether compliant controls are actually operating.

For privileged access, the evidence a supervisor will request includes:

• Privileged account inventory: A current, complete list of all privileged accounts — human and service — with named owners, documented purposes, and last review dates. Not a spreadsheet assembled the day before the examination. A maintained register with a version history.
• Access review logs: Completed review outputs for each review cycle in the period under examination. Each output should show which accounts were reviewed, by whom, what the findings were, and what remediation actions were taken — with completion dates.
• PAM audit trails: Logs showing privileged access sessions — who accessed what, when, and for how long. Where PAM tooling is in place, this means audit log exports. Where it is not, the equivalent evidence is more difficult to produce and will be scrutinised more closely.
• MFA enforcement evidence: A report — from your identity platform, not manually compiled — showing MFA status for every privileged account. Exceptions must be documented with a risk acceptance sign-off and compensating controls.
• Account separation confirmation: Evidence that privileged tasks are performed using separate accounts, not the same accounts used for standard business activity. This can be evidenced through account configuration reports from Active Directory or Entra ID.

The key principle: if you cannot produce this evidence within 24 to 48 hours of a request, you have an evidence gap. That gap may reflect an actual control gap, or it may reflect poor record-keeping around controls that are working. Either way, a supervisor reading a request that takes two weeks to respond to is drawing conclusions from the response time as well as the content.

Practical Steps Before the Next Supervisory Review

The following steps are prioritised by their supervisory impact and the frequency with which they surface as gaps in DORA examinations. They are sequenced so that each step produces evidence that the next step builds on.

• Run a privileged account discovery: Use your identity platform — Active Directory, Entra ID, or both — to produce a complete list of accounts with elevated roles or permissions. Include service accounts. Do not rely on a manually maintained list as your starting point.
• Assign owners to every account: Every privileged account, including every service account, must have a named human owner who is accountable for that account's continued use and scope. Accounts with no identifiable owner should be treated as orphaned and reviewed for removal.
• Eliminate shared admin accounts: Identify all shared credentials being used for privileged tasks and replace them with individual accounts before the next examination cycle. This is non-negotiable under Article 9(4).
• Enforce MFA on all privileged accounts: Conditional access policies or equivalent enforcement mechanisms should prevent any privileged account from authenticating without MFA. Document and risk-accept any exceptions with compensating controls.
• Conduct and document a full access review: Before your next supervisory cycle, complete a privileged access review that covers all accounts in your inventory, produces a written output with findings, and tracks remediation actions to completion.
• Scope service account permissions: For each service account in your inventory, verify that its current permissions match its documented purpose. Remove any permissions that are not required for its current function.