Post-quantum FIDO2 WebAuthn passkey migration for sovereign organisations

Post-quantum FIDO2 WebAuthn passkey migration is the process of replacing the elliptic-curve and RSA-based signing algorithms at the core of current passkey authentication with lattice-based post-quantum algorithms, specifically ML-DSA (FIPS 204), so that phishing-resistant credentials remain secure against both classical and quantum adversaries. For European government bodies and regulated sectors, this migration is not a theoretical future project: it is an active risk management obligation that intersects with NIS-2, DORA, GDPR and the emerging eIDAS 2.0 EUDI Wallet framework.

Why today’s FIDO2 algorithms are quantum-vulnerable

The FIDO2 and WebAuthn (W3C) specifications use COSE algorithm identifiers to negotiate the signing algorithm between an authenticator and a relying party. The two dominant defaults, ES256 (ECDSA over P-256) and RS256 (RSA with SHA-256), rely entirely on the hardness of the elliptic-curve discrete logarithm problem and integer factorisation. A sufficiently large quantum computer running Shor’s algorithm breaks both in polynomial time.

The relevant statistic here is the threat horizon: ENISA estimates that a cryptographically relevant quantum computer capable of breaking RSA-2048 could emerge within 10 to 15 years (ENISA, 2023). That window sounds comfortable until you factor in credential longevity. Passkeys enrolled today in a government identity system or a regulated financial institution may remain active, and therefore harvested, for exactly that duration. The attack model that makes this urgent is harvest-now-decrypt-later: an adversary records WebAuthn assertion traffic now and decrypts the signing key later, enabling retrospective account takeover on high-privilege identities whose credentials were never rotated.

What IETF draft-vitap-ml-dsa-webauthn specifies

The IETF draft draft-vitap-ml-dsa-webauthn is the protocol-level answer to this vulnerability. It defines how ML-DSA, standardised by NIST as FIPS 204 (formerly CRYSTALS-Dilithium) in August 2024, is integrated into the WebAuthn credential creation and assertion flows.

Concretely, the draft registers three new COSE algorithm identifiers corresponding to the three ML-DSA parameter sets: ML-DSA-44 (NIST security category 2), ML-DSA-65 (category 3) and ML-DSA-87 (category 5). Relying parties that declare support for these identifiers in their PublicKeyCredentialCreationOptions can instruct a compatible authenticator to generate an ML-DSA keypair at credential registration time. The authenticator attests the new public key using its existing attestation key, which during the transition period may itself still be ECC-based. This creates a nuanced dependency: the credential signing key becomes quantum-safe, but the attestation chain may not be, until hardware vendors issue new attestation certificates signed under ML-DSA.

The draft does not mandate a flag day. Relying parties that do not list ML-DSA identifiers in their supported algorithms will simply never negotiate them with an authenticator, preserving full backward compatibility with the installed base of FIDO2 devices.

Hybrid signatures and backward compatibility

The practical deployment model for the transition period is a hybrid credential: during registration, the authenticator generates both an ECC keypair and an ML-DSA keypair, and the relying party stores both public keys bound to the same credential. During authentication, a quantum-capable relying party verifies the ML-DSA assertion; a legacy relying party falls back to ECC. This is directly analogous to the hybrid TLS approach already being deployed in browsers and is consistent with the hybrid signature guidance in NIST SP 800-208.

For sovereign identity deployments, hybrid mode has a specific governance implication: the transition window during which both algorithm sets are active must be explicitly bounded in policy. An open-ended hybrid mode that runs indefinitely provides no actual quantum protection, because an adversary harvesting traffic during that period only needs the weaker ECC component. The CISO must define a migration completion date and enforce it through authenticator policy in the identity provider configuration, whether that is a self-hosted Keycloak instance, a national identity broker, or an eIDAS-connected node.

Sovereign-compatible hardware security key options

Hardware authenticators are the physical trust anchor in any serious FIDO2 deployment for government or regulated sectors. The post-quantum readiness of these devices is therefore critical.

For sovereign European deployments, OpenSK is particularly relevant because its open-source firmware can be independently audited, compiled and provisioned without dependency on a US vendor’s supply chain or firmware signing infrastructure. Organisations with a requirement to avoid foreign-jurisdiction control over cryptographic key material, a requirement that arises directly from CLOUD Act and FISA 702 exposure risk, should evaluate OpenSK on procurement-grade hardware as a medium-term bridge until commercial keys with certified ML-DSA support become available.

Interaction with eIDAS 2.0 and the EUDI Wallet

The eIDAS 2.0 regulation, formally adopted in 2024, mandates that all EU member states provide citizens and organisations with a European Digital Identity (EUDI) Wallet by 2026. The Architecture Reference Framework (ARF) published by the European Commission governs the cryptographic requirements for wallet-bound credentials and their presentation to relying parties.

The EU HORIZON POSEIDON project (funded under Horizon Europe) is the primary research vehicle investigating how post-quantum cryptography, including ML-DSA and hybrid signatures, should be embedded in digital identity schemes at the level of national eID and the EUDI Wallet. POSEIDON’s outputs are intended to feed directly into future ARF versions, meaning that the algorithm choices made in draft-vitap-ml-dsa-webauthn and FIPS 204 will shape the mandatory cryptographic baseline for public-sector authentication across the EU.

For a Dutch municipality, a Belgian federal agency or a Finnish healthcare authority already deploying FIDO2 as a second factor alongside their national eID scheme, the practical consequence is that post-quantum passkey migration cannot be treated in isolation. The credential formats used for EUDI Wallet presentation (SD-JWT VC, ISO/IEC 18013-5 mdoc) must also support ML-DSA-signed issuer attestations. Organisations that begin hybrid passkey migration now will be better positioned to extend that posture to wallet credentials when the ARF mandates it.

Governance: what auditors under NIS-2 and DORA need to see

NIS-2 Article 21 requires essential and important entities to implement “state-of-the-art” cryptographic practices as part of their risk management measures. DORA Article 9 imposes equivalent obligations on financial entities, with explicit reference to ICT security controls including authentication. Neither regulation names specific algorithms, but both require demonstrable, documented risk management. For a CISO preparing for an audit, post-quantum readiness must be evidenced, not merely asserted.

The minimum governance documentation set for a defensible quantum-readiness position covers six areas. First, a cryptographic inventory that maps every use of RSA and ECC within authentication flows, including hardware attestation chains, TLS termination at identity providers and API signing keys. Second, a written algorithm selection rationale that references FIPS 204, NIST IR 8547 and the relevant ENISA guidance by document title and date. Third, a phased rollout timeline with specific milestone dates: hybrid mode activation, completion of hardware refresh for the highest-privilege user population, and the end date for ECC-only credential acceptance. Fourth, a hybrid-mode operating procedure that defines which user populations are already on ML-DSA credentials, which are still in hybrid mode and which remain on legacy ECC, with a risk justification for each group. Fifth, a credential recovery protocol covering the scenario where an ML-DSA-only authenticator is lost before the algorithm is widely supported in backup authenticators. Sixth, a board-level sign-off or equivalent executive acknowledgement that the migration timeline has been reviewed against the organisation’s data retention obligations, because data retained beyond 2030 under existing ECC-signed access logs carries residual quantum risk.

As NIST has stated in its IR 8547 initial public draft: “The transition to post-quantum cryptography is not a future problem; it is a present risk management challenge that requires immediate planning.” For compliance officers presenting to supervisory authorities under NIS-2 or the European Banking Authority’s DORA technical standards, that framing translates directly into audit findings if planning has not started.

FAQ

Can we keep existing YubiKey hardware and still become post-quantum ready?

Most current YubiKey models do not yet support ML-DSA in firmware. Yubico has indicated post-quantum roadmap work, but a full migration will require either new hardware generations or a hybrid approach where the server-side relying party accepts both ES256 and ML-DSA credentials during a transition window. Plan for a phased hardware refresh cycle aligned with your credential expiry policy.

What is a harvest-now-decrypt-later attack and why does it affect authentication credentials specifically?

In a harvest-now-decrypt-later attack, an adversary captures signed WebAuthn assertions from network traffic today and archives them until a quantum computer is available to recover the private signing key. For long-lived passkeys on high-privilege accounts, this creates a retrospective impersonation risk even after the account no longer exists in the live system.

Does IETF draft-vitap-ml-dsa-webauthn break existing WebAuthn relying parties?

No. The draft defines new COSE algorithm identifiers that relying parties must explicitly declare support for. Existing relying parties that do not list these identifiers will not negotiate them, and the authenticator falls back to its ECC algorithms. Backward compatibility is preserved by design.

How does the eIDAS 2.0 EUDI Wallet interact with post-quantum passkeys in public-sector authentication?

The EUDI Wallet Architecture Reference Framework is being updated to accommodate post-quantum suites. The EU HORIZON POSEIDON project is the primary research programme feeding ML-DSA and hybrid signature requirements into that framework. Public-sector relying parties should track ARF releases from the European Commission for the moment ML-DSA becomes a mandatory or recommended algorithm in the wallet trust framework.

What must a CISO document to satisfy NIS-2 or DORA auditors on post-quantum readiness?

The minimum set includes: a cryptographic inventory of all RSA and ECC uses in authentication flows; an algorithm selection rationale citing FIPS 204 and NIST IR 8547; a phased rollout timeline with dated milestones; a hybrid-mode operating procedure; a tested credential recovery protocol; and board-level acknowledgement that the migration timeline has been reviewed against the organisation’s data retention obligations.