DORA and operational resilience: Credential management as a financial risk control

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.

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 one-time passwords are not adequate against current attack techniques. Enforce phishing-resistant MFA for all users, with particular rigour on privileged accounts and remote access paths.

• Enforce least-privilege access. JIT provisioning — granting elevated access only for the duration of a specific task — eliminates the standing privileges that make credential theft so damaging. Deactivate accounts immediately on offboarding. Dormant accounts are among the most common and most avoidable attack vectors.

• Vault all credentials. Service account passwords, API keys, and privileged credentials must be stored in an encrypted, access-controlled credential vault. Manual credential management at scale is operationally unworkable and produces no audit trail. A business password manager Passwork — deployed on-premise within the institution’s own infrastructure — provides the encrypted vaulting, granular access controls, and complete activity history that Article 9 demands.

• Monitor continuously. Anomalous login behaviour — unusual geolocations, off-hours access, lateral movement patterns — must trigger automated alerts. Reducing that 186-day average dwell time is the single most effective lever for cutting both financial exposure and DORA incident reporting obligations.

All four controls depend on the same foundation: how credentials are stored, shared, accessed, and monitored. Without structure at that layer, even well-designed policies fail at execution.

How Passwork supports DORA compliance in practice

Passwork is a corporate password manager certified to ISO/IEC 27001 and available as a self-hosted deployment — meaning your credential data never leaves your own infrastructure.

For financial entities navigating DORA’s Chapter V supply chain obligations, that distinction matters: a third-party SaaS credential store introduces exactly the kind of ICT dependency the regulation requires you to govern.

For institutions working through the four controls above, Passwork addresses the credential management dimension of each.

• MFA enforcement across the credential layer. Passwork supports biometric, passkey, and security key MFA natively, with SAML SSO and LDAP integration for enterprise environments.

• Role-based access control and least privilege. Permissions are assigned at vault and folder level, inherited from AD or LDAP groups, and updated automatically on directory changes. Offboarding revokes access to shared credentials in a single operation — logged and timestamped, producing the evidence an investigator will request under Article 9(4)(c).

• Privileged account inventory and secure sharing. Passwork provides a structured, searchable repository of all organisational credentials, including shared administrative accounts. Encrypted vault sharing replaces informal channels that leave no audit trail and cannot be revoked.

• Audit logs for compliance documentation. Every credential access, permission change, password reset, and sharing event is recorded in a tamper-evident log, exportable for compliance reporting and integrable with SIEM systems. A structured activity history is a substantively stronger response to a regulator than a policy document alone.

DORA compliance is as much an evidence problem as a technical one. The institutions that navigate enforcement most effectively are those that can produce documentation on demand.

Act before the audit

DORA has converted credential management from a security best practice into a binding financial risk control. Articles 9(4)(c) and 9(4)(d) are explicit: least-privilege access, strong authentication, and cryptographic key protection are legal obligations for every financial entity operating in the EU.

Operational resilience begins with identity — and identity begins with controlling who holds the keys.

Audit your credential controls against Article 9, document the findings, and have the evidence ready before a regulator asks. Under DORA, the absence of documentation is itself a finding.

Passwork is designed for exactly this situation: a self-hosted password manager that keeps credential data inside your own infrastructure, enforces MFA across every access point, and generates the tamper-evident audit logs that turn a compliance conversation from a liability into a demonstration. ISO/IEC 27001 certified, with LDAP and SAML SSO integration for enterprise environments.

Start your free Passwork trial — full functionality, no limitations.

Sponsored and written by Passwork.