The State of Post-Quantum Cryptography: May 2026

Post-quantum cryptography is no longer a standards exercise. ML-KEM key exchange is the default in every major browser and in OpenSSH. RHEL 10 ships with post-quantum TLS and SSH enabled out of the box. DigiCert is issuing ML-DSA certificates today.

But “available” and “deployed” are not the same thing. Key exchange is largely solved. Authentication — the part where certificates, signatures, and trust chains live — is not. The gap between what the standards define and what production systems can actually verify is where most of the engineering work remains.

This post is a practitioner’s scorecard. It covers what works today, what is close, and what is still blocked across TLS, SSH, and PKI. It is the first installment of a periodic series; I will update it as the landscape evolves.

If you want the implementation details — how a CA actually signs ML-DSA certificates, handles FIPS constraints, and manages the size explosion — the PKI.Next series covers that in depth. This post is the view from 10,000 feet.

The Standards Foundation

NIST published the first three post-quantum cryptographic standards in August 2024:

Two more standards are in progress:

• FIPS 206 (FN-DSA), based on FALCON, is expected later in 2026. It produces smaller signatures than ML-DSA and is designed for bandwidth-constrained environments.
• HQC, a code-based key encapsulation mechanism, was selected in March 2025 as a backup to ML-KEM. The draft standard is expected in early 2026 with finalization in 2027.

The compliance deadlines are real and approaching:

CNSA 2.0 is prescriptive: it requires ML-DSA-87 and ML-KEM-1024 exclusively (Category 5 security) for National Security Systems. The broader FIPS standards offer additional parameter sets, but the highest-security variants are the only ones acceptable for government use.

TLS: Key Exchange Is Solved, Authentication Is Not

Key Exchange: Done

Post-quantum key exchange in TLS 1.3 is a solved problem at scale. The hybrid approach — combining ML-KEM-768 with X25519 in a single key exchange — is deployed across all major browsers and CDNs:

• Chrome 131 (November 2024) made X25519MLKEM768 the default TLS 1.3 key exchange offer. By Chrome 138, users could no longer disable it.
• Firefox 132 enabled X25519MLKEM768 by default on desktop. Firefox 135 added support over QUIC/HTTP3.
• Edge 131 mirrors Chrome’s timeline, being Chromium-based.
• Cloudflare reports that over 60% of human-initiated TLS traffic now uses hybrid ML-KEM key exchange.
• Akamai made post-quantum key exchange the default for all client connections in January 2026, completing full network rollout by March 2026.

On the server side, rustls has supported ML-KEM key exchange by default since version 0.23.27. The upcoming 0.24 release will require explicit crypto provider selection, with rustls-aws-lc-rs providing the post-quantum algorithms and rustls-ring limited to classical-only.

The IETF specifications for hybrid TLS key exchange (draft-ietf-tls-ecdhe-mlkem) are still in draft, but the deployed implementations are stable and interoperable.

Bottom line: if you are running a modern browser or a server with rustls/OpenSSL 3.5+, your TLS key exchange is already quantum-resistant. This is the “harvest now, decrypt later” defense, and it is operational.

Authentication: The Hard Part

TLS authentication — where the server proves its identity via a certificate chain — is a different story. The pieces exist but do not connect yet:

• RFC 9881 (October 2025) defines ML-DSA algorithm identifiers for X.509 certificates.
• DigiCert is issuing ML-DSA certificates today through Trust Lifecycle Manager.
• OpenSSL 3.5 (April 2025) includes ML-DSA support in the default provider.

But here is the gap: most TLS libraries cannot verify ML-DSA signatures in a handshake. Rustls does not support ML-DSA certificate verification in its stable API. The aws-lc-rs crate provides ML-DSA through an unstable feature flag, not the production path. Cloudflare has stated they will add ML-DSA certificate support when CAs broadly support them — their estimate is 2026.

The size problem compounds this. An ML-DSA-65 signature is 3,309 bytes and a public key is 1,952 bytes. A typical two-certificate TLS chain (end-entity + intermediate) adds roughly 14.7 KB of signature and key data to the handshake — compared to ~256 bytes with ECDSA P-256. This is not just a bandwidth concern; it impacts connection latency, particularly on mobile networks and constrained devices.

Bottom line: you can issue ML-DSA certificates today. You cannot use them for TLS authentication in most production stacks. Key exchange protects the session; authentication protects the identity. One of these two is solved.

SSH: Post-Quantum by Default

SSH is further along than TLS for a simple reason: key exchange was the only urgent problem, and OpenSSH solved it.

OpenSSH has offered post-quantum key agreement since release 9.0 (April 2022), initially via the sntrup761x25519-sha512 algorithm. OpenSSH 10.0 (April 2025) made mlkem768x25519-sha256 — the NIST ML-KEM standard combined with X25519 — the default key exchange algorithm.

OpenSSH 10.1 and later warn you when a connection is not using a post-quantum key exchange:

The IETF is standardizing the hybrid SSH key exchange algorithms in draft-ietf-sshm-mlkem-hybrid-kex (revision 10, February 2026), defining mlkem768x25519-sha256, mlkem768nistp256-sha256, and mlkem1024nistp384-sha384.

Adoption is accelerating. Between October 2024 and March 2025, SSH key exchange with ML-KEM grew 554%. All the hybrids combine a post-quantum algorithm with a classical one, so if ML-KEM were to have a flaw, X25519 still protects the session — and vice versa.

Distribution Support

Red Hat Enterprise Linux 10 tells the story of how quickly this moved:

RHEL 10.1 was the first major Linux distribution to sign its packages with hybrid post-quantum keys. In RHEL 10.2, the FUTURE system-wide cryptographic policy permits only hybrid ML-KEM key exchange algorithms, discontinuing traditional non-post-quantum methods entirely.

What SSH Is Missing

Post-quantum user authentication does not exist yet. SSH user keys are still RSA or Ed25519. There is no standard for ML-DSA SSH host or user keys. Key exchange protects the session confidentiality; if an attacker steals your SSH key, the quantum-resistant key exchange does not help. This is an acceptable trade-off today — “store now, decrypt later” attacks target session data, not authentication keys — but it is a gap that will need to close.

Bottom line: if you are running OpenSSH 10.0+ or RHEL 10.1+, your SSH sessions are already quantum-resistant for key exchange. Check with ssh -vv and look for mlkem768x25519-sha256 in the negotiated KEX.

PKI: The Certificate Size Problem

Post-quantum PKI is where the engineering gets hard. The signature sizes that are merely awkward in a TLS handshake become structural problems when multiplied across certificate revocation, OCSP responses, and certificate transparency logs.

What Works Today

• DigiCert issues ML-DSA certificates through Trust Lifecycle Manager. You need OpenSSL 3.5+ to generate CSRs with ML-DSA keys.
• RFC 9881 defines how ML-DSA keys and signatures are encoded in X.509 certificates. The encoding is straightforward: a bare OID with no parameters, raw public key bytes in the SubjectPublicKeyInfo, and identical OIDs for signature and public key algorithms.
• Composite certificates (draft-ietf-lamps-pq-composite-sigs) embed both a classical and a post-quantum signature in a single certificate, providing quantum resistance while maintaining backward compatibility.

Merkle Tree Certificates: The Structural Answer

The most significant response to the size problem is Merkle Tree Certificates (MTCs), being standardized by the IETF’s PLANTS working group (PKI, Logs, And Tree Signatures). The current draft (revision 03, April 2026) is 83 pages and defines a fundamentally different certificate architecture.

Instead of each certificate carrying its own signature, certificates are batched into a Merkle tree. The CA signs the tree root once, and each certificate carries a short inclusion proof — a path of hashes from its leaf to the signed root.

The size savings are dramatic:

Google’s February 2026 announcement described three deployment phases:

1. Phase 1 (underway): Live feasibility study with Cloudflare, ~1,000 certificates enrolled
2. Phase 2 (target Q1 2027): Public infrastructure bootstrap
3. Phase 3 (target Q3 2027): Chrome Quantum-resistant Root Store

Chrome has designated MTC as its preferred path for post-quantum TLS authentication. DigiCert has open-sourced an MTC playground implementation.

There is a significant caveat: MTCs require clients to regularly fetch tree head updates through an out-of-band channel. This is trivial for auto-updating browsers, but difficult for command-line tools, embedded systems, or IoT devices. Servers will need to serve both MTC inclusion proofs and traditional X.509 certificates for the foreseeable future.

The 47-Day Certificate Timeline

In parallel, the CA/Browser Forum’s Ballot SC-081v3 (passed unanimously, April 2025) is driving certificate lifetimes shorter:

The 47-day target is not arbitrary: 31 days (one maximal month) + 15 days (half a 30-day month) + 1 day buffer. At 47 days, certificates expire before most revocation systems would have propagated a revocation anyway, reducing the dependency on OCSP and CRLs.

This creates a natural synergy with Merkle Tree Certificates. MTCs’ batch issuance model — where a CA signs a tree of thousands of certificates at once — fits naturally with short-lived certificates that are reissued frequently. The overhead of managing frequent issuance is offset by the dramatic reduction in per-certificate signature size.

FIPS 140-3: The Validation Gap

FIPS validation moves at its own pace, and that pace does not match deployment reality.

What Has Been Validated

AWS-LC FIPS 3.0 is the first open-source cryptographic module to include ML-KEM in a FIPS 140-3 validation (certificates #4631, #4759, #4816). All three ML-KEM parameter sets (512, 768, 1024) are covered.

AWS KMS now supports ML-DSA key creation and signing through its FIPS 140-3 Level 3 validated HSMs. This means you can use ML-DSA as a root of trust for code and document signing today — but only through KMS, not through the aws-lc-rs Rust crate’s stable API.

What Has Not

• ML-DSA is not yet in any FIPS-validated software library’s stable interface. In aws-lc-rs, it is behind the aws_lc_rs_unstable feature flag.
• OpenSSL 3.5’s FIPS provider includes ML-KEM for hybrid key exchange only (SecP256r1MLKEM768 and SecP384r1MLKEM1024). ML-DSA and SLH-DSA are in the default provider but not the FIPS provider.
• Ed25519 remains outside the FIPS boundary in most validated modules.

The average FIPS 140-3 processing time is 542 days. This is the real bottleneck: even if a library submits ML-DSA for validation today, the certificate may not arrive until late 2027 or 2028.

NIST’s April 2026 update to the FIPS 140-3 Implementation Guidance relaxed self-test requirements for ML-KEM, ML-DSA, and SLH-DSA — modules can now test internal algorithms rather than external ones, and check against the private key only (since it contains the public key). This should speed up future validations, but the queue is deep.

FIPS 140-2 sunsets in September 2026. Any system still relying on a FIPS 140-2-only module needs to migrate to a FIPS 140-3-validated module within four months.

Bottom line for FIPS-constrained deployments: ML-KEM key exchange is available in FIPS mode via AWS-LC. For ML-DSA signing, your options are AWS KMS or a PKCS#11 hardware token with its own PQC validation. Do not wait for software FIPS ML-DSA — use HSMs.

The Practitioner’s Scorecard

What to Do Today

If you manage TLS servers:

1. Verify your servers negotiate X25519MLKEM768. Most modern TLS libraries do this by default. If you are running rustls 0.23.27+, OpenSSL 3.5+, or behind Cloudflare/Akamai, you are already covered.
2. Plan for 200-day certificate lifetimes — the first SC-081v3 milestone took effect in March 2026. Automate your certificate renewal now if you have not already.

If you manage SSH infrastructure:

1. Update to OpenSSH 10.0 or later. On RHEL 10.1+, post-quantum SSH key exchange is on by default.
2. Look for the mlkem768x25519-sha256 KEX algorithm in your ssh -vv output. If you see sntrup761x25519-sha512 instead, that is also post-quantum — just the older algorithm.

If you operate a PKI or CA:

1. Test ML-DSA certificate issuance with OpenSSL 3.5 in a lab environment. The encoding rules (RFC 9881) have subtleties — no algorithm parameters, raw public key encoding — that differ from RSA and ECDSA.
2. If you need FIPS-compliant ML-DSA signing today, use a PKCS#11 token. Software FIPS validation for ML-DSA is at least 18 months away.

If you are planning a PQC migration:

1. Prioritize key exchange. This is the “harvest now, decrypt later” defense, and it is the most mature.
2. Do not block on ML-DSA for authentication. The size problem is real, and Merkle Tree Certificates may change the architecture before ML-DSA TLS authentication is broadly deployable.
3. Watch the PLANTS working group. MTCs are the most likely path to practical post-quantum TLS authentication at scale.

This is the first installment of a periodic series tracking post-quantum cryptography adoption. For implementation details — signing ML-DSA certificates, handling FIPS constraints, managing ASN.1 encoding — see the PKI.Next series.