Skip to content
All posts

FIDO2 Keys for DORA Compliance: What DORA Requires

September 26, 2026 · PlayCISO
TL;DR · the short version

DORA (the EU Digital Operational Resilience Act) sets ICT risk-management, access-control and resilience requirements for banks, insurers, investment firms and their critical ICT third parties. Like NIS2 it is technology-neutral, but its emphasis on strong authentication, least privilege for privileged accounts, and operational resilience makes FIDO2/WebAuthn — phishing-resistant hardware keys and passkeys — a natural fit. This guide maps FIDO2 to DORA's identity and access-management expectations, explains why device-bound authenticators matter for privileged financial-system access, and gives a rollout order aligned to DORA's risk-based approach.

Put it into practice
See what DORA and its RTS require for authentication
The exact DORA and RTS wording on strong authentication, which users need phishing-resistant MFA first, and a phased rollout plan you can copy.
Open the MFA planner

DORA — the EU Digital Operational Resilience Act — is the financial sector's counterpart to NIS2, and it is now the baseline for banks, insurers, investment firms and the critical ICT third parties that serve them. It never says "FIDO2." What it does require is robust ICT risk management, strong authentication, least-privilege control of privileged accounts, and demonstrable operational resilience. Phishing-resistant FIDO2/WebAuthn authentication supports all four, which is why it shows up in so many DORA readiness plans.

The DORA angle: strong authentication plus resilience

Two DORA themes pull toward FIDO2. First, strong authentication and identity/access management: DORA expects financial entities to prevent unauthorised access to ICT systems, and origin-bound FIDO2 credentials defeat the phishing and adversary-in-the-middle attacks that OTP and push MFA do not. Second, operational resilience: DORA is fundamentally about staying operational under stress, and an authentication programme where every user holds two or more authenticators is inherently more resilient to lockout and device loss than a single-factor or single-device scheme.

Mapping FIDO2 to DORA

  • Strong authentication: FIDO2 is phishing-resistant by construction — the strongest, most defensible answer to "how do you authenticate access to critical financial systems?"
  • Privileged access: device-bound hardware keys for operators of core banking, trading and payment infrastructure prevent silent credential theft off endpoints.
  • Third-party risk: DORA extends to critical ICT third parties — requiring FIDO2 for their access to your systems is an auditable third-party control.
  • Resilience: multiple registered authenticators per user reduce lockout risk and support continuity expectations.

A DORA-aligned rollout order

  1. Privileged financial-system access. Hardware security keys for admins and operators of core banking, payments and trading platforms.
  2. Remote and third-party access. Enforce FIDO2 at the identity provider for anything reachable externally, including vendor portals.
  3. General workforce passkeys. Synced passkeys for primary IdP sign-in across staff.
  4. Resilience and cleanup. Two authenticators per user; remove SMS/OTP fallback on hardened accounts.

Evidence to keep

DORA is evidence-driven. Keep FIDO2 coverage figures for privileged, third-party and general populations; a register of accounts that still permit a phishable fallback; and the two-authenticator coverage rate. Those map directly to the access-control and resilience questions an examiner will ask.

See the broader FIDO2 & passkeys for the workforce and the FIDO2-for-NIS2 guide; assess your identity exposure with the Identity Risk tool →

Frequently asked questions

Does DORA require FIDO2? No — DORA is technology-neutral. It requires strong authentication and robust IAM; FIDO2/WebAuthn is a leading phishing-resistant way to meet that.

Why does FIDO2 fit DORA? It provides phishing-resistant access, device-bound keys for privileged operators, and lockout resilience when users hold multiple authenticators.

Does DORA cover ICT third parties? Yes — requiring FIDO2 for third-party access to your systems is a concrete DORA-aligned control.

Where do we start? Privileged access to core financial systems with hardware keys, then remote/third-party access, then workforce passkeys.

Frequently asked questions

How does FIDO2 support DORA regulations?

DORA is technology-neutral, but it requires financial entities to implement strong authentication and robust identity and access management and to stay operationally resilient — and phishing-resistant FIDO2/WebAuthn supports all of that. It provides origin-bound credentials that defeat phishing and adversary-in-the-middle attacks, device-bound hardware keys for operators of core banking, payments and trading systems, an auditable control for the third-party and remote access DORA extends oversight to, and — with two or more authenticators per user — resilience against lockout. Start with privileged access to critical financial systems, then remote and third-party access, then the workforce with passkeys, and keep coverage evidence for examiners.

Why does FIDO2 fit DORA especially well?

DORA pairs strong authentication with operational resilience. FIDO2 delivers phishing-resistant access (origin-bound credentials that cannot be relayed), device-bound hardware keys for privileged financial-system operators, and — when users hold two or more authenticators — resilience against lockout, which supports DORA's continuity expectations.

Does DORA cover our ICT third parties too?

Yes. DORA extends oversight to critical ICT third-party providers, and financial entities are expected to manage third-party access risk. Requiring phishing-resistant FIDO2 sign-in for third-party and remote access to your systems is a concrete, auditable way to reduce that risk.

Where do we start for DORA?

Privileged and administrative access to core banking, trading and payment systems first, with device-bound hardware keys; then remote and third-party access; then the general workforce with passkeys. Remove phishable fallbacks on hardened accounts and register at least two authenticators per user.

See what DORA and its RTS require for authentication
The exact DORA and RTS wording on strong authentication, which users need phishing-resistant MFA first, and a phased rollout plan you can copy.
Open the MFA planner

Ready to practise the decisions these articles describe?

Run your first Cyber War Room free →

Pro

🖤 Black Friday: new customers get 3 months of Pro for $5, then $5/month. Ends 30 Nov. Claim 3 months for $5 →