DORA makes authentication a core control for customer resilience

At a glance

What this is: This analysis argues that DORA turns customer authentication into a resilience control, with phishing-resistant MFA, auditability, and third-party alignment carrying more weight than simple MFA presence.

Why it matters: IAM teams supporting financial services need to treat authentication design as part of resilience, incident reporting, and partner governance, not just user login experience.

By the numbers:

• DORA has been fully enforceable since January 17, 2025, and non-compliance can carry penalties up to 2% of daily global turnover for up to six months.

Context

DORA has turned customer authentication into a resilience issue, not just an access issue. For financial institutions and insurers, the control question is whether login, step-up verification, and auditability can stand up to real attack conditions and regulatory scrutiny across every customer touchpoint.

The pressure is strongest where legacy MFA still depends on SMS or email OTP, because those methods are easier to phish, harder to evidence, and often too rigid for modern customer journeys. The governance problem is not the presence of MFA, but whether authentication is phishing-resistant, observable, and consistent across internal systems and third-party services.

That makes DORA a useful test case for identity programmes that span human users and external service relationships. The article’s core point is that resilience now depends on how authentication is engineered, logged, and exercised under incident and testing scenarios.

Key questions

Q: What breaks when MFA is configured with weak, phishable factors?

A: Weak factors such as SMS codes, OTP apps, or push-based approvals can satisfy a policy checkbox while still leaving the environment open to phishing, man-in-the-middle, and push bombing attacks. That means the control may look compliant but fail under real attack conditions. Teams should test whether the factor actually binds the login to the user and target service.

Q: Why does DORA treat strong authentication as a resilience requirement for financial entities?

A: DORA treats strong authentication as a resilience requirement because passwords alone are vulnerable to phishing and credential stuffing, and one compromised account can become a wider disruption event. Requiring two factor authentication makes unauthorized access harder, protects sensitive systems, and reduces the chance that a single stolen credential can trigger service interruption or broader operational impact.

Q: What signs show that MFA is failing to meet DORA expectations?

A: The clearest signs are repeated dependence on SMS or email OTP, poor visibility into authentication events, inconsistent controls across channels, and exceptions for third-party identity flows. If the team cannot explain how authentication behaves during phishing or session theft scenarios, then the control is probably too weak to support resilience claims.

Q: How should teams govern authentication when third-party identity providers are involved?

A: They should treat the provider as part of the resilience boundary, not as an external convenience layer. That means inventorying the dependency, confirming audit rights, reviewing logging depth, and testing how the service behaves during incident and recovery scenarios. If the provider handles credential decisions, it belongs inside the governance model.

Technical breakdown

Why DORA pushes authentication into the control plane

DORA treats authentication as part of ICT risk management because access events are also resilience events. If a customer login path cannot be audited, tested, and defended against phishing, credential stuffing, and session hijacking, the institution loses both preventive control and forensic evidence. That is why the regulation reaches beyond simple MFA deployment and into the quality of the authentication method, its logging, and its consistency across channels. In practice, authentication becomes a control plane for incident detection and response, not a front-end convenience layer.

Practical implication: teams need to assess authentication by resilience evidence, not just by MFA coverage.

Why legacy OTP and always-on MFA create a false sense of compliance

Legacy OTP methods can satisfy a superficial reading of MFA while still leaving users exposed to interception, replay, and social engineering. Always-on MFA also adds friction in ways that drive workarounds, which weakens real-world adherence and can hide unsafe behaviour behind a compliant checkbox. DORA’s concern is not whether extra factors exist, but whether they resist current attack paths and remain usable enough to survive production use. That tension is why phishing-resistant methods and step-up logic matter more than static challenge frequency.

Practical implication: replace checkbox MFA thinking with method-level evaluation of phishing resistance and user friction.

How third-party identity services become part of DORA scope

The article correctly extends DORA’s authentication discussion into third-party providers because identity decisions rarely stop at one application boundary. If an external identity provider, fraud signal, or authentication workflow influences who can sign in, then it is part of the institution’s resilience posture. DORA’s third-party requirements therefore apply to the systems that handle credentials, audit trails, and access decisions, not just the bank or insurer’s own code. That makes supplier oversight inseparable from authentication governance.

Practical implication: map every external authentication dependency into third-party risk oversight and audit-rights reviews.

Threat narrative

Attacker objective: The attacker wants to obtain authenticated customer access that can be used for fraud, account takeover, or unauthorized changes while avoiding detection.

1. Entry begins with phishing, credential stuffing, or session hijacking against customer authentication flows that rely on weak or reusable factors.
2. Credential access succeeds when SMS or email OTP, breached passwords, or weak recovery paths let an attacker satisfy the login sequence.
3. Escalation follows when the attacker reuses authenticated access to move into account actions, transfers, claims, or profile changes.
4. Impact appears as unauthorized transactions, account takeover, or an incident record that lacks the audit detail regulators expect.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication has become a resilience control, not an identity convenience. DORA changes the evaluation standard from whether MFA exists to whether it resists modern attack paths and produces usable audit evidence. That shift matters because incident handling, third-party governance, and resilience testing all depend on the quality of authentication outcomes. Practitioners should now judge authentication as part of operational resilience architecture.

Legacy MFA can satisfy policy language while still failing under attack. SMS and email OTP reduce friction for users and increase comfort for compliance teams, but they do not hold up well against phishing, interception, and session theft. The control gap is not lack of MFA presence, but reliance on factors that attackers can still traverse. Practitioners should treat factor quality as the real compliance variable.

DORA exposes an auditability gap in many customer identity programmes. If an organisation cannot reconstruct who authenticated, how they authenticated, and what signals were present, incident reporting becomes slower and weaker. That is especially relevant for organisations that outsource identity decisions to third parties or scattered workflows. Practitioners should regard logging depth as part of resilience, not an afterthought.

Customer authentication and third-party identity services now sit in the same governance frame. DORA’s scope makes outsourced identity decisions subject to the same scrutiny as internal controls because both affect incident response and resilience testing. This is where IAM, vendor oversight, and compliance stop being separate workstreams. Practitioners should align authentication architecture with third-party risk governance rather than manage them in isolation.

Phishing-resistant authentication is now a governance expectation, not an optional enhancement. Passkeys, device-bound factors, and adaptive step-up flows matter because they change the attacker’s ability to turn a stolen credential into usable access. The article’s subtext is that resilience comes from reducing the number of paths an attacker can traverse, not from making every login equally hard. Practitioners should shift design choices toward methods that fail safely under phishing pressure.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: Zero Trust for AI Agents

What this signals

Phishing-resistant authentication is now a resilience requirement: DORA pushes teams to evaluate whether login methods can withstand real attacker paths, not just whether MFA is present. That means customer identity journeys should be designed around device-bound factors, step-up logic, and observable access events rather than static challenge frequency.

Audit trails become part of the control itself: if authentication cannot be reconstructed after an incident, the organisation will struggle to satisfy reporting, triage, and accountability obligations. Teams should treat authentication telemetry as a governance asset, not just a security log.

For practitioners

• Map authentication to DORA pillars Trace each customer and workforce authentication flow to ICT risk management, third-party risk management, incident reporting, and resilience testing so control ownership is explicit.
• Replace weak MFA factors Phase out SMS and email OTP where possible and prioritise phishing-resistant methods such as passkeys, with step-up challenges reserved for risky actions.
• Instrument authentication for auditability Log factor type, device context, IP reputation, country, and user action so incident reports can reconstruct access attempts with evidentiary detail.
• Bring third-party identity services into oversight Include external identity providers, fraud engines, and authentication workflow vendors in contractual audit rights, inventory, and resilience reviews.
• Test login paths against real attack patterns Use phishing, credential stuffing, session hijacking, and MFA bypass scenarios in resilience testing to validate that the customer journey holds under pressure.

Key takeaways

• DORA changes authentication from a front-door control into part of the resilience and incident-response fabric for financial services.
• Weak MFA can still pass compliance checks while leaving organisations exposed to phishing, session hijacking, and account takeover.
• Teams should prioritise phishing-resistant methods, audit depth, and third-party oversight if they want authentication to support DORA in practice.

Key terms

• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
• Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.
• Adaptive Authentication: Adaptive authentication changes the strength of login checks based on context such as device, location, source network, and session history. It helps IAM teams respond to suspicious access without forcing every user through the same high-friction path.
• Operational Resilience: Operational resilience is the ability to keep critical services running or recover them quickly after disruption. In identity-led environments, that depends on authentication services, privilege management, and recovery procedures that can be tested under realistic failure conditions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.