Post-Quantum Cryptography in 2026: NIST FIPS 203/204/205, Apple PQ3, Cloudflare, and the Harvest-Now Threat

ML-KEM, ML-DSA, SLH-DSA, Apple PQ3 for iMessage, Cloudflare's PQ rollout, Signal's PQXDH, and the harvest-now-decrypt-later threat that makes the migration urgent in 2026.

Post-Quantum Cryptography in 2026: NIST FIPS 203/204/205, Apple PQ3, Cloudflare, and the Harvest-Now Threat

The reason post-quantum cryptography is the rare quantum topic that matters today, in 2026, has nothing to do with whether a fault-tolerant quantum computer exists. It has to do with traffic that adversaries are capturing right now and intend to decrypt later. Once Shor’s algorithm runs on a real machine — sometime between 2030 and 2040 by most credible estimates — every RSA and elliptic-curve key exchange recorded between now and then becomes readable. If the data still matters at decryption time, it has already been compromised. This is the harvest-now-decrypt-later threat, and it is why the US National Security Agency, the German BSI, and the UK NCSC have all been telling enterprises to start migrating since 2022.

The NIST standards finally landed in August 2024. The reference clients — Apple iMessage, Cloudflare, Signal, AWS, Google Chrome — have shipped real deployments. This post is the engineering tour of what changed, what to deploy, and where the migration sharp edges live.

The NIST PQC standards as of 2026#

NIST finalized three Federal Information Processing Standards in August 2024 after an eight-year competition.

FIPS 203 — ML-KEM, formerly known as Kyber. Module-Lattice-based Key-Encapsulation Mechanism. Replaces RSA-OAEP and ECDH for key establishment. Three parameter sets — ML-KEM-512, 768, and 1024 — with 1024 the NSA’s CNSA 2.0 mandate. Public keys and ciphertexts are roughly 1 to 1.5 KB at the 768 level, which is much larger than a 32-byte X25519 public key but small enough for TLS handshakes.

FIPS 204 — ML-DSA, formerly Dilithium. Module-Lattice-based Digital Signature Algorithm. Replaces RSA-PSS and ECDSA for signatures. Three parameter sets with signature sizes in the 2.4 to 4.6 KB range — a real overhead compared to 64-byte Ed25519 signatures, and the source of most of the migration pain when signing many small things (DNS, OCSP, certificate chains).

FIPS 205 — SLH-DSA, formerly SPHINCS+. Stateless hash-based signatures. Slower and larger than ML-DSA but built on different mathematics, which gives a hedge if lattice problems are ever broken. The conservative choice for long-lived signatures — code signing, firmware, root CAs — where rotation is hard.

FIPS 206 — FN-DSA, formerly Falcon — is still in draft as of mid-2026, expected to finalize later in the year as a compact signature alternative.

The 2024-2025 NSA CNSA 2.0 mandate sets the transition timeline for US national-security systems: software/firmware signing by 2025, general-purpose use by 2030, full transition for new equipment by 2033. Commercial and EU regulators are aligning to similar windows. The PCI Council and FIPS 140-3 module guidance are catching up.

The Apple PQ3 deployment#

Apple’s PQ3 protocol for iMessage, announced in February 2024 and rolled out through iOS 17.4 and macOS 14.4, is the largest consumer-scale post-quantum deployment in history. PQ3 uses ML-KEM for the initial key establishment alongside the classical ECDH key exchange — a hybrid construction — and then ratchets the post-quantum key forward on every conversation refresh. The design goal was Level 3 protection — periodically refreshing the post-quantum key, so an attacker who compromises a key at one moment cannot decrypt long historical traffic.

The Apple engineering rationale that is worth understanding: post-quantum security against harvest-now-decrypt-later requires both forward secrecy (rotate keys often) and post-quantum primitives (rotate them with ML-KEM, not just ECDH). PQ3 does both. By 2026, billions of iMessage threads are protected this way by default.

TLS handshake exchanging hybrid post-quantum and classical keys

The Cloudflare and TLS rollout#

Cloudflare has been the most public commercial PQC deployment story. Starting in 2022 with X25519+Kyber768 as an experimental hybrid, the rollout went general-availability through 2023-2024, and by 2025 Cloudflare reported that a meaningful share of HTTPS connections through their edge used hybrid post-quantum key exchange. Chrome enabled X25519MLKEM768 by default in late 2024, Firefox followed in early 2025, and the major CDNs — Cloudflare, Fastly, AWS CloudFront — all support hybrid handshakes by 2026.

The TLS 1.3 hybrid model is the practical compromise: combine a classical and a post-quantum key exchange so the connection is secure as long as either holds up. This buys time during the migration window where ML-KEM is widely supported but not yet exclusively trusted. The IETF TLS working group’s hybrid_key_exchange codepoints are the wire format.

The downside that platform teams need to know about: hybrid handshakes are roughly 1 KB larger per ClientHello, which can fragment over MTU-limited paths and break naive middleboxes. Cloudflare’s published incident report from 2023 on the topic is the canonical reference for the failure modes.

Signal PQXDH and messenger protocols#

Signal’s PQXDH protocol, deployed in late 2023, was the first major messenger to ship post-quantum protection in the X3DH initial key agreement. PQXDH adds CRYSTALS-Kyber to Signal’s classical X3DH handshake. Unlike Apple’s PQ3, Signal’s design did not initially ratchet the post-quantum key with every message — the cost of doing so in a low-bandwidth threaded conversation was deemed too high — but the 2025 follow-up work has been refining that. WhatsApp, which uses the Signal protocol underneath, picked up PQXDH through 2024.

The relevant pattern across all of these consumer rollouts: hybrid first, post-quantum only later. Nobody is willing to bet exclusively on a lattice problem yet, and the hybrid construction is the right caution. The right enterprise posture is the same.

What enterprise teams should actually do in 2026#

The migration plan that we recommend for enterprise platform teams in 2026:

Inventory your crypto first. You cannot migrate what you have not catalogued. Where do you use RSA and ECC? In your TLS termination, your VPN tunnels (IPsec, WireGuard, OpenVPN), your code-signing pipelines, your SSH access, your S/MIME or PGP email, your database TDE, your KMS, your JWT signing? Every one of those has a different migration timeline. Tools like Cryptosense, Sandbox AQ, and IBM’s Quantum Safe inventory products exist for exactly this; many enterprises do it as a one-time spreadsheet exercise and then automate the recurring scan.

Pick the hybrid TLS path for inbound traffic. Turn on X25519MLKEM768 at your edge — Cloudflare, AWS, Akamai, Fastly, or your own load balancers if you run NGINX or HAProxy with the right OpenSSL provider. This is a no-regret move that improves harvest-now resistance and is invisible to clients.

Migrate code signing and long-lived signatures first. SLH-DSA or ML-DSA for firmware and software updates. Code signed today with RSA needs to be verifiable in 2035; the signature has to survive that long. CA/Browser Forum and Apple’s notarization timeline are pushing the same direction.

Countdown clock beside a vault and intercepted packets

Plan the KMS migration. AWS KMS, Azure Key Vault, and Google Cloud KMS are all working on PQC support — AWS announced ML-DSA and ML-KEM support in late 2024, Azure followed in 2025. The enterprise pattern is to introduce post-quantum keys alongside classical ones and run hybrid where possible.

Do not panic about TLS for short-lived data. Web traffic that has no value in 2035 — payment-form submissions, ad-tech, ephemeral session cookies — does not need an emergency migration. Long-lived secrets (medical records, banking statements, government documents, attorney-client communications) do.

Update your compliance baselines. PCI DSS, FedRAMP, FIPS 140-3, and the EU’s NIS2 directives all reference PQC migration timelines now. Auditors are starting to ask.

The gotchas that bite real migrations#

A few hard-won lessons from PQC migrations our team has been involved in over 2024 and 2025.

Hardware tokens are the long pole. YubiKeys, HSMs, smart cards — the firmware update path to support ML-DSA is slow because the algorithm needs more RAM and computation than older devices have. YubiKey 5 series got ML-KEM support in 2025; older tokens cannot be upgraded.

Certificate chains explode. A typical TLS certificate chain with ML-DSA signatures is meaningfully larger than ECDSA. Chrome and Firefox have been quietly working on certificate-compression extensions to manage this, but the impact on QUIC handshakes and DNSSEC in particular is non-trivial.

Old protocols may not have a migration story. Anything still using SHA-1 or RSA-1024 — yes, this exists in production at enterprises — needs to be upgraded twice. Once to current classical baselines, then to post-quantum.

Library availability is uneven. OpenSSL 3.5 (released early 2025) bundles ML-KEM and ML-DSA. AWS-LC, BoringSSL, and Rustls all support them. Older application servers and embedded devices may not.

Where this fits in the broader landscape#

Post-quantum migration is the practical, deadline-driven part of the quantum computing landscape story. The fault-tolerant quantum computer that breaks RSA may be five years away or fifteen — but the harvest-now-decrypt-later threat is happening now. For organizations that handle long-lived sensitive data — healthcare, banking, government, legal — starting in 2026 is the realistic timeline. Starting in 2030 is too late for traffic that needs to remain confidential through 2040.


The migration window is open and it closes faster than most teams think. If your organization needs help inventorying crypto, sequencing the migration, or shipping hybrid TLS at the edge, our cloud infrastructure team has helped enterprises do exactly this. Tell us about your crypto estate.