FIDO and post-quantum cryptography: prepare without inventing a roadmap
FIDO2 combines WebAuthn and CTAP to support public-key authentication. A relying party holds a public key, while the authenticator protects the private credential. A PIN or biometric check can authorize use of that credential; the biometric itself is not the site’s signing key. WebAuthn’s relying-party scoping and origin checks provide phishing resistance, not immunity to every compromised device, account-recovery weakness or implementation error. See the W3C WebAuthn specification.
The quantum risk is real, but the date is not established
A sufficiently capable quantum computer would threaten the mathematical assumptions behind RSA and elliptic-curve cryptography. That does not establish a year when existing FIDO credentials will be broken. The original 2024–2035 risk ladder, claims of inevitable compromise after 2035, and fixed product/protocol milestones were unsupported forecasts, not a verified deployment schedule.
FIDO’s 2024 post-quantum white paper discusses uncertainty, crypto-agility and dependencies on other standards bodies. Distinguish authentication signatures from confidentiality: collecting encrypted traffic for future decryption is a different risk from replaying an old authentication response. A properly checked fresh challenge still matters; neither concern should be reduced to a calendar slogan.
What the NIST algorithms do
NIST published FIPS 203, 204 and 205 in August 2024. Key encapsulation and digital signatures serve different purposes; an algorithm’s publication is not automatic integration into every authenticator, browser or relying-party library. See NIST’s standards announcement.
| Algorithm | Standard/status | Role |
|---|---|---|
| ML-KEM | FIPS 203 | Key establishment, based on module lattices; not an authentication signature. |
| ML-DSA | FIPS 204 | Digital signatures based on module lattices. |
| SLH-DSA | FIPS 205 | Hash-based digital signatures. |
| FN-DSA / Falcon | Track NIST status | Separate standardization work; a small signature alone does not establish FIDO interoperability. |
For the separate FN-DSA effort, consult NIST’s PQC project rather than treating an anticipated FIPS number, draft encoding or product announcement as finalized support. ML-KEM is not a drop-in replacement for a WebAuthn signature, and SLH-DSA’s possible firmware use is an engineering choice, not a universal FIDO mandate.
Size and hardware constraints need measurement
The ML-DSA-44 parameter set has a 1,312-byte public key and a 2,420-byte signature according to FIPS 204. Ed25519 has a 32-byte encoded public key and a 64-byte signature, not the original article’s 64-byte public key; see RFC 8032. These are raw algorithm encodings, not complete COSE messages, transport frames or attestation chains.
Larger credentials can affect storage, transfer, RAM, latency and battery use. Costs depend on the algorithm, parameter set, implementation and hardware; this article reports no benchmark. NFC and USB transport constraints need implementation-specific analysis. A dedicated accelerator is one possible design, not a confirmed requirement or guaranteed capability of a named future security key.
Migration is a system change
- Inventory credential algorithms, authenticator and browser support, relying-party validation, recovery paths and attestation trust dependencies.
- Track standards and vendor support before changing accepted algorithm lists. Hybrid designs must follow an agreed protocol and validation rules; concatenating signatures or inventing a dual-signed certificate format is not enough.
- Review metadata, attestation certificates and root trust separately from user credential signatures. Their migration paths and lifetimes may differ.
- Plan compatibility and replacement in an approved test environment. Do not present “CTAP3,” “YubiKey 6,” a mandated PQC-only date or deprecation of all classical FIDO as a verified roadmap on the basis of the original article.
Passkeys can be synced or device-bound
Passkeys are not all cloud-synced. FIDO distinguishes synced and device-bound passkeys. A synced system additionally depends on the provider’s encryption, device onboarding and recovery design. Any post-quantum update must address those layers and interoperability; it is not justified to prescribe ML-KEM as the single required fix for every provider.
Conclusion
Prepare an inventory and an upgrade path while continuing to use supported, correctly implemented phishing-resistant authentication. Plan from published specifications and verified vendor capabilities, not speculative dates, invented products or an assumption that “post-quantum” alone makes an entire authentication system safe.