DORA Identity Controls Requirements: What the Regulation Actually Demands

What DORA Actually Requires on Identity

The Digital Operational Resilience Act (EU 2022/2554) is not primarily an identity regulation. It is a framework for ICT risk management across the EU financial sector — banks, insurance companies, investment firms, crypto-asset service providers, and a range of other entities. But identity controls sit at the centre of several of its most demanding obligations.

The relevant provisions are concentrated in three articles. Understanding what each one says precisely — rather than what general summaries claim — is the starting point for any compliance programme.

Article 9: Protection and Prevention

Article 9 is the core access control article. It requires financial entities to "develop, document, and implement policies, procedures, protocols and tools aimed at ensuring the security of networks and information systems." Within that, it specifies a set of obligations that map directly onto identity controls.

Article 9(4) is the most detailed provision. It requires financial entities to have in place "policies and measures to ensure sound administration of human resources" covering specifically:

• Access management policies based on the need-to-know principle and least privilege
• Documented and periodically reviewed access rights for all users
• Separate, dedicated accounts for privileged access
• Strong authentication (the technical standards specify multi-factor authentication) for privileged access and for access to systems that support critical or important functions
• Access revocation procedures when access is no longer required
• Controls to prevent the use of shared credentials for privileged access

Article 9 also requires that access policies are documented, implemented, and tested — not simply drafted. The distinction between having a policy and having an operating control supported by evidence is central to how DORA supervisors approach this area.

Article 10: Detection

Article 10 requires financial entities to implement mechanisms to promptly detect anomalous activities, including network intrusion and identity-related threats. For identity specifically, this means monitoring for unusual authentication patterns, privileged access anomalies, and deviations from established access baselines.

The regulatory technical standards (RTS) developed by the Joint Committee of the ESAs under Article 15 elaborate on detection requirements. Entities must maintain logs of privileged access events and must have the capability to correlate authentication events against access policy — not just log them.

Article 17: ICT-Related Incident Management

Article 17 requires financial entities to have a documented ICT incident management process. The identity relevance is twofold: many ICT incidents are caused by compromised credentials or misused privileged access, and the response to any ICT incident affecting identity systems must be pre-planned and tested.

Article 17 specifically requires entities to define "roles and responsibilities" for incident response — which in an identity context means documented emergency access procedures, tested revocation processes, and clear ownership of each privileged account.

The Access Control Obligations in Detail

The EBA, ESMA, and EIOPA published final draft regulatory technical standards (RTS) on ICT risk management in January 2024, which took effect alongside the regulation. These RTS provide the technical specificity that the regulation's articles set out as principles. For identity practitioners, the most important sections are in Chapter II of the RTS on ICT risk management.

Documented Access Policies

The RTS requires that access management policies are documented, approved by management, and reviewed at least annually. The policy must cover: how access rights are granted, modified, and revoked; how privileged access is managed differently from standard user access; and how service accounts are identified, documented, and reviewed.

An undated policy document — particularly one that does not reflect the actual state of your systems — is not compliant. Supervisors will look at the policy date, ask when it was last reviewed, and ask whether the controls it describes are the controls that are actually in place.

Least Privilege and Need-to-Know

The least privilege requirement means that every account should have access to only the systems and data required for its defined function — and no more. This is a straightforward principle that is poorly implemented in practice across most organisations.

Common failures the RTS implicitly addresses:

• Accounts provisioned with broad roles at joining and never scoped down
• Application-level permissions granted for convenience rather than necessity
• Inherited permissions from group memberships that have grown over time
• Temporary elevated access that was never revoked

DORA does not specify a technical implementation for least privilege. But it does require entities to document how least privilege is enforced, and to demonstrate through periodic access reviews that it is functioning.

Multi-Factor Authentication

The RTS on ICT risk management specifies that strong authentication, including multi-factor authentication, must be applied to all privileged access and to access to all systems that support critical or important functions. This is not guidance — it is a technical standard with legal force.

The practical implication is that MFA is not optional for privileged accounts. Exceptions must be documented, justified, risk-accepted by management, and mitigated through compensating controls. Undocumented MFA exceptions are a compliance finding.

Service Account Management

Service accounts are explicitly within scope. The RTS requires entities to maintain an inventory of service accounts, document the purpose of each, and apply appropriate access controls — including preventing service accounts from being used interactively where that is not their function.

The service account inventory requirement is one of the most commonly missed by organisations in initial DORA readiness assessments. Many organisations have a large number of service accounts — particularly in complex Active Directory or hybrid cloud environments — with no owner, no documented purpose, and no review cycle.

Periodic Access Reviews

Access rights must be reviewed at least annually, and more frequently for privileged access. The review must be documented — who conducted it, what was in scope, what findings were made, and what remediation actions were taken.

A verbal assertion that "we do access reviews" will not satisfy a DORA supervisor. The review process, its outputs, and the actions taken as a result of it must all be evidenced.

Audit and Testing Requirements

DORA's testing obligations are among the most demanding aspects of the regulation for financial entities. Chapter IV of DORA sets out a tiered testing programme that includes threat-led penetration testing for significant entities and annual ICT risk assessments for all in-scope entities.

Annual ICT Risk Assessment

Article 6(6) requires all in-scope entities to conduct an annual review of their ICT risk management framework. In the context of identity, this means assessing whether access controls are operating effectively, whether privileged access management is functioning as designed, and whether the entity's identity posture has changed materially during the year.

The assessment must produce documented findings and a management report. It is not sufficient to perform an internal review and conclude "all is fine." The review must identify gaps, assign owners, and set remediation timelines — and those findings must be visible to management.

Threat-Led Penetration Testing (TLPT)

Article 26 requires "significant financial entities" — those designated by competent authorities based on their systemic importance — to conduct threat-led penetration testing at least once every three years. TLPT under DORA is a specific methodology, aligned with the TIBER-EU framework, that involves a red team conducting a real-time attack simulation targeting the entity's production environment.

Identity controls are a primary target for any TLPT engagement. Red teams will attempt:

• Credential theft and lateral movement through privilege escalation
• Exploitation of misconfigured service accounts
• Abuse of privileged access through social engineering
• Bypass of MFA controls through session hijacking or token theft

Entities subject to TLPT need to ensure that their identity controls are capable of withstanding a genuine adversarial test — not just meeting a technical checklist.

What Evidence Looks Like to a DORA Auditor

Based on early supervisory guidance and published examination frameworks from the EBA and ESMA, DORA supervisors are examining identity controls through a specific evidence lens. Policy documents are not evidence. What supervisors are requesting includes:

• Access control policy: Dated, approved by named management authority, version-controlled, with a clear review history
• MFA coverage report: A point-in-time export showing which accounts have MFA enforced, which do not, and documented exceptions for those that do not
• Privileged account inventory: A complete list of all privileged accounts — including service accounts — with owners, purposes, and last review dates
• Access review records: Completed and signed-off review outputs showing what was reviewed, by whom, and what actions were taken
• Incident and exception logs: Records of access policy exceptions, including the risk acceptance process and the compensating controls applied

The pattern that supervisors report seeing most consistently is organisations that have the policies but not the evidence. A policy that says "access reviews are conducted quarterly" is meaningless without the quarterly review outputs to support it.

Privileged Access Under DORA

Privileged access — accounts with elevated permissions to modify systems, read sensitive data, or administer infrastructure — receives specific treatment under DORA because it represents the highest-risk category of access. A compromised standard user account is bad. A compromised privileged account is typically catastrophic.

Separate Accounts for Privileged Tasks

Article 9(4) explicitly requires separate, dedicated accounts for privileged access tasks. This means an administrator who uses their standard user account for both daily work and administrative tasks is non-compliant. Privileged actions must be performed using separate accounts that are not used for standard activities such as email, browsing, or accessing business applications.

The rationale is clear: a phishing attack against a user's standard email account should not give an attacker elevated access to systems. Separation ensures the blast radius of a credential compromise is bounded.

PAM Controls

Privileged Access Management (PAM) tooling is not mandated by name in DORA, but the controls that PAM tools implement are required. Specifically:

• Session recording and logging for privileged access to critical systems
• Just-in-time access mechanisms (elevated access granted for a defined period and revoked automatically)
• Credential vaulting — privileged account passwords should not be known to users; they should be checked out from a secure store
• Approval workflows for elevated access requests, with audit trails

Organisations without a PAM solution in place should not interpret this as a requirement to deploy one immediately. The controls can be implemented through process and policy — but the evidentiary burden then falls on proving those processes work, which is significantly harder without tooling.

Emergency Access Procedures

DORA requires documented procedures for emergency access — what happens when normal authentication mechanisms are unavailable during an incident. This is the break-glass account scenario: accounts with broad access that bypass normal controls, held in secure storage, used only when other access paths are unavailable.

Emergency access accounts must be documented, their use must be logged, and the log must be reviewed after any use. Undocumented break-glass accounts — which are extremely common in organisations that have grown through acquisition or have legacy systems — are a compliance risk under both the DORA text and the supervisory guidance.

Service Account Governance

Service accounts — accounts used by applications, scripts, and automated processes rather than humans — are frequently the weakest element of privileged access governance. They tend to accumulate over time, often have excessive permissions granted at creation and never reduced, and frequently have no human owner by the time they are examined.

DORA's requirements for service accounts include: documented inventory with owner, purpose, and permission scope; periodic review (at the same frequency as human privileged accounts); and application of least privilege — a service account should not have domain admin rights unless its function genuinely requires them.

What Supervisors Are Actually Checking

DORA supervision in its first cycle is being conducted by the national competent authorities in each EU member state, coordinated by the Joint Committee of the ESAs (EBA, ESMA, EIOPA). Published guidance from supervisory examinations in the Netherlands, Germany, and Ireland — jurisdictions where DORA supervision began earliest — provides a picture of what supervisors are focusing on.

The Policy-Evidence Gap

The most consistent finding in early DORA examinations is the gap between what policies say and what evidence shows. Supervisors are reporting that organisations frequently have well-written policies that describe controls that are not operating in practice, or that operated at some point in the past but have not been maintained.

The practical implication: supervisors are not reading your policies and accepting them at face value. They are asking for the operational evidence — the review outputs, the account inventories, the exception logs — that demonstrates the policy controls are running. If you have a policy that says privileged access is reviewed quarterly but you cannot produce four consecutive quarterly review outputs with signatures and remediation actions, the policy is not evidence of compliance.

What EBA Supervisory Guidance Indicates

The EBA's guidance on ICT risk management examinations, published in 2024 alongside the RTS, specifies the supervisory examination methodology. For identity and access management, the examination approach includes:

• Request for privileged account inventory — complete, with owners and last review dates
• Sample testing of access reviews — verifying that accounts identified for removal in the review were actually removed
• MFA exception review — verifying that all undocumented exceptions are identified and mitigated
• Service account review — verifying that service accounts are inventoried, owned, and operating within their documented purpose
• Emergency access account audit — verifying that break-glass accounts are documented and their use logged

ESMA and Insurance Sector Focus

ESMA's supervisory focus for investment firms and CCPs includes a particular emphasis on access to trading systems and settlement infrastructure. Privileged access to systems that could affect market integrity — order management systems, risk systems, settlement connectors — is under heightened scrutiny.

EIOPA's guidance for the insurance sector focuses on third-party access governance: access granted to outsourcing partners, managed service providers, and other third parties to ICT systems. Many insurance entities have complex legacy outsourcing arrangements where access controls were never properly governed. DORA's third-party ICT risk requirements (Chapter V) intersect with identity here — third-party access must be governed with the same rigour as internal privileged access.

The Timeline Pressure

DORA came into force on 17 January 2025. That is not when organisations needed to start — the 24-month implementation period ran from the regulation's publication in December 2022. Organisations that were subject to DORA should have had compliant controls in place on 17 January 2025.

For identity controls, the practical reality in February 2026 is:

• Organisations are now over a year into the first supervisory cycle
• National competent authorities are conducting their first formal examinations
• The first wave of TLPT designations has been made in several jurisdictions
• Supervisors have now seen enough organisations to have established patterns of what compliant and non-compliant controls look like

There is a significant difference between identifying a gap now and having that gap identified in a formal supervisory examination. Organisations that identify their own identity control gaps and have a documented remediation plan are in a materially better position than those where the same gaps are found by a supervisor with no prior acknowledgment.

This is not primarily about penalty risk — though penalties under DORA can be significant. It is about the nature of the supervisory relationship. A supervisor who finds undisclosed gaps that the entity had not identified internally is receiving a signal about the entity's risk management culture, not just its technical controls.

DORA Identity Controls Readiness Checklist

The following 10 items are a practical starting point for any organisation assessing its DORA identity controls posture. They are not a substitute for a formal assessment, but they will surface the most common and significant gaps quickly.

• Documented access control policy: Is there a current (reviewed within 12 months), management-approved access control policy that covers privileged access, service accounts, and MFA requirements?
• Privileged account inventory: Can you produce a complete list of all privileged accounts — including service accounts — with human owners and documented purposes, within 24 hours?
• MFA coverage report: Can you produce a report showing the percentage of privileged accounts with MFA enforced, and a documented exception list for those without it?
• Separate privileged accounts: Do administrators use separate accounts for privileged tasks, distinct from their standard user accounts used for email and normal work?
• Access review records: Do you have completed access review outputs for the last four quarters — or the last review cycle — showing what was reviewed, findings, and remediation actions?
• Service account governance: Is there a service account register with owners, purposes, permission scopes, and last review dates for each account?
• Emergency access procedures: Are break-glass accounts documented, secured, and subject to a use-logging process? Has a test of emergency access been conducted in the last 12 months?
• Access revocation process: Is there a documented, tested process for revoking all access for a user within a defined timeframe? Is the timeframe measured and reported?
• Third-party access governance: Are all third-party privileged accounts inventoried, scoped to minimum necessary access, and subject to the same review cycle as internal privileged accounts?
• Annual ICT risk assessment: Has your organisation completed an ICT risk assessment that includes identity controls within the current annual cycle, with documented findings and a management report?

If the answer to any of these is "no" or "we think so but cannot evidence it," that gap exists whether or not a supervisor has identified it. The value of finding it now is that you can address it before the examination cycle reaches you.