DORA · Identity Lens

DORA

DORA is where identity stops being IT plumbing and becomes board-reported operational resilience.

Full name: Digital Operational Resilience Act
Region: European Union
Applies to: Financial entities operating in the EU — banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers — plus critical ICT third-party service providers designated by the European Supervisory Authorities.

Regulation (EU) 2022/2554 (DORA) applies from 17 January 2025 and brings ICT risk management for financial services under a unified, supervised regime. It covers ICT risk management, incident reporting, digital operational resilience testing (including threat-led penetration tests), and the management of ICT third-party risk. Identity sits inside every one of those pillars.

What it asks for

The Identity Lens

The clauses that bite when identity architecture is weak, rewritten in plain English. Authoritative text is linked below.

ICT risk management framework (Article 6 and RTS on ICT risk management tools)

The framework must include identification, protection, detection, response, recovery, and learning — applied to identity-bearing assets like authentication services, privileged accounts, federation, and machine credentials. The RTS spells out access control, authentication strength, monitoring, and segregation expectations.

Identity and access management (RTS on ICT risk management, Title II)

Logical and physical access management, strong authentication aligned to risk, least privilege, joiner/mover/leaver, periodic review, and explicit lifecycle for privileged and emergency accounts. Generic accounts and shared credentials are tightly constrained.

ICT third-party risk (Articles 28-30)

Identity is how third-party risk actually manifests: how a CSP, BPO, or fintech vendor gets into your environment, what they can do once in, and how quickly they can be cut off. DORA requires register-of-information level visibility into these relationships, including exit strategies that have to actually work.

Incident reporting (Articles 17-23 and RTS on classification)

Major ICT-related incidents must be reported on an initial / intermediate / final cadence. Identity-driven incidents (account takeover, federation failure, mass token compromise) typically classify as major and need the identity team's audit trail in hours, not weeks.

Digital operational resilience testing (Articles 24-27, TLPT under TIBER-EU)

Threat-led penetration tests assume the adversary will target identity. Architectures need to be testable against credential theft, federation abuse, and lateral movement via legitimate accounts.

Where teams miss it

Common Misses

Patterns we see again and again — usually because the identity programme runs in parallel to the compliance programme rather than inside it.

Identity treated as part of access management only. The wider ICT risk framework, third-party register, and incident pipeline are run by other teams that do not see the identity surface.

Privileged access pathways through CSPs, MSSPs, and fintech vendors not captured in the third-party register.

Emergency / break-glass accounts undocumented, untested, or shared. Auditors find them quickly.

Recovery testing that restores systems but assumes federation, MFA, and conditional access still work — when the most likely scenario is that they do not.

What works

Where Design Pays Off

Patterns we have seen survive supervisory review, audit, and the next change.

An identity contribution to the DORA register of information: who has access, through which provider, to which critical functions.

Identity resilience treated as part of disaster recovery — known-good baselines, immutable backups, drift detection, and the ability to recover a tenant before recovering applications.

Threat-led test scenarios that explicitly include identity attack paths and produce architectural findings, not just patch tickets.

Authoritative sources