DORA and operational resilience: Credential management as a financial risk control
DORA Article 9 mandates credential management and MFA for EU financial institutions.
Summary
The Digital Operational Resilience Act (DORA), which entered force on January 17, 2025, makes authentication and access control a legal obligation for EU financial entities under Article 9. The regulation requires implementation of strong authentication (MFA based on FIDO2/WebAuthn standards), least-privilege access controls, and cryptographic key management. The article explains DORA's specific credential security requirements and illustrates the operational resilience failure that occurs when compromised credentials enable attackers to move laterally undetected for months, citing the January 2026 breach of France's national bank registry as a concrete example.
Full text
DORA and operational resilience: Credential management as a financial risk control Sponsored by Passwork April 24, 2026 10:10 AM 0 Author: Eirik Salmi, System Analyst at Passwork When a threat actor walks into your network using a legitimate username and password, which control stops them? For most financial institutions, the honest answer is: nothing catches it immediately. The attacker looks like an authorised user. They move laterally, escalate privileges, and map critical systems for an average of 186 days before the breach is even identified — and a further 55 days to contain it — according to IBM's Cost of a Data Breach Report (2025). By then, the operational damage is done, and the regulatory clock has already started. On January 17, 2025, the Digital Operational Resilience Act (DORA) entered into application across the EU. Article 9 of the regulation makes credential security a binding financial risk control, with supervisory consequences for institutions that fall short. The question is no longer whether your authentication posture meets best practice. It is whether it meets the law — and whether you can prove it. This article traces the specific Article 9 requirements that govern credential management, explains why a compromised password is an operational resilience failure under DORA's framework, and outlines the practical controls that close the gap. The threat that DORA was built to counter Stolen credentials are the single largest initial access vector in 2025, accounting for 22% of all data breaches, per Verizon's Data Breach Investigations Report. For financial institutions, the sector-specific cost of that exposure averages $5.56 million per incident, according to IBM's Cost of a Data Breach Report — down from $6.08 million in 2024, yet still the second-highest of any industry globally. The supply side of credential theft has been fully industrialised. Initial Access Brokers sell verified corporate network access for an average of $2,700, with 71% of listings including privileged credentials — pre-packaged access that requires no technical skill to exploit, according to Rapid7 research. Infostealers such as Lumma, RisePro, StealC, Vidar, and RedLine automate credential harvesting at scale. IBM X-Force data shows their delivery via phishing increased 84% year-on-year in 2024, with 2025 data pointing to an even steeper trajectory. DORA's Article 9 exists precisely to interrupt this chain. The regulation reflects a documented, ongoing threat to the operational continuity of European financial markets. Keep your credentials DORA-ready with Passwork DORA Article 9 requires strong authentication, least-privilege access, and documented controls. Passwork delivers all three — self-hosted, ISO 27001 certified, with full audit logs your compliance team can export on demand. Try Passwork Free What DORA Article 9 actually requires Article 9 of DORA — titled "Protection and Prevention" — sits within the ICT risk management framework mandated by Article 6. It sets out specific technical and procedural obligations that financial entities must implement. Two provisions are directly relevant to credential management. Article 9(4)(c) requires financial entities to "implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only." This is the least-privilege principle, stated as a legal obligation. Article 9(4)(d) goes further, requiring entities to "implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems, and protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes." Unpacking that language in operational terms: MFA is mandatory. The reference to "relevant standards" points directly to FIDO2/WebAuthn — the most widely deployed authentication standard currently resistant to Adversary-in-the-Middle (AiTM) phishing kits, which can bypass SMS and TOTP-based MFA in real time. Cryptographic key management is a regulatory requirement. Privileged access management (PAM) tools are not named explicitly in the regulation — but the controls they deliver map directly onto Article 9's requirements. Session recording, just-in-time (JIT) access provisioning, and privileged credential vaulting are precisely the "dedicated control systems" the regulation describes. Institutions that have not deployed these controls face a compliance gap that supervisors can act on. The European Banking Authority (EBA) and ESMA's Regulatory Technical Standards under DORA provide additional specificity on ICT risk management requirements, reinforcing the Article 9 baseline with sector-specific implementation guidance. Credential compromise as an operational resilience failure DORA's stated purpose is to ensure financial entities can withstand, respond to, and recover from ICT disruptions. A credential compromise looks entirely different through that lens than it does through a security incident lens. With an average dwell time of 186 days, a compromised credential does not produce a discrete security event. It produces a sustained, invisible threat to operational continuity — an attacker moving laterally, escalating privileges, and mapping critical systems while appearing as a legitimate user. It is a direct threat to the operational continuity DORA is designed to protect. The breach of France's national bank registry in January 2026 made the mechanics 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 account, the attacker accessed and extracted data on 1.2 million bank accounts, including IBANs, account holder names and addresses, and tax identification numbers. The affected system was taken offline, operations at the registry were disrupted, and the incident was reported to France's data protection authority, CNIL. The attack required no technical sophistication. Under DORA, an incident of that scale at a financial entity would trigger mandatory reporting obligations under Article 19 — an initial notification within 4 hours of classification (and no later than 24 hours after detection), an intermediate report within 72 hours, and a final report within one month. The third-party dimension: Vendor credentials are your credentials DORA's Chapter V places explicit obligations on financial entities regarding ICT third-party risk. The compliance perimeter does not stop at the institution's own systems. The Santander breach in May 2024 is the European reference point. Attackers used credentials stolen from employees of Snowflake to access a database containing customer and employee data across Spain, Chile, and Uruguay. The credentials had been harvested months earlier by infostealer malware infecting contractor workstations. None of the compromised Snowflake accounts had multi-factor authentication enabled. The entry point was not inside Santander. It was a vendor's weak authentication posture — and it exposed data belonging to one of Europe's largest banks without a single exploit being written. Under DORA, a financial institution whose critical ICT provider suffers a credential-based breach faces direct regulatory exposure. Institutions must contractually require equivalent authentication standards from their vendors and audit compliance against those requirements. A vendor's password policy gap is not the vendor's problem alone — it is the financial entity's regulatory liability. Building a DORA-compliant credential management Meeting Article 9's requirements demands a structured programme across four areas. Deploy phishing-resistant MFA first. FIDO2/WebAuthn-based authentication — hardware security keys, passkeys, platform authenticators. SMS and TOTP-based o