DORA Turns Credential Management Into a Financial Risk Control

The EU’s Digital Operational Resilience Act has changed how financial institutions need to treat passwords, privileged access, and authentication. Under DORA, weak credential management is no longer only a cybersecurity weakness. It can become a regulatory resilience failure if it allows attackers to disrupt financial services or access critical ICT systems.

DORA entered into application on January 17, 2025, and applies across the EU financial sector. Its goal is to make banks, insurers, investment firms, and other financial entities more resilient against ICT disruptions, including cyberattacks and third-party technology failures.

Article 9 is especially important for identity and access security. It requires financial entities to limit logical and physical access to what users need for approved functions, and it requires strong authentication mechanisms based on relevant standards and dedicated control systems.

Why credentials now count as operational resilience

Credential attacks are dangerous because they often look like normal user activity. A threat actor who signs in with a real username and password may not trigger the same alarms as malware or exploit traffic.

That creates a long detection window. IBM’s 2025 Cost of a Data Breach Report says compromised credentials took an average of 186 days to identify and 60 days to contain. Across all breach types, IBM puts the average identification and containment timeline at 241 days.

For a financial institution, that is not only a security problem. It means an attacker may have months to move laterally, escalate privileges, study payment systems, access sensitive records, or prepare service disruption before the organization understands the scope.

At a glance

Issue	Why it matters under DORA
Weak passwords	Increase the chance of credential compromise
Shared admin accounts	Make accountability and audit evidence harder
Standing privileges	Let stolen accounts cause wider damage
Missing MFA	Makes phishing and infostealer theft more useful
SMS or TOTP-only MFA	Can be bypassed by modern phishing kits
Vendor credentials	Expand the institution’s regulatory exposure
Poor audit logs	Make it harder to prove controls worked
Manual credential sharing	Creates hidden access paths with little evidence

What Article 9 requires in practice

Article 9(4)(c) requires financial entities to limit access to information assets and ICT assets to legitimate and approved functions. In operational terms, this means least privilege must become a working access model, not just a policy document.

Article 9(4)(d) requires strong authentication mechanisms and protection measures for cryptographic keys. It also links encryption to approved data classification and ICT risk assessment processes.

This points financial institutions toward stronger controls such as phishing-resistant MFA, privileged access management, encrypted credential vaulting, access reviews, session controls, and detailed audit trails. DORA does not name every tool category, but the required outcomes are clear.

Why MFA must move beyond basic codes

Traditional MFA still helps, but attackers have adapted. Adversary-in-the-middle phishing kits can capture passwords and some one-time codes in real time, then replay them into a legitimate session.

That is why financial entities should prioritize phishing-resistant authentication for privileged accounts, remote access, administrators, and critical business functions. FIDO2, WebAuthn, passkeys, hardware security keys, and platform authenticators offer stronger protection than SMS-based codes.

The regulation’s language about strong authentication based on relevant standards makes this shift important. A financial institution needs to show not only that MFA exists, but that the authentication method matches current risk.

Why stolen credentials remain a major breach driver

Verizon’s 2025 Data Breach Investigations Report analyzed 22,052 incidents and 12,195 confirmed breaches. The report continues to show stolen credentials as a major part of breach activity across sectors and attack patterns.

The credential economy has also matured. Infostealers collect browser passwords, session cookies, cloud tokens, VPN credentials, and developer secrets at scale. Initial access brokers then sell working access to corporate networks, often giving ransomware and espionage groups a shortcut into victim environments.

This is the threat chain DORA’s resilience model tries to interrupt. If attackers can use valid access for months, the organization has not only lost secrecy. It has lost control over operational continuity.

Third-party credentials are part of the same risk

DORA also expands the problem beyond internal users. ICT third-party service providers, contractors, outsourced help desks, cloud platforms, and managed service providers can all create credential exposure.

A vendor account with weak authentication can become a path into a financial institution’s systems or data. That makes third-party identity controls part of the institution’s own resilience posture.

Financial entities should contractually require strong authentication, least privilege, logging, incident reporting, and access revocation from ICT providers. They should also test whether providers can prove those controls during audits or incidents.

What a DORA-ready credential program should include

• Phishing-resistant MFA for privileged, remote, and high-risk access.
• Least-privilege permissions with regular access reviews.
• Just-in-time access for administrative tasks.
• Encrypted credential vaulting for shared accounts, service accounts, API keys, and admin passwords.
• Immediate offboarding that revokes account and vault access.
• Central logging for credential access, sharing, password changes, and permission updates.
• Alerts for unusual login locations, impossible travel, off-hours access, and lateral movement.
• Third-party credential requirements written into contracts.
• Evidence packs that compliance teams can export during audits.

Why documentation matters as much as tooling

DORA compliance is not only about having controls. Financial entities also need to prove that those controls exist, work, and get reviewed.

A written password policy will not be enough if the institution cannot show who accessed a privileged credential, when access was granted, why it was approved, and when it was revoked. Regulators and incident investigators will look for evidence, not intentions.

This makes audit logs, access histories, SIEM integration, and documented exception handling central to credential governance. Under DORA, missing evidence can create its own compliance problem.

How financial institutions can close the gap

The first step is to inventory credentials. Institutions need to know where human passwords, service account passwords, API keys, SSH keys, database credentials, and emergency accounts exist.

The second step is to remove informal sharing. Credentials should not live in spreadsheets, chat messages, browser profiles, shared inboxes, or personal password managers. Every shared credential needs ownership, encryption, access control, and a revocation path.

The third step is to connect credential management to operational risk. If a stolen password can disrupt payments, trading, customer access, claims processing, or regulatory reporting, it belongs in the resilience program, not only in IT security.

FAQ