Do Passkeys Satisfy DORA and NIS2? What European Organisations Need to Check

DORA has been in force since January 2025. NIS2’s transposition deadline passed in October 2024, with full compliance required by October 2026.

The first ICT register submissions under DORA were collected in April 2025. Regulators are supervising now, not preparing to supervise.

Across European financial services and critical sectors, security teams have deployed or are deploying passkeys as their passwordless answer. That is largely the right call. The authentication security question is settled: passkeys are phishing-resistant, FIDO2 compliant, and increasingly the enterprise default.

The compliance question is not settled.

DORA and NIS2 ask about vendor dependencies, data sovereignty, third-party risk registers, and concentration risk. These questions were written before passkeys existed. Most organisations deploying passkeys have answered the security question but have not yet worked through the compliance one. This article does that work.

What DORA requires from your authentication infrastructure

DORA applies to approximately 22,000 financial entities across all 27 EU member states: banks, insurers, investment firms, payment institutions, crypto-asset providers, and their ICT suppliers. Size does not exempt organisations. The regulation is built around five pillars, two of which directly touch authentication.

ICT risk management requires financial entities to:

• Maintain strong authentication policies with mandatory annual review
• Classify and document all information assets
• Implement multiple layers of control across ICT systems

Third-party risk management requires financial entities to:

• Maintain a register of every external ICT vendor, including authentication providers
• Assess concentration risk from dependency on any single vendor for a critical function
• Ensure contracts include audit rights, SLAs, termination rights, and incident notification procedures

The penalty exposure is significant. Serious violations carry fines up to 10% of annual turnover or €10 million. This is not a tick-box exercise.

UK readers: DORA does not apply post-Brexit. The UK equivalent is PS24/16, published by the FCA, PRA, and Bank of England in November 2024, effective January 2025. It creates a parallel framework for designating critical third parties to the UK financial sector. The authentication architecture implications are identical.

What NIS2 requires from your authentication infrastructure

NIS2 is broader than DORA and, unlike DORA, is a directive — meaning full compliance is required by October 2026, with enforcement varying by member state.

It covers healthcare, energy, transport, digital infrastructure, public administration, and financial services: essentially any organisation operating in a sector that matters to the functioning of EU society. Where NIS2 and DORA overlap for a financial institution, DORA takes precedence as the more specific regulation.

The authentication requirement in NIS2 is unusually direct. Article 21(2)(j) explicitly requires the use of multi-factor authentication and continuous authentication to protect network and information systems. Not “should consider.” Not “where appropriate.” Requires.

In June 2025, ENISA published nearly 200 pages of technical guidance clarifying what NIS2 compliance looks like in practice, including specific MFA implementation standards for different system types, vendor oversight methodologies, and supply chain security assessment requirements.

NIS2 also explicitly requires organisations to assess and manage supply chain and third-party security: the same vendor dependency question DORA raises, applied across a much wider set of sectors.

Fines under NIS2 reach up to €10 million or 2% of global annual turnover. Incident reporting is mandatory within 24 hours of a significant event.

Three things your passkey deployment needs to document

Passkeys meet the authentication method requirements of both DORA and NIS2. NIST SP 800-63-4, finalised July 2025, classifies passkeys as AAL2 compliant, a recognised standard that regulators reference. That is not the gap.

The gap is in what sits around the authentication method: the vendor infrastructure it depends on, the data it stores, and your organisation’s ability to demonstrate end-to-end control of the ICT chain. Here is what needs to be documented.

1. Your authentication vendor dependencies

Passkeys sync and recover through Apple’s iCloud Keychain or Google Password Manager. Under DORA, both are ICT third-party providers. In November 2025, the European Supervisory Authorities designated 19 ICT providers as critical under DORA, including major cloud platforms. Once designated, these providers are subject to direct EU supervisory oversight.

If your employee authentication recovery runs through iCloud or Google, that dependency belongs in your ICT register. Your regulator can now ask about it directly.

2. Personal data in your authentication databases

Passkeys eliminate passwords. They do not eliminate user accounts. Every service a user authenticates with still holds their email address or username in a database. Under GDPR, email addresses are personal data. Under NIS2, personal data held in critical infrastructure systems requires appropriate security measures.

The email address sitting alongside a passkey record in your authentication database is a regulated data point, even if the login itself is passwordless. Your GDPR data mapping should reflect what authentication databases hold, not only what is transmitted at login.

3. Concentration risk at the authentication layer

DORA requires financial entities to assess and manage concentration risk: the risk of depending on a single vendor for a critical function. Authentication recovery is a critical function. If that recovery path runs through a single vendor cloud, that is a concentration risk item requiring formal assessment and documentation in your ICT risk management framework.

Verizon’s 2025 Data Breach Investigations Report found that third-party involvement in financial services breaches doubled year-over-year, from 15% to 30%. The risk is not theoretical. It is measured and growing.

What architecture satisfies these requirements most cleanly

The compliance challenge with passkeys is not the authentication method. It is the vendor infrastructure underneath it. The question regulators are asking is: who controls the recovery path, and what is your dependency on them?

Zero-knowledge authentication built on distributed infrastructure answers that question differently.

On the ICT register and concentration risk: WWPass does not depend on any of the 19 designated critical ICT providers. No Apple, no Google in the authentication or recovery chain. The ICT register entry for authentication has no designated critical provider dependency to assess or justify. Concentration risk at the authentication layer is structurally removed rather than managed.

On personal data in authentication databases: At login, services receive only a PUID, an opaque identifier unique to that user-service pair. The user’s email address, provided once at registration, is not transmitted during login and is not stored by every service they authenticate with. Fewer personal identifiers in circulation means a smaller GDPR data mapping footprint and a cleaner NIS2 compliance posture.

On demonstrating end-to-end control: When every element of the authentication architecture, including storage, recovery, and key management, sits within a distributed system with no external vendor dependency, demonstrating control to a regulator is straightforward. There is no third-party cloud whose policies, jurisdiction, or operational status affects your compliance posture.

WWPass hardware keys also operate at NIST AAL3, the highest authentication assurance level, requiring cryptographic hardware plus PIN or biometric. For high-privilege access and the most sensitive regulated environments, that exceeds what both frameworks require.

DORA and NIS2 authentication requirements: compliance mapping

WWPass Key is the only key that locks both your digital identity and your data, not just your login.

A compliance checklist for your authentication review

Before signing off on your authentication posture under DORA or NIS2, your team should be able to answer yes to each of the following:

1. Have you identified which vendor handles passkey sync and recovery in your deployment?
2. Is that vendor on the DORA critical ICT provider list published November 2025?
3. Is the authentication vendor dependency documented in your ICT register?
4. Have you conducted a concentration risk assessment for your authentication recovery path?
5. Does your GDPR data mapping include email addresses held in authentication databases?
6. Can you demonstrate end-to-end control of your authentication chain to a regulator on request?
7. Does your authentication architecture meet AAL2 as a minimum, and AAL3 for high-privilege access?
8. Do your ICT vendor contracts include audit rights, SLAs, termination rights, and incident notification procedures?

If the answer to any of these is no or not yet, the gap is worth closing before your regulator asks.

DORA and NIS2 do not require you to replace passkeys. They require you to document, assess, and control every dependency in your authentication chain. If your authentication recovery runs through a vendor cloud that regulators now supervise directly, that is a compliance conversation waiting to happen. Better to have it on your terms than on theirs.

See how WWPass maps to DORA and NIS2.