DORA makes authentication a core control for customer resilience

At a glance

What this is: This Descope post argues that DORA turns authentication into a cross-cutting control for resilience, auditability, and customer-facing risk reduction.

Why it matters: For IAM and NHI practitioners, it shows why identity controls must support both compliance evidence and practical resistance to phishing, account takeover, and third-party risk.

By the numbers:

• DORA has been fully enforceable since January 17, 2025.
• Major incidents require initial notification within 4 hours, intermediate reports within 72 hours, and final reports within one month.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Descope's analysis of DORA authentication and MFA strategy

Context

DORA has moved authentication from a user-experience decision to an operational resilience control. For financial institutions and insurers, the issue is not only whether users can sign in, but whether identity systems can prove access decisions, withstand phishing and session abuse, and support incident reporting across internal and third-party environments.

That matters for NHI governance because customer identity patterns often mirror the same weak assumptions found in service accounts, automation, and delegated access. When access controls are rigid, brittle, or poorly logged, they create compliance friction without materially reducing risk. The article’s starting point is typical for regulated organisations, but the real gap is broader than MFA choice alone.

As DORA matures into an ongoing operational requirement, teams need to treat authentication as part of resilience engineering rather than a final compliance layer. The practical question is whether identity controls can adapt to risk, preserve audit trails, and still hold up when regulators or testers simulate real attack conditions.

Key questions

Q: How should financial institutions balance DORA compliance with customer authentication experience?

A: Treat compliance and experience as linked design goals, not competing outcomes. Use stronger factors for risky actions, not every login, and rely on contextual signals to avoid unnecessary prompts. That approach reduces friction while still improving resilience, auditability, and phishing resistance across regulated access paths.

Q: When does MFA help under DORA, and when is it not enough?

A: MFA helps when it is resistant to phishing, replay, and session abuse, and when logs show how it was used. It is not enough when factors are reusable, poorly bound to the session, or applied without risk context. DORA expects controls that reduce incident likelihood and support investigation.

Q: What is the difference between adaptive authentication and phishing-resistant MFA?

A: Adaptive authentication changes the challenge based on risk signals such as device, location, or behaviour. Phishing-resistant MFA changes the quality of the factor itself so stolen secrets are harder to reuse. The two controls solve different problems and work best together for regulated identity flows.

Q: Why do authentication logs matter so much under DORA?

A: Because incident reporting and resilience testing depend on evidence. Logs show who authenticated, from where, with what method, and what action followed. Without that chain of record, teams cannot prove control effectiveness, reconstruct suspicious activity, or satisfy reporting expectations after an event.

Technical breakdown

Why DORA pushes authentication into resilience architecture

DORA does not treat authentication as a standalone login feature. It sits inside ICT risk management, third-party oversight, incident reporting, and resilience testing, which means identity controls must do more than verify a user once. They need to produce evidence, constrain access paths, and support recovery when controls fail. In practice, this shifts authentication into a control plane for operational resilience, especially where customer portals, partner systems, and delegated service access overlap. For NHI programmes, the same pattern applies to service accounts and API access: if you cannot prove who or what accessed a system, compliance and containment both suffer.

Practical implication: Map authentication controls to resilience and evidence requirements, not just login success rates.

Adaptive and phishing-resistant MFA under DORA

The article highlights two important distinctions. Adaptive MFA adds challenge only when signals suggest higher risk, such as a new device, suspicious IP reputation, or impossible travel. Phishing-resistant MFA, including passkeys and browser-bound magic links, reduces the value of credential capture because the secret is not reusable in the same way as SMS or email OTP. These are different controls with different failure modes. Adaptive MFA helps with context-driven friction. Phishing-resistant methods address credential theft. For NHI governance, the lesson is that ephemeral access and stronger authentication still need proof of binding between the credential, the device, and the request.

Practical implication: Prefer phishing-resistant factors for higher-risk flows and use adaptive challenges to reduce unnecessary friction.

Audit trails are part of the control, not a side effect

DORA incident handling depends on reconstruction. That means logs must capture who authenticated, how they authenticated, from where, and what action followed. The article frames this as an audit requirement, but the deeper point is that identity telemetry becomes the evidence layer for both detection and regulatory reporting. Without structured event records, teams cannot distinguish benign anomalies from compromise, especially when third-party systems or partner access are involved. For NHI environments, the same expectation applies to automation: access events should be attributable, time-bound, and reviewable end to end.

Practical implication: Require identity logs that support investigation, reporting, and access review before you expand or change auth flows.

Threat narrative

Attacker objective: The attacker seeks unauthorised access that can be monetised through account takeover, fraud, or data exposure while avoiding detection long enough to challenge incident response.

1. Entry begins with credential theft or phishing that targets customer authentication paths, including reusable OTPs or weak password flows.
2. Escalation occurs when the attacker replays the stolen identity to bypass poorly contextualised MFA or session controls.
3. Impact follows when the intruder reaches regulated customer data, triggers an account takeover, or creates an incident that must be reported under DORA.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

DORA reframes authentication as resilience infrastructure, not a compliance accessory. Identity controls now have to satisfy auditability, third-party assurance, and incident reporting as one connected discipline. That makes login design part of operational risk management, especially in environments where customers, partners, and automation all touch the same services. Practitioners should govern authentication as an operational control with evidence attached.

Phishing-resistant MFA should be treated as the default control for high-value access paths. SMS and email OTPs may remain in circulation, but they are poorly aligned with the threat model regulators now expect teams to withstand. Passkeys, device-bound challenges, and contextual step-up reduce the opportunity for replay and social engineering. Practitioners should reserve weaker factors for low-risk fallback only.

Adaptive authentication creates what can be called an identity blast radius model. When access decisions change based on device, location, and behaviour, teams can limit the damage from a single compromised credential without imposing universal friction. This is especially relevant where NHI and customer access patterns overlap in shared platforms. Practitioners should design for variable privilege and variable challenge, not one static login path.

Auditability is now a design requirement, not a post-incident afterthought. DORA’s reporting windows and test expectations mean teams need logs that reconstruct decisions quickly and defensibly. If identity telemetry cannot show who, how, and from where access occurred, the organisation is left with compliance exposure even when no breach is confirmed. Practitioners should make forensic completeness a release criterion for auth changes.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• For related context: 52% of companies can track and audit the data their AI agents access, so the remaining 48% still operate with a compliance and investigation blind spot according to AI Agents: The New Attack Surface report; pair that gap with the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs to tighten identity evidence and review.

What this signals

DORA will keep pushing identity teams toward measurable control effectiveness rather than broad claims of compliance. In practice, that means the next maturity step is not simply adding more MFA, but proving that access methods, audit trails, and third-party dependencies can survive a real incident review. For regulated environments, the direction is toward evidence-rich identity operations tied to the NIST AI Risk Management Framework-style governance mindset, even when the subject is not AI.

Identity evidence debt: organisations that cannot reconstruct authentication events quickly will face growing pressure as regulators expect better incident detail and faster reporting. The operational answer is to centralise logs, tighten exception management, and align customer authentication changes with change control. That also helps NHI programmes, where service account and delegated access visibility often lags behind human identity controls.

For practitioners

• Prioritise phishing-resistant factors for regulated journeys Move passkeys, device-bound links, or equivalent methods into customer and partner flows that would cause material harm if compromised. Keep SMS and email OTP only as fallback where business constraints still require them, and document the exception path.
• Add contextual step-up to sensitive actions Trigger additional authentication for high-risk events such as payment changes, security setting updates, new device access, or unusual geolocation. Use device reputation, IP reputation, and transaction sensitivity to reduce unnecessary prompts while protecting critical actions.
• Build audit logs for regulatory reconstruction Capture authentication method, device details, IP data, country of origin, action type, and timestamp for each meaningful identity event. Ensure the record can support both incident reporting and after-the-fact control validation.
• Test authentication under realistic attack paths Include phishing, credential stuffing, session hijacking, and MFA bypass scenarios in resilience testing so controls are evaluated against actual adversary behaviour rather than policy intent alone.
• Review third-party identity dependencies Inventory external identity providers, authentication services, and partner access paths that participate in customer journeys. Confirm contractual logging, audit rights, and evidence retention before they become a regulatory weak point.

Key takeaways

• DORA turns authentication into a resilience requirement, which means identity controls must prove both security and auditability.
• Weak, reusable factors create regulatory and operational risk because they are harder to defend against phishing, replay, and session abuse.
• Teams should prioritise phishing-resistant MFA, contextual step-up, and reconstructable logs before they expand or redesign regulated access flows.

Key terms

• Phishing-resistant MFA: Multi-factor authentication that cannot be easily replayed after a user is tricked into giving up a code or credential. It usually relies on device-bound or cryptographic proof rather than shared secrets, which makes it materially stronger than SMS or email OTP in regulated environments.
• Adaptive authentication: An authentication approach that changes the challenge based on risk signals such as device, location, reputation, or behaviour. It reduces unnecessary friction for low-risk access while increasing scrutiny when the request looks abnormal or high impact.
• Identity telemetry: The event data generated by authentication and access decisions, including method, device, location, and action context. In practice, it is the evidence layer that supports investigation, compliance reporting, and security tuning across human and non-human identities.

Deepen your knowledge

DORA authentication strategy is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is aligning customer identity controls with regulatory resilience requirements, it is worth exploring.

This post draws on content published by Descope: How DORA Impacts Your Auth and MFA Strategy. Read the original.