Skip to content
Start with Identity
Join free
Compliance · Intermediate

Identity Controls for DORA

By SWI Community Team · Updated 2026-11-05 · 13 min

DORA identity controls are the access, authentication and account rules that EU financial entities must run under the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, which has applied since 17 January 2025. The detail sits in Commission Delegated Regulation (EU) 2024/1774: unique accounts for every person and system, least privilege, strong authentication for remote, privileged and critical access, and access-right updates at least every six months for systems supporting critical or important functions. This guide is for IAM and security teams at banks, insurers, investment firms, payment institutions and their ICT providers.

What the law and the RTS say

DORA itself is short on identity detail. Article 9(4) requires policies that limit physical and logical access to what legitimate, approved functions need, and policies and protocols for strong authentication mechanisms based on relevant standards. The ICT risk management RTS, Delegated Regulation 2024/1774, adopted 13 March 2024, turns that into checkable requirements:

Provision Requirement What you build
RTS Art. 20(2)(a) A unique identity and user account for each staff member, including staff of third-party ICT providers No shared vendor logins; every provider engineer is a named account
RTS Art. 20(2)(b) Records of all identity assignments, kept after a reorganisation or the end of a contract Retained provisioning history, not just current state
RTS Art. 20(2)(c) Lifecycle process covering creation, change, review, temporary deactivation and termination, automated where applicable Joiner-mover-leaver automation through IGA and SCIM
RTS Art. 21(1)(a)-(b) Need-to-know, need-to-use and least privilege, including remote and emergency access; segregation of duties Role model plus toxic-combination rules
RTS Art. 21(1)(c) Limit generic and shared accounts; users identifiable for their actions at all times Shared admin accounts retired or vaulted with check-out attribution
RTS Art. 21(1)(e) Privileged, emergency and administrator access on a need-to-use or ad-hoc basis, dedicated admin accounts, automated PAM where applicable; revoke without undue delay Just-in-time elevation, separate admin identities
RTS Art. 21(1)(e)(iv) Update access rights at least once a year for all ICT systems, and at least every six months for systems supporting critical or important functions A six-month access certification cycle for critical systems
RTS Art. 21(1)(f) Authentication commensurate with asset classification; strong authentication for remote network access, privileged access, critical or important functions, and publicly accessible assets Phishing-resistant MFA on those four paths first

Smaller and non-interconnected entities that qualify for the simplified ICT risk management framework (Title III of the same RTS) get a lighter version: access rights must still be periodically reviewed and withdrawn when no longer required, but the fixed six-month interval does not apply.

The incident clock

The incident reporting RTS, Delegated Regulation 2025/301, sets the deadlines identity detection has to support. The EBA summarises them as an initial notification within 4 hours after classification as major and 24 hours after detection, an intermediate report within 72 hours, and a final report within one month. An intrusion that signs in with valid credentials produces no malware alert, so if identity telemetry is not watched, the 24-hour clock can expire before anyone knows it started.

What makes DORA different from a checklist

DORA is a resilience regulation, not a control catalogue, so the question is not whether a control exists but whether you can show it works under stress. For identity that means three testable claims:

  • You can revoke access fast enough to matter. Not just disable an account, but revoke refresh tokens and sessions, including for third-party ICT providers, and evidence the timeline.
  • You can detect identity-based incidents inside the reporting window. Feed identity signals into ITDR or your SOC so a normal-looking login by the wrong person still alerts.
  • You can operate during degradation. If your identity provider is unavailable, nobody signs in to respond. A tested break-glass path is a resilience control, not an IT convenience.

Third-party ICT access is the exposure

DORA extends scrutiny to ICT providers and requires a Register of Information on ICT third-party arrangements. Vendor access is consistently the least governed path in a financial institution: standing accounts, shared credentials, and remote sessions nobody records. RTS Article 20 removes the shared-login option by requiring unique accounts for provider staff.

The incidents show why:

  • A provider's API key. At the US Treasury, an attacker obtained a key BeyondTrust used to secure its Remote Support SaaS, bypassed the service's security and remotely accessed Treasury workstations. That is static API key abuse against the vendor, not the customer.
  • A provider's management plane. In the N-able N-central incident, attackers exploited CVE-2026-18577, an authentication bypass giving unauthenticated administrative access, then used Take Control remote sessions to reach systems in managed customer environments. N-able said its first hotfix was incomplete before a second shipped on 7 August 2026.
  • A supplier developer's session. The Bybit theft of about 1.5 billion dollars in ether ran through a compromised Safe{Wallet} developer machine and hijacked AWS session tokens, a case of token replay.

Decision table: where to spend first

If your gap is... Do this first Tool category
Shared or standing vendor accounts Named accounts per provider engineer, time-bound grants, session recording PAM
No six-month review evidence for critical systems Scope critical or important functions, run a certification with revocation counts IGA
Password-only remote or admin access Phishing-resistant MFA on the four RTS 21(1)(f) paths IdP plus MFA
No identity detection feeding the 4-hour clock Identity threat detection wired to incident classification ITDR
Static secrets in automation and provider integrations Vault, rotate, then move to short-lived workload credentials Secrets management

Ownership moved in 2026 for several tools on a typical DORA shortlist, which matters for your Register of Information and concentration-risk view. In PAM, Idira (formerly CyberArk) is part of Palo Alto Networks since 11 February 2026, and Delinea closed its acquisition of StrongDM on 5 March 2026. In IGA, SailPoint and Saviynt remain independent, while Veza is part of ServiceNow since 2 March 2026. For authentication, Microsoft Entra ID and Okta cover most workforce estates, with Yubico keys for administrators. For identity detection, Microsoft Defender for Identity and Silverfort are common in Active Directory-heavy banks. HashiCorp Vault has been an IBM subsidiary since 27 February 2025.

Evidence to keep

Access review output with revocation counts per cycle, the list of systems you classify as supporting critical or important functions (it sets the review interval), privileged session recordings, the MFA exemption list with review dates, third-party access grants with their expiry, retained identity assignment records for ended contracts, and incident timelines from detection to notification. See zero standing privileges.

Where to start

  1. Inventory third-party ICT access. Every provider account, remote session path and management platform with reach into your environment, each named, owned and expiring.
  2. Classify systems, then set review cadence. Six-month certifications for critical or important functions, annual for the rest. Planning estimate, not a regulatory figure: a first full cycle usually takes one quarter to stand up.
  3. Close strong-authentication gaps on remote, privileged, critical and internet-facing access.
  4. Prove revocation speed. Disable an account and revoke its sessions and tokens, including a provider account, and record the timeline.
  5. Test the break-glass path. Simulate an identity provider outage, use the emergency accounts, and keep the logged and reviewed record.

Identity controls for NIS2, IAM audit preparation, financial services vertical, insurance vertical, best identity tools for financial services, compliance calendar.

Frequently asked questions

What does DORA require for identity and access management?
DORA's ICT risk management requirements translate into strong authentication and access management with least privilege and segregation of duties, controls on privileged accounts, logging and monitoring that support incident detection and reporting, and governance of access by third-party ICT providers. Delegated Regulation 2024/1774 sets the detail. DORA has applied since 17 January 2025 and tests whether controls work under stress rather than whether they exist.
How often must access rights be reviewed under DORA?
Delegated Regulation 2024/1774, Article 21, requires access rights to be updated where changes are necessary and at least once a year for all ICT systems, and at least every six months for ICT systems supporting critical or important functions. Entities under the simplified framework must review periodically without a fixed interval. Keep revocation counts per cycle, because a review that removes nothing rarely convinces a supervisor.
Does DORA require MFA?
DORA does not name MFA, but Article 9(4)(d) requires strong authentication mechanisms, and RTS 2024/1774 Article 21 requires strong authentication methods for remote access to the network, privileged access, access to ICT assets supporting critical or important functions, and publicly accessible assets. In practice supervisors read that as MFA on those paths, and phishing-resistant factors are the defensible choice for administrators and vendors.
What IAM tools do banks need for DORA compliance?
Typically phishing-resistant MFA for workforce and privileged access, IGA for least privilege, segregation of duties, and evidenced access reviews, PAM with session recording and just-in-time elevation, and ITDR feeding the monitoring and incident reporting obligations. Add governed, time-bound access for third-party providers with a full audit trail. The tools matter less than proving revocation, detection, and degraded operation actually work.
How does DORA affect third-party vendor access?
DORA extends scrutiny to ICT providers, and vendor access is usually the least governed path in a financial institution: standing accounts, shared credentials, and unrecorded remote sessions. Grant time-bounded access through an approval workflow, record sessions that touch production, assign an owner per provider, and keep an inventory of provider access you can produce on request.
What identity evidence should we keep for a DORA review?
Keep access review output with revocation rates, privileged session recordings, the MFA exemption list with review dates, third-party access grants with their expiry, and incident timelines showing the path from detection to notification. Also be ready to evidence how quickly you can revoke sessions and refresh tokens, and a tested break-glass path for when the identity provider is unavailable.
Why is a break-glass path a DORA control?
Because DORA is a resilience regulation. You have to show you can keep operating when systems degrade, and if your identity provider is unavailable, nobody can sign in to respond. A tested emergency access path, with its use logged and reviewed, is an operational resilience control rather than an IT convenience, and it belongs in your evidence alongside revocation and detection timelines.
Last reviewed By SWI Community TeamSuggest a correctionHow we research