The Attacker Who Looks Like a Legitimate User
When a threat actor enters a corporate network using a valid username and password, most financial institutions have no immediate control that stops them. The intruder appears authorised, moves laterally, escalates privileges, and quietly maps critical systems. According to IBM's Cost of a Data Breach Report (2025), attackers spend an average of 186 days inside a network before the breach is even identified — and a further 55 days to contain it. By that point, the operational damage is done and the regulatory clock has begun.
On January 17, 2025, the Digital Operational Resilience Act (DORA) entered into application across the EU. Its Article 9 converts credential security into a binding financial risk control, with direct supervisory consequences for institutions that fall short. The question is no longer whether an institution's authentication posture reflects best practice — it is whether that posture meets the law, and whether the institution can demonstrate it.
The Threat Landscape DORA Was Designed to Counter
Stolen credentials are the single largest initial access vector in 2025, responsible for 22% of all data breaches according to Verizon's Data Breach Investigations Report. For financial institutions, the sector-specific cost of a credential-based breach averages $5.56 million per incident, per IBM's Cost of a Data Breach Report — down from $6.08 million in 2024, but still the second-highest figure of any industry globally.
The supply side of credential theft has been industrialised. Initial Access Brokers sell verified corporate network access for an average of $2,700, with 71% of listings including privileged credentials, according to Rapid7 research — pre-packaged access requiring no technical skill to exploit. Infostealers including 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. It reflects a documented, ongoing threat to the operational continuity of European financial markets.
What DORA Article 9 Actually Requires
Article 9 — titled Protection and Prevention — sits within the ICT risk management framework mandated by Article 6. It sets out specific technical and procedural obligations. Two provisions bear directly on credential management.
Article 9(4)(c): Least-Privilege Access as a Legal Obligation
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 statute, not guidance. Just-in-time (JIT) access provisioning — granting elevated permissions only for the duration of a specific task — eliminates the standing privileges that make credential theft so damaging. Dormant accounts following offboarding must be deactivated immediately; they remain among the most common and most avoidable attack vectors.
Article 9(4)(d): Strong Authentication and Cryptographic Key Management
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."
In operational terms, this means:
- Multi-factor authentication (MFA) is mandatory. The reference to "relevant standards" points directly to FIDO2/WebAuthn — currently the most widely deployed authentication standard 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, not an optional security measure.
- Privileged access management (PAM) tools are not named explicitly in the regulation, but the controls they deliver — session recording, JIT access provisioning, privileged credential vaulting — map directly onto the "dedicated control systems" the regulation describes.
The European Banking Authority (EBA) and ESMA's Regulatory Technical Standards under DORA provide additional specificity on ICT risk management, reinforcing the Article 9 baseline with sector-specific implementation guidance.
A Compromised Credential Is an Operational Resilience Failure
DORA's stated purpose is to ensure financial entities can withstand, respond to, and recover from ICT disruptions. Viewed through that lens, a credential compromise is not merely a security incident — it is a sustained, invisible threat to operational continuity. With a 186-day average dwell time, an attacker using stolen credentials produces no discrete security event; they simply appear to be a legitimate user for months.
The breach of France's national bank registry in January 2026 illustrates the mechanics. 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, registry operations were disrupted, and the incident was reported to France's data protection authority, CNIL. No technical sophistication was required.
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. Those 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 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 Programme
Meeting Article 9's requirements calls for a structured programme across four areas.
1. Deploy Phishing-Resistant MFA First
FIDO2/WebAuthn-based authentication — hardware security keys, passkeys, and platform authenticators — should be enforced for all users, with particular rigour on privileged accounts and remote access paths. SMS and TOTP-based one-time passwords are not adequate against current AiTM attack techniques.
2. Enforce Least-Privilege Access
JIT provisioning eliminates standing privileges. Accounts must be deactivated immediately on offboarding; dormant accounts remain one of the most common and most avoidable attack vectors in enterprise environments.
3. 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 — both fatal flaws under DORA's documentation requirements.
4. 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 share the same foundation: how credentials are stored, shared, accessed, and monitored. Without structure at that layer, even well-designed policies fail at execution.
Compliance Is as Much an Evidence Problem as a Technical One
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.
The institutions that navigate enforcement most effectively will be those that can produce documentation on demand — audit logs, permission histories, offboarding records, and MFA enforcement evidence. A structured, tamper-evident activity history is a substantively stronger response to a regulator than a policy document alone.
Operational resilience begins with identity, and identity begins with controlling who holds the keys. Institutions should audit their credential controls against Article 9, document the findings, and have the evidence ready before a regulator asks.
Source: BleepingComputer