Argon2id and scrypt are recommended for password storage, and passkeys are recommended in place of passwords. The two recommendations have different quantum exposure. A password hashed with Argon2id is symmetric cryptography; Grover's algorithm offers at most a quadratic speedup on the guess, and the memory-hard construction costs the quantum attacker the same memory per guess as the classical one. A passkey is a P-256 key pair and an ECDSA signature, which current resource estimates put ahead of RSA-2048 in the order of breaking. Which quantum deadline applies to a passkey depends on where its private key is stored.
Standards status for ML-DSA in WebAuthn
RFC 9964 defines ML-DSA serializations for COSE, and the IANA COSE registry carries the identifiers −48, −49 and −50 for ML-DSA-44, ML-DSA-65 and ML-DSA-87. WebAuthn Level 3, a W3C Recommendation since August 2026, passes a COSE algorithm identifier through without interpreting it, so the W3C specification needs no change. The FIDO Alliance's Server Requirements review draft for WebAuthn Level 3 and CTAP 2.3, dated February 2026, lists all three ML-DSA parameter sets as Recommended for servers; its ML-DSA reference is still the Internet-Draft that preceded the RFC. An individual IETF draft, draft-vitap-ml-dsa-webauthn, describes registration and assertion with ML-DSA keys and advises ML-DSA-44 or ML-DSA-65 where signature size or processing time matters. An ML-DSA-87 signature is 4,627 bytes; an ES256 signature is 64.
Authenticators exist as demonstrators. Google published an ECDSA/Dilithium hybrid firmware for OpenSK in August 2023. Yubico has shown prototype YubiKeys that sign with ML-DSA, which Mike Jones noted when RFC 9964 was published. Swissbit's iShield Key 2 PQC supports ML-DSA credentials against a modified SimpleWebAuthn relying party. None is a certified product, and no platform authenticator from Apple, Google or Microsoft has announced a date. Johann-Philipp Thiers of Swissbit, a co-chair of the FIDO Alliance's PQC Study Group, wrote in September that the CTAP PIN/UV protocols rely on ECDH and would likely move to ML-KEM, that attestation chains rest on X.509 certificates with ECC or RSA keys, and that the metadata service signatures and the certification programs have to change with them.
Device-bound passkeys and the signature deadline
A passkey assertion is a challenge-response signature. It proves possession of the key at the time of signing; there is no ciphertext to collect and no session key to recover. The exposure is the one NSA calls trust now, exploit later: an adversary who has recorded the public key recovers the private key once a cryptographically relevant quantum computer exists and signs challenges from then on. Under EO 14412 that is the signature deadline of 2031, a year behind key establishment. In the hybrid signature split Valsorda's position is that pure ML-DSA-44 is adequate for signatures while hybrids remain on key exchange. Apple's PQ3 design for iMessage applies the same reasoning: key establishment moved to a Kyber hybrid in 2024, and sender authentication stays on P-256 ECDSA because a signature cannot be attacked retroactively.
A passkey whose private key stays in a hardware authenticator or a device secure element is therefore on the signature deadline, behind TLS key exchange and behind code signing in migration order.
Synced passkeys and the key establishment deadline
Apple's platform security guide on secure keychain syncing describes each device holding a syncing identity of P-384 elliptic-curve keys, with each keychain item encrypted so that only a device in the user's circle can decrypt it, and passing through Apple's servers in that form. Recovery is a separate path: Apple's page on escrow security describes an escrow record guarded by a cluster of hardware security modules, each holding a key that encrypts the records in its care, with the user's iCloud security code verified by SRP, and names no public-key algorithm for the escrow wrapping. Google's description of passkeys in Google Password Manager states that a backed-up private key is uploaded only in encrypted form, under a key accessible on the user's own devices and recovered on a new device through an existing device's screen lock, and does not name the key agreement.
On the sync path the stored object is a private signing key wrapped to an elliptic-curve device identity, held on the provider's infrastructure for the life of the account. An adversary holding that ciphertext, by breach or by legal process, who later breaks a single device identity key recovers the items wrapped to it as usable signing keys. Harvest now, decrypt later applies to this path, and so does the key establishment deadline rather than the signature deadline. Whether the sync and recovery channels of the three platform providers have moved to post-quantum key agreement is not answered by their public documentation.
Existing credentials cannot change algorithm
The FIDO Alliance estimates five billion passkeys in active use as of May 2026, and its State of Passkeys 2026 survey finds that three quarters of consumers have enabled one. Each is a P-256 key, or an RSA key where the relying party allowed it. WebAuthn has no operation that changes the algorithm of an existing credential; migration is a new registration ceremony per account per user, and the relying party holds both credentials until the old one is retired.
Export-grade RSA is the precedent for a credential population that persists past its reason. The 512-bit RSA_EXPORT cipher suites were created by US export rules in the mid-1990s and the rules were relaxed in 2000. FREAK, in March 2015, found 36.7% of servers with browser-trusted certificates still offering the suites and clients still accepting them, and Logjam found the same for 512-bit Diffie-Hellman two months later. No mechanism had forced a re-key in fifteen years. A passkey is re-keyed only when a person re-enrolls it.
Relying-party configuration
Accepting −48 and −49 in pubKeyCredParams alongside −7, as the CTAP 2.3 Server Requirements recommend, ensures that the first authenticator offering ML-DSA is not rejected. WebAuthn libraries are adding the algorithms; Keycloak's tracking issue is blocked on webauthn4j, and SimpleWebAuthn has been patched in Swissbit's demonstrator. Recording the COSE algorithm of every registered credential makes the P-256 count and its rate of change reportable, which a credential table holding only the public key blob cannot do.
The reporting split is the same one that applies to TLS, where [PQ]probe grades post-quantum key exchange against 2030 and records the signature algorithm of every certificate it sees. For passkeys the sync and recovery channel reports against the key establishment deadline and the assertion against the signature deadline, and the credential table's algorithm column is where the second number comes from.