NEWS

DORA and Operational Resilience: Credential Management as a

Article 9 of DORA makes authentication and access control a legal obligation for EU financial entities. With stolen credentials now the single largest...

Dylan H.

News Desk

April 25, 2026
7 min read
DORA and Operational Resilience: Credential Management as a

Overview

The EU Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — became applicable on January 17, 2025, transforming how EU financial institutions must manage cybersecurity risk. At its core, DORA converts credential management from a security best practice into a legally binding financial risk control.

Article 9 of DORA makes authentication and access control explicit legal obligations for EU financial entities. In an environment where stolen credentials represent the single largest initial access vector — accounting for 22% of all data breaches — the regulation's timing is critical.


What DORA Requires

The Five Pillars of DORA

DORA is structured around five interconnected resilience requirements for EU financial entities:

PillarRequirement
ICT Risk ManagementRobust frameworks with defined roles, reporting lines, and risk appetite thresholds
Incident ReportingSignificant ICT incidents reported to competent authorities within strict timeframes
Resilience TestingRegular testing of ICT systems through threat-led penetration testing (TLPT)
Third-Party RiskOversight framework for Critical Third-Party Providers (CTPPs)
Information SharingVoluntary cyber threat intelligence sharing between financial entities

Article 9: Authentication as a Legal Obligation

Articles 9(4)(c) and 9(4)(d) are explicit on credential management requirements:

  • Least-privilege access — users must have only the minimum permissions required for their role
  • Strong authentication — multi-factor authentication is mandated for privileged and remote access
  • Cryptographic key protection — cryptographic credentials must be protected in accordance with defined standards
  • Access control documentation — all access grants must be documented and auditable

The absence of documentation is itself a regulatory finding under DORA.


The Real-World Risk: Why Credentials Are the Central Threat

The Ficoba Breach: A DORA Case Study

The January 2026 breach of France's national bank registry made the credential threat concrete. A threat actor obtained the credentials of a single civil servant with access to Ficoba — the interministerial database holding records on every bank account opened in France.

Using only that one compromised account, the attacker:

  • Accessed and extracted data on 1.2 million bank accounts
  • Exfiltrated IBANs, account holder names and addresses, and tax identification numbers
  • Operated with legitimate credentials, generating no authentication alerts
  • Triggered discovery only after the extraction was complete

The affected system was taken offline and reported to France's data protection authority (CNIL). Under DORA's incident reporting requirements, financial entities experiencing comparable events face mandatory notification to competent authorities within defined timeframes.

The Dwell Time Problem

MetricValueImplication
Average credential dwell time186 daysAn attacker moves as a legitimate user for over six months
Breach detection gapWeeks to monthsStandard monitoring misses slow-burn credential abuse
Financial sector breach cost$5.56M average (IBM DBIR)Among the highest of any sector
Credentials as initial access vector22% of all breaches (Verizon DBIR)The leading entry point, ahead of vulnerability exploitation

A 186-day dwell time means a compromised credential does not produce a discrete security event. It produces a sustained, invisible threat to operational continuity — the exact type of threat DORA is designed to prevent.


DORA Compliance Requirements for Credential Management

Minimum Technical Controls

Under Article 9, EU financial entities must implement:

Authentication Controls:
- Multi-factor authentication for all privileged access
- Multi-factor authentication for remote access
- Strong authentication for access to financial systems
 
Access Control:
- Least-privilege principle enforced across all systems
- Regular access reviews (at minimum annually for privileged accounts)
- Immediate revocation upon role change or departure
- Segregation of duties for critical financial functions
 
Credential Management:
- Cryptographic protection of stored credentials
- Prohibition of shared or generic accounts
- Password complexity and rotation policies
- Privileged Access Management (PAM) for admin credentials
 
Logging and Monitoring:
- Audit trails for all privileged access
- Anomaly detection for credential usage patterns
- Retention of access logs for the DORA-mandated period

Documentation Requirements

Under DORA, the absence of documentation is itself a regulatory finding. Organizations must maintain evidence of:

RequirementDocumentation
Access control policyWritten policy referencing DORA Article 9 obligations
Least-privilege reviewsRecords of periodic access reviews with sign-off
MFA deploymentInventory of systems covered and exceptions documented with risk acceptance
Credential vault controlsEvidence of PAM deployment and privileged credential management
Incident responseDocumented response procedures for credential compromise scenarios

Practical Compliance Steps

Audit Your Credential Controls Against Article 9

  1. Inventory all authentication mechanisms — document which systems use passwords, MFA, certificates, or passkeys
  2. Identify MFA gaps — systems still relying on single-factor authentication for privileged or remote access are a DORA compliance finding
  3. Review access grants — verify that least-privilege is enforced and over-provisioned accounts are remediated
  4. Assess PAM coverage — privileged credentials for critical systems should be managed through a PAM solution with session recording

Detection: Closing the 186-Day Gap

Standard perimeter monitoring will not detect credential abuse during the dwell period. Closing this gap requires:

Behavioral Controls:
- User and Entity Behavior Analytics (UEBA) to detect anomalous login patterns
- Impossible travel detection
- Privilege escalation anomaly detection
- Alert on access to Ficoba-equivalent registries or high-value data stores
 
Proactive Hunting:
- Credential exposure monitoring (dark web, breach databases)
- Periodic credential rotation for high-value accounts
- Honey credentials to detect lateral movement

Third-Party Risk

DORA explicitly requires oversight of ICT third-party providers. Credential management extends to vendor access:

  • Inventory all third-party access to financial systems
  • Enforce MFA for all vendor/contractor remote access
  • Time-limit vendor credentials — no standing access
  • Monitor third-party sessions via PAM

The Cost of Non-Compliance

Beyond the direct financial and reputational cost of a credential-based breach ($5.56M average in financial services), DORA exposes entities to:

  • Regulatory fines from national competent authorities (NCAs)
  • Mandatory reporting obligations with reputational exposure
  • Increased supervisory scrutiny following any incident
  • Potential liability to customers and counterparties affected by inadequate controls

For organizations subject to both DORA and GDPR, a credential-based breach triggering unauthorized access to personal financial data creates dual reporting obligations — to the NCA under DORA and to the supervisory authority under GDPR.


Key Takeaways

  1. DORA converts credential hygiene into law — Article 9 requirements are not aspirational, they are mandatory
  2. The 186-day dwell time is the operational threat DORA addresses — credential compromise produces silent, sustained disruption to operational continuity
  3. Document everything — under DORA, undocumented controls are non-compliant controls
  4. MFA gaps are the highest-priority finding — any system with privileged or remote access lacking MFA is a direct Article 9 violation
  5. Third-party credential access is in scope — vendor and contractor credentials fall under DORA's third-party risk framework

References