up:: In the Protocols MOC

FIDO2, WebAuthn, and Passkeys

FIDO2, WebAuthn, and passkeys are the standards and the user-facing name for passwordless authentication, where a device holds a private key and proves identity by signing a challenge instead of sending a shared secret, and because that private key is a classical ECDSA, EdDSA, or RSA key, the whole scheme rests on a digital signature that a cryptographically relevant quantum computer running Shor’s algorithm can forge. Passwordless authentication removes the harvestable shared secret, which is a real security gain, and it relocates the quantum exposure to the signature keys that authenticate every login and every attestation. The migration answer is the same one the rest of the stack is taking, which is post-quantum signatures (ML-DSA) carried through the FIDO Alliance’s roadmap.

The short version:

1. WebAuthn is the W3C browser API, CTAP is the protocol between the browser and the authenticator, FIDO2 is the two together, and a passkey is a WebAuthn credential synced or bound to a device.
2. Every step that matters cryptographically is a signature. The authenticator signs a login challenge (the assertion) and, at registration, may sign a statement about itself (the attestation), and today those signatures are ECDSA over P-256, EdDSA, or RSA.
3. Those are exactly the algorithms Shor’s algorithm breaks, so a passkey is a public-key signature system and it inherits the public-key signature system’s quantum exposure.
4. Passwordless does help with the harvest problem. A signature is verified live and there’s no shared secret on the wire to record, so the quantum risk here is forge-later rather than harvest-now.
5. The fix is post-quantum signatures in the same credentials. IANA registered ML-DSA code points in COSE (the format WebAuthn credentials use) in 2025, and the FIDO Alliance is scoping ML-DSA into the standards, so the migration rides the existing agility of the credential format.

Think of a passkey like a wax seal on a letter instead of a password written inside it. Anyone can see the letter, so there’s no secret to steal in transit, and the letter is trusted because only your signet ring makes that exact seal. The quantum problem isn’t that someone intercepts the letter, it’s that a good enough forger could study your published seals and carve a matching ring, at which point they can seal letters as you without ever touching your ring. Moving from a written password to a wax seal closes the interception problem and opens the forgery problem, and the fix is a seal pattern too intricate for the forger’s tools, which is what a post-quantum signature is.

What are FIDO2, WebAuthn, and passkeys?

FIDO2 is an authentication framework built from two specifications that work together, and a passkey is the consumer-friendly name for the credential it produces. Getting the pieces straight matters, because the quantum exposure lives in a specific one of them.

1. WebAuthn is the W3C Web Authentication API, the interface a website (the relying party) uses in the browser to register and then verify a public-key credential. It defines the registration ceremony and the authentication ceremony.
2. CTAP is the Client to Authenticator Protocol from the FIDO Alliance, the protocol between the client platform (the browser or OS) and the authenticator itself (a security key, a phone, a laptop’s secure element).
3. FIDO2 is WebAuthn plus CTAP taken as one system, the full path from a website down to the hardware that holds the key.
4. A passkey is a WebAuthn credential meant to replace a password outright, typically a discoverable credential that is either bound to one device or synced across a user’s devices through a platform keychain.

Source: W3C, “Web Authentication, An API for accessing Public Key Credentials Level 3,” W3C WebAuthn L3.

Source: FIDO Alliance, “Client to Authenticator Protocol (CTAP),” FIDO CTAP.

The reason to hold these apart is that the quantum question is not about the framework’s design. WebAuthn’s challenge-response flow, its origin binding, and its phishing resistance are structural and survive the transition untouched. What has to change is the one primitive underneath all of it, the signature algorithm the authenticator uses.

Where does cryptography live in a passkey?

The cryptography that matters is a public-key signature, and it appears at two moments in the WebAuthn lifecycle, both of which are classical today. A passkey is a key pair whose private half never leaves the authenticator, and everything the system trusts flows from that private key signing something.

1. The assertion signature (every login). When a user authenticates, the relying party sends a random challenge, and the authenticator signs it with the credential’s private key. The relying party verifies that signature against the public key it stored at registration. This is the core of every passwordless login, and the WebAuthn spec’s registered algorithms for it are ES256 (ECDSA with P-256), EdDSA, and RS256 (RSA with SHA-256).
2. The attestation signature (at registration, optionally). During registration an authenticator can present an attestation statement, verifiable evidence of what kind of authenticator it is, signed by an attestation key that chains to a manufacturer certificate. This lets a relying party enforce a policy like “only hardware keys from these vendors.” The attestation signature and its certificate chain are also classical public-key cryptography.

Source: W3C, “Web Authentication Level 3,” §Authentication and §Attestation, W3C WebAuthn L3.

The algorithm a credential uses is carried as a COSE (CBOR Object Signing and Encryption) key with an algorithm identifier, so the credential format already names its algorithm explicitly rather than hardcoding one. That detail is what makes the migration tractable, because adding a post-quantum algorithm is adding a code point, not redesigning the credential.

Why are passkeys in the quantum blast radius?

Because their security reduces entirely to a classical digital signature, and classical signatures are exactly what Shor’s algorithm breaks. A passkey’s public key is, by design, public. The relying party stores it, and in synced-passkey ecosystems it can be widely distributed. Shor’s algorithm, run on a CRQC, recovers a private key from an ECDSA, EdDSA, or RSA public key, which is the whole security assumption of the scheme inverted.

If an attacker recovers the private key behind a passkey, they can produce valid assertion signatures for that credential, which means they can authenticate as the user to the relying party that trusts it. The same logic hits attestation: recovering an attestation private key lets an attacker forge attestations, defeating the “trusted hardware only” policy a relying party relied on. Both failures are forgery of a signature the system treats as proof of identity or provenance, which is precisely the failure mode of every classical signature under a quantum computer, covered in general terms under quantum-vulnerable algorithms.

The honest framing is that passkeys are neither uniquely vulnerable nor magically immune. They’re a signature system, so they carry a signature system’s quantum exposure, no more and no less than the certificates and code-signing keys elsewhere in the estate.

Does passwordless remove the quantum problem or move it?

It moves it, from a harvestable secret to a forgeable signature, and that relocation genuinely changes the clock you’re racing. A password is a shared secret. When you send it, or when a server stores a hash of it, there’s a thing an attacker can capture now and attack later. A passkey has no shared secret to send, so the harvest-now-decrypt-later pressure that dominates key-exchange migration doesn’t apply to the login itself in the same way.

That puts passkey signatures in the non-harvestable category, alongside other signatures. A signature has to be forged against a live relying party at the moment of authentication, which needs a working quantum computer in hand, not a recording made today. So the urgency is real but it’s forge-later urgency, weighted by blast radius (how many accounts and how much trust depend on the algorithm) rather than by a harvesting deadline. This is the same key-exchange-versus-signatures split that runs through the whole protocol layer in the protocols: passwordless is a signature story, so it clocks like signatures do.

The table lays the two authentication models side by side on the axis that matters for quantum planning.

	Password authentication	Passkey (WebAuthn) authentication
Secret on the wire	A shared secret is transmitted and often stored server-side	No shared secret is transmitted; the private key stays on the authenticator
Harvest-now exposure	The transmitted or stored secret can be captured now and attacked later	Login has no harvestable secret, so it’s non-HNDL
Quantum failure mode	Offline cracking, sped up modestly by Grover against the hash	Shor forges the signature outright by recovering the private key
What has to change	A stronger password hash and a longer secret	A post-quantum signature algorithm (ML-DSA) in the credential

The takeaway is that both models have a quantum answer, and they’re different answers. For the residual password surfaces, see Passwords in a Quantum World. For passkeys, the answer is post-quantum signatures.

How do passkeys go post-quantum?

By adding a post-quantum signature algorithm to the credential format and negotiating it the same way the current algorithms are negotiated, and the standards groundwork for that is now in place. The migration doesn’t require reinventing WebAuthn or CTAP, because the credential already carries its algorithm as a COSE identifier, so the work is registering post-quantum algorithms and having authenticators and relying parties support them.

1. The COSE code points exist. IANA’s COSE Algorithms registry now carries ML-DSA entries, ML-DSA-44 (value -48), ML-DSA-65 (-49), and ML-DSA-87 (-50), specified by RFC 9964. Since WebAuthn credentials name their algorithm through COSE, this is the specification hook a post-quantum passkey needs to be expressible at all.
2. The FIDO Alliance is addressing it. The Alliance has published guidance on migrating its technologies to post-quantum cryptography, working toward the extensions that let authenticators generate and use ML-DSA credentials and relying parties request them, which is what turns the registered code points into an interoperable capability.

Source: FIDO Alliance, “Addressing FIDO Alliance’s Technologies in a Post-Quantum World” (white paper), FIDO Alliance. 3. Agility carries the transition. Because the relying party declares which algorithms it accepts and the credential declares which it used, a passkey ecosystem can add ML-DSA as an accepted algorithm and let new credentials use it while old ones keep working, which is crypto-agility operating at the credential layer rather than a flag-day cutover.

Source: IANA, “CBOR Object Signing and Encryption (COSE) Algorithms” registry, ML-DSA-44/65/87 entries per RFC 9964, IANA COSE.

Source: IETF, “ML-DSA for COSE,” RFC 9964, RFC 9964.

The practical shape of the migration is therefore reassuringly ordinary. It’s an algorithm addition to a format built to hold more than one algorithm, propagated through authenticators, platforms, and relying parties on their own timelines, with the classical and post-quantum credentials coexisting during the overlap.

Common misconceptions

1. “Passkeys are quantum-safe because there’s no password to steal.” Removing the password removes the harvestable secret, and it leaves a classical signature that Shor’s algorithm can forge. Passwordless improves the harvest picture and doesn’t make the underlying keys post-quantum.
2. “Passkeys use fancy device crypto, so quantum doesn’t apply.” The device crypto is ECDSA, EdDSA, or RSA, the same public-key families quantum breaks. Secure-element storage protects the key from extraction, not from being derived out of its public counterpart by a quantum computer.
3. “If passkeys break, it’s a harvest-now emergency like TLS key exchange.” Signatures are verified live, so a passkey has to be forged against a running relying party with a quantum computer in hand. It’s a forge-later risk weighted by blast radius, not a recording made today.
4. “There’s no post-quantum path for FIDO yet, so nothing can be done.” The ML-DSA COSE code points are registered and the FIDO Alliance is scoping the extensions. The credential format was built to name its algorithm, so the path is an algorithm addition, and designing for agility now is the concrete move.
5. “Attestation is a minor detail, only the login signature matters.” Attestation is a signature too, and its keys chain to manufacturer roots that are long-lived. Forged attestations defeat “trusted hardware only” policies, so attestation is a real second signature surface, not a footnote.

Questions people ask

Are passkeys quantum-safe today? No. A passkey authenticates by signing with a classical ECDSA, EdDSA, or RSA key, and those are the algorithms Shor’s algorithm breaks. They’re a genuine security upgrade over passwords for phishing and harvesting, and they still need a post-quantum signature to be quantum-safe.

Is a passkey a harvest-now-decrypt-later target? The login itself isn’t, because the assertion is a live-verified signature with no shared secret to record. The quantum risk to a passkey is forgery once a quantum computer exists, which makes it a forge-later concern ranked by how much trust rides on the credential.

Which algorithm will post-quantum passkeys use? The registered COSE code points are for ML-DSA, the NIST standard lattice signature, at parameter sets ML-DSA-44, -65, and -87 (RFC 9964). ML-DSA is NIST’s primary post-quantum signature, so it’s the expected default for FIDO’s post-quantum work.

Do I need new hardware security keys for post-quantum passkeys? Likely yes for hardware authenticators, since generating and signing with ML-DSA has to be supported by the authenticator itself, and older security keys have fixed firmware. Platform authenticators (phones, laptops) that can update software have an easier path, which mirrors the constrained-device agility problem.

Are ML-DSA signatures too big for a passkey? ML-DSA public keys and signatures are kilobytes where an ECDSA signature is tens of bytes, so post-quantum credentials are larger to store and transmit. It’s a size consideration for authenticators and syncing, not a blocker, and it’s the same size-over-speed reality that runs through the whole transition.

Does moving to passkeys now help or hurt the quantum migration? It helps. Passkeys remove the harvestable password secret today, and because the credential format is algorithm-agile, a passkey ecosystem is well-positioned to add ML-DSA when the FIDO extensions land. Adopting passkeys and requiring algorithm agility is a reasonable step ahead of the post-quantum signatures.

What about the attestation certificates, do those need to migrate too? Yes. Attestation statements are signed and chain to manufacturer roots, so those signatures and their certificate chains are classical public-key cryptography that a quantum computer can forge. Any relying party that enforces attestation policy has a second signature surface to account for alongside the login credential.

---

Everything here is the map, given freely. When your team needs its authentication estate inventoried, its passkey and attestation surfaces sorted from its residual password and shared-secret surfaces, and the whole thing sequenced onto post-quantum signatures, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-14 · Maintained by Addie LaMarr, LaMarr Labs.