This blog was first published in 2025 and has been updated.
When the Digital Operational Resilience Act (DORA) was adopted by the EU, it signaled a fundamental shift in how financial institutions must approach cybersecurity, risk management, and operational continuity. For the first time, regulators didn’t just mention identity security in passing — they embedded it directly into the fabric of compliance.
This evolution recognizes a reality many security professionals have known for years: that identity is the foundation of digital security and a linchpin of operational resilience. Let’s look at what’s changed, the impacts DORA will have on identity security, the challenges that financial institutions face, and how CISOs must prepare to ensure that their organizations meet DORA requirements by the 2025 deadline.
Under DORA, every digital operation within a financial institution — from payments to customer onboarding to trading systems — must be secure, resilient, and continuously available. And that places identity security front and center. Because if you can’t verify who is accessing what, when, and from where, your identity strategy collapses.
In the new DORA regulatory reality, identity is no longer a back-office IT function. It is now a strategic imperative owned by risk leaders, compliance officers, and business executives alike.
Several articles within DORA directly or implicitly demand robust identity and access management (IAM) capabilities. For example:
- Access control and governance: DORA mandates that institutions manage user access rights in real time and conduct regular access reviews to prevent privilege creep and unauthorized access.
- Authentication requirements: Strong authentication methods, such as multi-factor authentication (MFA), are expected to protect systems from unauthorized access.
- Operational continuity: Institutions must ensure critical functions remain available during cyber incidents, outages, or disruptions. This includes maintaining identity services under duress.
- Monitoring and anomaly detection: Organizations must detect, respond to, and recover from cyber incidents quickly. Identity-related anomalies, such as unusual access patterns, are crucial indicators.
These requirements underscore the need for a modern, risk-aware identity security program.
2025 marks the year where compliance now passes into enforcement stages, meaning organisations that do not comply with DORA face fines of either 2% of average global turnover or 1% of average daily turnover with the addition of daily fines levied on non-compliant organisations until they achieve compliance. The stakes are now high.
Despite increased investments in security, many financial institutions still struggle with identity-related gaps in their security and operational functions, including:
- Legacy IAM systems that lack adaptability and visibility
- Siloed identity tools across on-premises and cloud environments
- Weak authentication methods that are vulnerable to phishing
- Manual governance processes that make compliance reporting slow and error-prone
These challenges leave organizations exposed — not only to attackers, but to regulatory scrutiny and compliance fines.
CISOs in the financial sector must take the lead in aligning identity strategy with DORA. That means:
- Adopting risk-based access models that adjust controls based on context and behavior
- Ensuring business continuity with hybrid failover for authentication and access
- Strengthening governance with automated provisioning, reviews, and access certification
- Embracing passwordless authentication to eliminate common attack vectors
The regulatory language of DORA is clear—but implementation looks different depending on the size, structure, and starting point of each organization. The following scenarios illustrate how financial services organizations of different profiles are approaching DORA compliance in practice.
Scenario 1: Large European bank preparing for DORA
Challenge A major EU retail bank operating across twelve countries faces a common problem: its identity infrastructure has grown through decades of acquisitions, leaving it with seven separate IAM systems, inconsistent MFA policies across business units, and access review cycles that take up to thirty days to complete. Under DORA’s Article 9 requirements for access control and continuous governance, this fragmentation represents both a compliance gap and an operational risk.
DORA requirements that apply
- Article 9: ICT risk management framework, access control, and least-privilege enforcement
- Article 10: Detection of anomalous activity and ICT-related incidents
- Article 17: ICT-related incident management process
Implementation steps
- Consolidate identity systems into a unified platform (RSA ID Plus) supporting cloud, on-premises, and hybrid environments across all subsidiaries.
- Deploy phishing-resistant MFA (RSA iShield Key 2 Series) for all privileged and administrative accounts within ninety days.
- Automate access certification and provisioning workflows using RSA Governance & Lifecycle, replacing manual spreadsheet-based reviews.
- Enable RSA Risk AI for continuous behavioral analysis and real-time anomaly detection.
- Establish a centralized IAM audit trail that feeds directly into DORA compliance reporting dashboards.
Success metrics
- Access review cycle reduced from thirty days to three days
- 100% of privileged accounts enrolled in phishing-resistant MFA within sixty days of platform deployment
- Audit-ready access certification reports generated automatically on a quarterly cadence
- Zero authentication-related incidents flagged during first DORA regulatory inspection
Key lesson Consolidation is not just a compliance project—it is a resilience project. A unified IAM platform eliminates the blind spots that exist at the seams between disconnected systems, which is exactly where attackers look for gaps.
Scenario 2: Mid-size financial services firm managing hybrid infrastructure
Challenge Core trading systems on-premises, client-facing applications in Azure, and a mix of SaaS tools across the business. When cloud outages or on-premises network disruptions occur, authentication failures have previously locked staff out of critical systems for hours—a direct violation of DORA’s operational continuity requirements under Article 11.
DORA requirements that apply
- Article 11: ICT business continuity and disaster recovery
- Article 9: Network and system access controls
- Article 30: ICT third-party service provider contractual requirements
Implementation steps
- Deploy RSA ID Plus Hybrid Failover to ensure authentication services remain available if cloud or on-premises components fail—with automatic failover between environments in under 60 seconds.
- Implement RSA Mobile Lock to enforce device health checks for staff accessing trading systems from mobile or unmanaged devices.
- Map all ICT third-party authentication dependencies and validate contractual DORA compliance under Article 30.
- Run quarterly disaster recovery simulations that include authentication system failure scenarios, documenting recovery time objectives (RTOs) and recovery point objectives (RPOs) for regulatory review.
Success metrics
- Authentication availability during infrastructure outages improved from 67% to 99.9%
- RTO for identity services reduced from 4 hours to under 3 minutes
- All ICT third-party contracts updated to include DORA-mandated resilience provisions within the 12-month preparation window
- Recovery simulation results documented and ready for competent authority review
Key lesson Operational continuity under DORA is not just about preventing attacks—it is about maintaining function during them. Hybrid failover for authentication is as critical to DORA compliance as strong authentication itself.
Scenario 3: Investment management company responding to a cyber incident under DORA
Challenge An EU-based asset manager with €40 billion AUM experiences a credential-based attack targeting its fund administration platform. An adversary-in-the-middle phishing campaign compromises a service account, enabling lateral movement within the network. Under DORA’s incident classification and reporting framework, the organization must notify its competent authority within 24 hours of classifying the incident as “major” — and provide an intermediate report within 72 hours and a final report within one month.
DORA requirements that apply
- Article 17: ICT-related incident management, classification, and reporting
- Article 19: Major incident reporting obligations and timelines
- Article 9: Authentication and access controls that must remain operational during the incident
The incident timeline and response
- Hour 0: RSA Risk AI detects anomalous authentication behavior—a service account logging in from an atypical geolocation and accessing systems outside its normal access pattern. An automated access suspension is triggered pending investigation.
- Hour 2: Security team confirms the compromise. The account is deprovisioned via RSA ID Plus in under 60 seconds. Lateral movement is contained.
- Hour 6: Internal classification confirms this meets DORA’s “major incident” threshold based on impact on the availability of core systems.
- Hour 18: Initial notification filed with the competent authority—within the 24-hour requirement—including incident type, classification rationale, and immediate containment measures taken.
- Hour 60: Intermediate report filed—within the 72-hour requirement—with full incident timeline, root cause analysis (phishable MFA on the compromised account), affected systems, and remediation steps.
- Week 4: Final incident report filed, including post-incident review, control improvements implemented (phishing-resistant MFA deployed to all service accounts), and changes to monitoring thresholds.
Success metrics
- Incident contained within 2 hours of detection
- All three DORA reporting deadlines met—24h initial, 72h intermediate, 1-month final
- Zero disruption to fund administration services during the incident due to authentication failover
- Immediate remediation: 100% of service accounts migrated to phishing-resistant authentication within 30 days of incident
Key lesson DORA’s incident reporting requirements reward organizations that have already invested in fast detection and containment. RSA Risk AI behavioral analytics reduced the time from attack initiation to containment from a potential 254-day average (the industry norm for credential breaches) to under 2 hours—transforming the compliance narrative from “we were breached” to “we detected, contained, and reported within DORA’s framework.”
At RSA, we help financial institutions operationalize identity as a pillar of resilience. Our security-first identity platform, RSA ID Plus, is built for regulated environments like finance.
- RSA Risk AI analyzes behavioral and contextual signals to enforce adaptive access policies
- RSA Mobile Lock protects access on unmanaged or compromised devices
- RSA iShield Key 2 Series authenticators enable phishing-resistant FIDO and OTP authentication
- RSA Governance & Lifecycle automates access governance and compliance workflows
- RSA Hybrid Failover ensures uninterrupted authentication during outages
Together, these solutions provide the controls needed to align with DORA — and strengthen your organization beyond compliance.
DORA marks a turning point for identity in financial services. It elevates IAM from a technical concern to a regulatory mandate — and a strategic enabler of operational resilience.
Financial institutions that embrace identity-first security strategies will not only meet DORA requirements, but also gain a competitive advantage in security, agility, and customer trust. Now is the time to rethink your identity posture before DORA enforcement begins.
The Digital Operational Resilience Act (DORA) entered into force on 16 January 2023 and became fully applicable on 17 January 2025 — the date from which all covered financial entities and critical ICT third-party providers were required to be compliant and enforcement powers activated across all 27 EU member states. There is no grace period for institutions that have not yet met requirements; competent authorities may initiate investigations and impose penalties as of that date.
For institutions still working toward full compliance, the priority is demonstrating a documented, actively progressing compliance program—particularly for complex legacy identity infrastructure that cannot be modernized overnight.
DORA establishes a two-tier penalty regime. Financial entities face fines of up to 2% of total annual worldwide turnover or 1% of average daily worldwide turnover—whichever is applicable under the competent authority’s assessment—with the daily rate applied as an ongoing fine until compliance is achieved. Individual senior managers found responsible for breaches may face personal fines of up to €1,000,000.
Critical third-party ICT providers (CTPPs) designated by the European Supervisory Authorities face steeper exposure: up to €5,000,000 per violation, with individual-level fines up to €500,000, plus daily penalties of up to 1% of average daily global turnover for up to six months. Beyond financial penalties, competent authorities may publicly disclose DORA violations—creating reputational risk that, for regulated financial institutions, can exceed the financial cost of the fine itself.
DORA applies to virtually the entire EU financial sector. Covered entities include credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers (CASPs), central securities depositories, central counterparties, trading venues, alternative investment fund managers, insurance and reinsurance undertakings, credit rating agencies, audit firms of public-interest entities, and crowdfunding service providers.
Critically, DORA’s reach extends beyond EU-headquartered institutions. Non-EU financial entities operating within the EU, and ICT third-party service providers—including cloud providers—that supply services to EU-covered financial entities are also subject to DORA requirements under Article 30’s contractual provisions. US-based financial services firms with EU operations or EU-based clients should not assume they are out of scope.
DORA does not prescribe specific technologies, but its risk management and access control requirements under Articles 9 and 10 directly translate into mandatory IAM capabilities. Financial institutions must implement the following
- Strong authentication for all systems: Policies and protocols for MFA are explicitly expected, with phishing-resistant methods recommended for privileged and high-risk access.
- Least-privilege access control: Users and systems should have only the access rights required for their function, reviewed continuously and adjusted in real time.
- Access governance: Regular, documented access reviews and certification cycles are required, with automated provisioning and deprovisioning to prevent privilege creep.
- Anomaly detection: Continuous monitoring of authentication and access patterns make it possible to detect and respond to unusual activity indicative of a compromise.
- Operational continuity for identity services: Authentication infrastructure must remain available during cyber incidents and outages, with documented recovery objectives.
- Audit trail maintenance: comprehensive, tamper-resistant logs of all identity and access events must be available for regulatory review and incident investigation.
RSA ID Plus for Financial Services maps directly to each of these requirements.
The Payment Services Directive 2 (PSD2) focused specifically on securing digital payments and required payment service providers to report major incidents to regulators within two hours of detection. DORA supersedes PSD2’s incident reporting rules for all entities subject to both frameworks—the European Banking Authority formally repealed its PSD2 major incident reporting guidelines from 17 January 2025, replacing them with DORA’s harmonized framework.
The key distinction is scope: PSD2 covered payment security; DORA covers the entire ICT risk posture of all financial entities, for all operational and security incidents—not just payment-related ones. DORA’s incident reporting timeline is also more structured: 24 hours for initial notification, 72 hours for an intermediate report, and one month for a final report. DORA also introduces direct oversight authority over critical ICT third parties, an accountability mechanism that has no equivalent in PSD2.
Under DORA Articles 17 and 19, institutions must follow a defined incident response and reporting process. First, the incident must be detected, logged, and classified—DORA defines criteria for what constitutes a “major” incident based on impact on service availability, number of clients affected, geographic spread, and economic impact. Once classified as major, the reporting clock starts:
- Initial notification to the competent authority within 24 hours of classification as a major incident
- Intermediate report within 72 hours with a detailed account of the incident, containment actions taken, and initial root cause assessment
- Final report within one month of the intermediate report, including full post-incident analysis, permanent remediation measures, and lessons learned
Throughout the incident, identity and authentication services must remain operational. DORA explicitly requires that business continuity plans cover ICT infrastructure including access and authentication systems—institutions cannot use an active incident as justification for authentication systems being unavailable.
Yes, provided the cloud-based solution and its contractual terms meet DORA’s third-party ICT provider requirements under Article 30. Cloud identity providers must offer contractual guarantees around service availability, incident notification timelines, audit rights, and data portability. Institutions relying solely on a cloud authentication service without a hybrid failover capability may struggle to demonstrate the operational continuity DORA requires.
RSA ID Plus is purpose-built for this challenge: it supports cloud, hybrid, and on-premises authentication from a single platform, with hybrid failover ensuring that authentication services remain available if cloud connectivity is disrupted. This means the compliance benefits of cloud management—centralized administration, automatic updates, scalability—without the single-point-of-failure risk that regulators are scrutinizing.
DORA requires financial institutions to maintain and be able to produce on request:
- ICT risk management framework documentation—policies, procedures, and controls mapped to DORA’s requirements, reviewed and approved by the management body at least annually
- Access review records—documented, time stamped access certification cycles demonstrating least-privilege enforcement and timely deprovisioning of departed staff and changed roles
- Incident registers—a complete log of all ICT-related incidents, their classification, timeline, containment actions, and outcomes
- Major incident reports—all filed notifications (initial, intermediate, final) for any incidents meeting DORA’s major classification criteria
- Third-party ICT contracts—Article 30-compliant agreements with all ICT service providers, including cloud authentication and identity management vendors
- Business continuity and disaster recovery plans—documented, tested plans covering authentication system availability, with recorded RTO/RPO results from simulations
RSA Governance & Lifecycle automates the generation and maintenance of access review records and compliance reports, reducing the time to produce audit-ready documentation from weeks to hours.
