Skip to main content
ComplianceFinancial Fraud

DORA Mandates Credential Security as Financial Risk Control

Secure server room with rows of computer servers and restricted access controls.

"When a threat actor walks into your network using a legitimate username and password, which control stops them?"

That question, posed by Eirik Salmi, System Analyst at Passwork, frames a regulatory and operational reckoning for financial institutions across the EU. Since the Digital Operational Resilience Act (DORA) entered into application on 17 January 2025, credential security has moved from best practice to binding financial risk control — and supervisors now have concrete rules to enforce.

DORA Article 9: explicit legal duties on access and authentication

Article 9 sits inside the ICT risk management framework mandated by Article 6 and sets specific obligations relevant to credential management. Two provisions matter most for identity controls.

  • 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." That language codifies the least-privilege principle as a legal duty.
  • Article 9(4)(d) requires 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." The provision names strong authentication, standards-based mechanisms, and cryptographic key protection.

The text points operations teams toward phishing-resistant standards such as FIDO2/WebAuthn and to "dedicated control systems" — controls that map onto tools commonly referred to as privileged access management, session recording, just-in-time provisioning, and credential vaulting. The European Banking Authority and ESMA's Regulatory Technical Standards under DORA add sector-level guidance that reinforces Article 9's baseline.

Credential compromise as an operational-resilience failure

Viewed through DORA’s operational-resilience lens, stolen credentials are not a single security event but a sustained threat to continuity. IBM's Cost of a Data Breach Report (2025) cited an average dwell time of 186 days between compromise and detection, followed by another 55 days on average to contain the breach. That prolonged, invisible presence is precisely the interruption to operational continuity DORA seeks to prevent.

The mechanics were made concrete in January 2026 when a threat actor used the credentials of one civil servant to access Ficoba, France’s interministerial bank-account registry. Using that single account, the attacker extracted data on 1.2 million bank accounts — including IBANs, account holder names and addresses, and tax identification numbers. The system was taken offline, operations were disrupted, and the incident was reported to CNIL. The published account emphasized that the attack required no technical sophistication.

Under DORA, a credential-driven incident of that scale would also trigger Article 19 mandatory reporting: an initial notification within four hours of classification (and no later than 24 hours after detection), an intermediate report within 72 hours, and a final report within one month.

Third-party credentials and the Santander–Snowflake example

DORA’s compliance perimeter explicitly covers third-party ICT providers. The May 2024 incident referenced in public reporting shows why. Attackers used credentials stolen from employees of Snowflake to access a database containing customer and employee data for Santander across Spain, Chile, and Uruguay. Those credentials had been harvested months earlier by infostealer malware on contractor workstations, and none of the compromised Snowflake accounts had multi-factor authentication enabled.

Under DORA, a financial entity whose critical ICT provider suffers a credential-based breach faces regulatory exposure: institutions must contractually require equivalent authentication standards from providers and audit vendor compliance. A vendor’s password-policy gap is therefore a regulatory liability for the contracting financial entity.

Practical controls that close the Article 9 gap

The source lays out four structured control areas aligned to Article 9 and operational realities.

  • Phishing‑resistant MFA first: FIDO2/WebAuthn hardware keys, passkeys, and platform authenticators are recommended; SMS and TOTP one‑time codes are described as inadequate against current Adversary-in-the-Middle phishing techniques.
  • Enforce least privilege: Just‑in‑time access provisioning, immediate deactivation on offboarding, and removal of standing privileges reduce the blast radius when credentials are stolen.
  • Vault credentials: Service account passwords, API keys, and privileged credentials should live in an encrypted, access‑controlled vault rather than informal channels. Vaulting produces an auditable trail.
  • Continuous monitoring: Automated alerts for anomalous logins, unusual geolocations, off‑hours access, and lateral movement patterns are essential to shorten the 186‑day dwell time that drives operational risk.

The vendor that authored the source, Passwork, positions its self‑hosted password manager as a response to these needs: ISO/IEC 27001 certified, deployable on‑premises, supporting biometric and passkey MFA, SAML SSO and LDAP integration, role‑based permissions inherited from AD/LDAP groups, encrypted vault sharing, and tamper‑evident audit logs exportable for compliance reporting and SIEM integration. Those product claims align with the evidence-focused approach DORA requires.

How technologists, regulators, and procurement leaders are affected

  • Technologists and security teams: Expect operational priorities to shift toward deploying phishing‑resistant MFA (FIDO2/WebAuthn), JIT provisioning, credential vaulting, and continuous monitoring to shorten dwell times and produce demonstrable audit trails.
  • Policymakers and regulators: Supervisory consequences now attach to insufficient credential controls; Article 9(4)(c) and 9(4)(d) provide clear legal hooks, and Article 19 enforces rapid incident reporting timelines.
  • Procurement and third‑party risk officers: Contracts must require equivalent authentication standards from critical ICT providers and include rights to audit compliance; a vendor’s weak password posture converts into the financial entity’s regulatory liability.

DORA has reframed credential management from a technical hygiene problem into a verifiable financial‑risk control. The regulation’s text — particularly Articles 9(4)(c) and 9(4)(d) — is explicit about least privilege, strong authentication, and cryptographic key protection. For institutions operating in the EU, the immediate task is procedural and evidentiary as much as technical: audit credential controls against Article 9, document the findings, and have the evidence ready before a regulator asks.

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