Passkeys and NIS2: One WebAuthn Flag Decides Whether a Passkey Counts as MFA

Yes, a FIDO2 passkey can count as multi-factor authentication under NIS2, but only when the login also checks that the user is present and verified. A passkey proves you hold a device-bound private key, which is one factor. The second factor is the fingerprint, face scan or PIN that unlocks that key locally, and the server only knows that step happened if the authenticator sets the User Verification (UV) flag and your identity provider requires it. Switch that check off, or leave it on “preferred”, and you have a phishing-resistant single factor, not MFA.

That one setting is the difference between a passkey rollout that supports your Article 21 evidence and one an auditor can pick apart.

What NIS2 Actually Requires for Authentication

In plain terms: NIS2 never mentions passkeys. The Directive asks for multi-factor or continuous authentication “where appropriate”. A Commission regulation adds technical detail, but only for eleven types of digital provider. Everything that names passkeys or FIDO2 is advisory guidance.

Article 21(2)(j) of the NIS2 Directive lists “the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.” No technology is named, and the closing qualifier applies to the whole point. Our guide to NIS2 MFA and secure communications requirements covers the full point (j), including the communications limbs.

The technical layer sits in Commission Implementing Regulation (EU) 2024/2690. Its Annex point 11.7.1 requires that users are “authenticated by multiple authentication factors or continuous authentication mechanisms … where appropriate, in accordance with the classification of the asset to be accessed.” Point 11.6.3 adds that entities shall “to the extent feasible use state-of-the-art authentication methods”. The words “passkey”, “FIDO” and “phishing-resistant” don’t appear anywhere in the regulation.

Text	Who it binds	What it says about passkeys
Directive (EU) 2022/2555, Art. 21(2)(j)	All essential and important entities, via national law	Nothing. MFA or continuous authentication, “where appropriate”
Implementing Regulation (EU) 2024/2690, Annex 11.6–11.7	Only DNS, TLD, cloud, data centre, CDN, MSP, MSSP, online marketplaces, search engines, social networks and trust service providers	Nothing by name. Strength must match asset classification; state of the art “to the extent feasible”
ENISA Technical Implementation Guidance (June 2025)	Nobody. Advisory	Lists passkeys; ranks FIDO/WebAuthn as “Strong” MFA
NIS Cooperation Group reference document (June 2026)	Nobody. Advisory	Nothing. “Entities should use multi-factor or continuous authentication where appropriate”

Does this apply to you? If you’re one of the eleven provider types above, the Annex binds you directly. If you’re a hospital, manufacturer or energy operator, your obligation comes from your national transposition law. The NIS Cooperation Group’s reference document on security measures maps each of its objectives back to an Annex point, so the Annex is the practical benchmark either way.

That June 2026 document reduces authentication to one sentence and says nothing about phishing resistance. So “does a passkey satisfy NIS2?” comes down to two questions: is it genuinely multi-factor, and is its strength appropriate for the asset it protects?

Why a Passkey Can Be Two Factors or Only One

In plain terms: the passkey itself is something you have. Whether it becomes MFA depends on whether the server demands proof that you also unlocked it with something you know or are.

At registration, the authenticator creates a key pair bound to the website’s domain. The private key stays in the device’s secure hardware or the platform keychain; the service stores only the public key. At login the server sends a challenge, the authenticator signs it, and the browser refuses to use the key on any domain other than the one it was registered to. That domain binding is why a cloned login page gets nothing usable. It’s also why CISA’s phishing-resistant MFA fact sheet states that “the only widely available phishing-resistant authentication is FIDO/WebAuthn authentication”.

Before the authenticator signs, it can check that a human is present (a tap) and, separately, verify which human (a PIN, fingerprint or face). WebAuthn reports these as two flags in the signed response: User Present (UP) and User Verified (UV). Only UV adds a second factor. The relying party controls this through the userVerification parameter, which takes “required”, “preferred” or “discouraged”. As MDN’s WebAuthn reference documents, the default is “preferred”, under which “the operation will not fail if it does not occur.” Out of the box, then, a passkey login only guarantees one factor.

The US standard is unambiguous on the consequence. NIST SP 800-63B-4, Appendix B states: “If the user is not verified, agencies SHALL treat the authenticator as a single-factor cryptographic authenticator.” Germany’s federal security office reaches the same line in the BSI technical guideline TR-03188 on passkey servers (version 1.0, June 2026). Its “normal” trust level is one factor, possession of the private key. Its “substantial” level counts as two-factor authentication only if the relying party sets userVerification to “required” for both registration and login and checks that the UV flag is set (requirement SBT-1).

That gives you a clean NIS2 test. A passkey login with UV required and enforced is two factors in one gesture: possession of the key plus a biometric or PIN that never leaves the device. With UV optional, it’s a strong single factor: far harder to phish than a password, but not what Annex 11.7.1 describes.

Synced or Device-Bound: Match the Passkey to the Asset

In plain terms: synced passkeys are backed up to a cloud account so they survive a lost phone. Device-bound passkeys never leave one piece of hardware. Both resist phishing, but they aren’t equally strong, and the Annex asks you to match strength to what’s being protected.

Annex points 11.6.2(a) and 11.7.2 both require authentication strength appropriate to the classification of the asset being accessed. That makes the synced versus device-bound choice a classification decision rather than a matter of taste. Three authorities draw the line in the same place:

• NIST accepts synced passkeys at its middle assurance level (AAL2) but states that “syncing violates the non-exportability requirements of AAL3”, its highest level.
• BSI TR-03188 allows only device-bound passkeys at its “high” trust level. Its attacker model AM-6 is precisely credentials synchronised to an untrusted cloud service, and it names synced passkeys as the example.
• Microsoft, in its Entra ID passkey documentation, says to treat synced passkeys “as phishing-resistant credentials but with the same security posture as other unattested authenticators”, and its sample policy restricts IT admins and executives to device-bound keys with attestation enforced.

The mechanism behind all three is the same. A synced passkey is only as strong as the cloud account it syncs through. The UK NCSC, announcing in April 2026 that it now recommends passkeys wherever a service supports them, still notes that syncing relies on “the strength of the authentication protecting the sync account”. If an employee’s personal Apple or Google account falls, your corporate key can go with it. NIST adds that some sync providers let users share keys with other people, which cuts against Annex point 11.5.2(b): link the identity of each user to a single person.

Asset classification	Example systems	Defensible passkey choice
Critical / privileged	Domain and cloud admin, IdP admin, OT engineering workstations, backup consoles	Device-bound only (hardware security key or attested authenticator app), UV required, attestation enforced, separate admin credential per 11.6.2(f)
Sensitive / internet-facing	Email, VPN, remote desktop, finance and HR systems	Synced or device-bound, UV required; synced only if the sync account is managed or itself protected by phishing-resistant MFA
Internal / low	Intranet, ticketing, low-risk SaaS	Synced passkeys acceptable; UV required if the login is meant to count as MFA

Watch your defaults. Microsoft’s documentation states that “if you haven’t opted in to passkey profiles yet and you have attestation enforcement off, synced passkeys are already enabled.” With attestation off, it adds, Entra “can’t guarantee any attribute about a passkey, including if it’s synced or device-bound.” So a “device-bound only” admin policy means nothing unless attestation is enforced. Enforcing it later doesn’t block keys already registered without attestation; those need re-registering.

The BSI’s three trust levels closely mirror the low, substantial and high assurance levels used under eIDAS. If you’re mapping both regimes, our comparison of eIDAS 2 strong authentication and NIS2 Article 21 shows how one identity policy can serve both.

Where Passkey Rollouts Lose Their Phishing Resistance

In plain terms: an attacker doesn’t need to break the passkey if they can go around it. The weak points are account recovery, old login methods left switched on, and Annex rules written with passwords in mind.

1. The recovery path. If a user who loses their phone can reset access with an emailed link or a password, the account is exactly as strong as that fallback. BSI TR-03188 makes this explicit for its “substantial” level: account recovery must reach at least the same trust level, and password- or email-based recovery must not be offered (SBT-4). ENISA’s technical implementation guidance asks entities to “implement secure fallback methods for users who lose access to their MFA methods”. In practice: issue a second registered security key, or route recovery through an identity-verified helpdesk process that issues a temporary access pass.

2. Legacy methods left enabled. Adding passkeys doesn’t remove SMS codes or push approvals, and a proxy phishing page can steer the login to whichever weaker method is still enabled. ENISA ranks push, number matching and app codes as “Medium” MFA, and SMS or email codes as “Last resort”. Enforce passkeys per resource with conditional access, and retire the weaker methods for every user group that has migrated.

3. Annex rules that assume passwords. Several 11.6.2 points still apply to passkeys and need a translation in your policy:

Annex point	What it requires	Passkey translation
11.6.2(c)	Credential change “initially, at predefined intervals and upon suspicion” of compromise	Define a re-registration interval tied to the access review cycle; revoke and re-enrol on suspicion. This point carries no “where appropriate” qualifier
11.6.2(d)	Reset and blocking after a predefined number of failed log-in attempts	Set PIN retry limits on authenticators and lockout thresholds at the IdP
11.6.2(f)	Separate credentials for privileged or administrative accounts	Register a distinct passkey for the admin identity, ideally on a dedicated hardware key
11.6.4	Review authentication procedures and technologies at planned intervals	Review registered authenticators, attestation status and remaining fallback methods

Point 11.6.2(c) is the one most passkey projects miss, because “change your password” seems to have no passkey equivalent. Our analysis of NIST password guidelines vs NIS2 access control explains why this point can’t be waived through documented reasoning, and how a long interval tied to access reviews satisfies it.

Points that do say “where appropriate”, including 11.7.1 itself, come with a release valve. Under Article 2(2) of the Implementing Regulation, an entity that considers such a requirement not appropriate “shall in a comprehensible manner document its reasoning”. If a legacy OT system can’t take a passkey, the answer is a written, risk-based exception, not silence.

What Each Role Should Do Next

CISO / IT security. Set userVerification to “required” for every passkey-protected application, and verify it in the identity provider rather than trusting the authenticator default. Enforce attestation for privileged groups. Remove SMS and email fallbacks from migrated groups, and log which method each login actually used.

Compliance officer. Make sure the authentication policy names which asset classes require device-bound passkeys and which accept synced ones, so it can be traced to 11.6.2(a) and 11.7.2. ENISA’s own evidence list includes an “access control policy outlining how different MFA methods are assigned, including whether phishing-resistant MFA is used”. Add IdP configuration exports and sign-in logs to the evidence file.

SME owner. You don’t need a hardware key for everyone. Synced passkeys with verification turned on, on managed company accounts, are a big step up from passwords plus SMS. Buy hardware keys for the handful of people with admin rights, and two per person so a lost key doesn’t become a password reset.

Board. Authentication failures fall under Article 21, and infringements of Article 21 carry the Directive’s maximum fines:

Entity type	Maximum fine set by Article 34 (at least)	Enforced by
Essential entity	EUR 10,000,000 or 2% of total worldwide annual turnover, whichever is higher	National competent authority
Important entity	EUR 7,000,000 or 1.4% of total worldwide annual turnover, whichever is higher	National competent authority

These are minimum ceilings; member states can set higher ones. Being able to show phishing-resistant MFA on email and admin accounts answers one of the first questions an auditor is likely to ask about point (j). For the wider policy picture, see our guide to NIS2 access control and human resources security.

Frequently Asked Questions

Does NIS2 require passkeys? No. Neither the Directive nor Implementing Regulation 2024/2690 names any authentication technology. They require MFA or continuous authentication where appropriate, at a strength matching the asset. Passkeys are one way to meet that, and ENISA recommends phishing-resistant MFA “wherever possible”.

Does ENISA say passkeys are the strongest form of MFA? Not quite, despite vendor claims. ENISA lists passkeys and FIDO2 security keys as separate items and ranks MFA by properties: no shared secrets, no attacker-in-the-middle exposure, and a private key bound to a domain (FIDO/WebAuthn) or a PKI trust provider. Passkeys share the “Strong” tier with certificate-based authentication.

Is a passkey on a phone with Face ID multi-factor? It can be. The phone holds the key (possession) and Face ID unlocks it (inherence). It counts as MFA only if the service requires User Verification and checks the UV flag on every login.

Do passkeys meet “continuous authentication”? No. A passkey authenticates at login. Continuous authentication is a separate mechanism that re-evaluates the session, such as risk signals or behavioural checks. Article 21(2)(j) treats it as an alternative to MFA, not a feature of passkeys.

The Bottom Line

The law doesn’t give credit for the word “passkey”. It asks whether users are authenticated by multiple factors at a strength appropriate to the asset. Require User Verification, reserve device-bound keys for privileged and critical systems, close every weaker fallback, and write those choices into a policy that maps to Annex 11.6 and 11.7.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive), Articles 21(2)(j), 21(5) and 34(4)–(5). EUR-Lex.
2. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, Article 2 and Annex points 11.3, 11.5, 11.6 and 11.7. EUR-Lex.
3. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 (June 2025), sections 11.6 and 11.7, footnote 95.
4. NIS Cooperation Group, Reference document on security measures for entities under NIS2, version 1.0 (June 2026). European Commission.
5. NIST SP 800-63B-4, Digital Identity Guidelines, Appendix B: Syncable Authenticators. National Institute of Standards and Technology.
6. BSI, Technische Richtlinie TR-03188 Passkey Server, version 1.0 (15 June 2026), sections 3.2.7 and 3.4. Federal Office for Information Security, Germany.
7. Microsoft Learn, How to enable passkeys (FIDO2) in Microsoft Entra ID (updated June 2026).
8. CISA, Implementing Phishing-Resistant MFA, fact sheet (October 2022).
9. UK National Cyber Security Centre, Passkeys are more secure than traditional ways to log in, blog post by Dave Chismon (23 April 2026).
10. MDN Web Docs, PublicKeyCredentialRequestOptions: userVerification property. Mozilla.