What Are Post-Quantum Certificates? ML-DSA and the Road to 2035

Almost every certificate on the internet today relies on RSA or elliptic curves. A large enough quantum computer could break both, and with them the signatures that certificates depend on. That is why the US standards body NIST standardised new, quantum-safe signature algorithms in 2024, above all ML-DSA. But their keys and signatures are far larger, which makes moving certificates over hard. This guide explains the new algorithms, works through the size problem, introduces hybrid certificates and Merkle Tree Certificates, and sets out the timetables in the US, the UK and the EU.

Why quantum computers threaten certificates

RSA is secure because large numbers cannot be split into their prime factors efficiently; ECDSA relies on the discrete logarithm problem on elliptic curves. Shor’s algorithm, running on a large enough error-corrected quantum computer, solves both efficiently. No such machine exists yet.

For certificates the danger differs from encryption:

Encryption is already at risk, because attackers can record traffic today and decrypt it later (“harvest now, decrypt later”).
Signatures can only be forged once the quantum computer exists. But whoever then works out a CA’s private key can issue any certificate they like. Because changing root stores and devices takes years, the move has to start now.

For an example of what is at stake in practice, see post-quantum encryption for satellites.

The new algorithms: ML-DSA, SLH-DSA and FN-DSA

In August 2024 NIST published three standards:

FIPS 203, ML-KEM: key agreement, in other words for encryption.
FIPS 204, ML-DSA: lattice-based signatures (formerly CRYSTALS-Dilithium), the main candidate for future certificates.
FIPS 205, SLH-DSA: signatures built only on hash functions (formerly SPHINCS+). Very conservative, but with large signatures.

A fourth algorithm, FN-DSA (Falcon), with smaller signatures, is being prepared by NIST as FIPS 206. The sizes compared (public key / signature):

ECDSA P-256: 64 / about 64 to 72 bytes
RSA-2048: 256 / 256 bytes
ML-DSA-44: 1,312 / 2,420 bytes
ML-DSA-65: 1,952 / 3,309 bytes
ML-DSA-87: 2,592 / 4,627 bytes
SLH-DSA-128s: 32 / 7,856 bytes

For today’s key types, see how to create a private key and CSR.

Bar chart of signature sizes: ECDSA P-256 about 72 bytes, RSA-2048 256, ML-DSA-44 2,420, ML-DSA-65 3,309, ML-DSA-87 4,627 and SLH-DSA-128s 7,856 bytes. — Classical and quantum-safe signatures compared by size.

The size problem: a worked example

On every HTTPS connection, the server sends several signatures and keys: the handshake signature, the signatures in the leaf and intermediate certificates, two SCTs from Certificate Transparency logs and two public keys. A rough estimate if everything moved to ML-DSA-44:

5 signatures × 2,420 bytes = 12,100 bytes
2 keys × 1,312 bytes = 2,624 bytes
in total 14,724 bytes, about 14.4 KiB

With ECDSA P-256 today it is about 5 × 72 + 2 × 65 = 490 bytes, roughly 30 times less. This matters: at the start of a connection a server may send only about 10 packets of 1,460 bytes, around 14,600 bytes, before it has to wait for an acknowledgement. If the handshake is bigger, every new connection costs an extra round trip across the network.

Bar chart: today ECDSA signatures and keys take about 490 bytes; with ML-DSA-44 it would be 14,724 bytes, more than the TCP initial window of about 14,600 bytes. — A rough estimate of the handshake size.

Three routes to quantum-safe certificates

Pure post-quantum certificates: an ordinary X.509 certificate with an ML-DSA key and an ML-DSA signature. For private PKIs, devices and company networks this is the obvious route, and Google has said it will support such certificates in private PKIs; see how to run a private certificate authority.
Hybrid (composite) certificates: one certificate holds two keys and two signatures, such as ML-DSA and ECDSA. It stays secure as long as either algorithm holds, in case weaknesses are found in the new ones. The IETF is working on the standard, but these certificates are even larger.
Merkle Tree Certificates: Google and Cloudflare are currently trialling a new format. Instead of signing each certificate individually, the CA signs a tree of millions of certificates at once, and the browser receives only a short proof that its certificate is in the tree, much like Certificate Transparency. Chrome plans to accept these certificates from 2027 in a separate, quantum-resistant root store, and does not intend to add classic X.509 certificates with post-quantum signatures to its public root store for now.

What is already quantum-safe

Encryption is well ahead: the major browsers and many servers now negotiate TLS connections hybrid with X25519 and ML-KEM (the X25519MLKEM768 scheme). Traffic recorded today is therefore protected against future quantum computers too. The signatures in certificates are still classical, which is fine as long as no suitable quantum computer exists.

Timetables for the move

US (NIST): report IR 8547, finalised in October 2026, deprecates RSA, ECDSA and classical key agreement after 2030 and disallows them after 2035.
UK (NCSC): organisations should finish discovery and an initial migration plan by 2028, complete their highest-priority migrations by 2031 and complete the move by 2035.
EU: a roadmap agreed by member states in 2025 aims to start the transition by the end of 2026, move high-risk systems by the end of 2030 and as many systems as feasible by 2035.
Chrome: Merkle Tree Certificates are to be trialled with Certificate Transparency log operators from the first quarter of 2027, with the separate root store planned for the third quarter of 2027.

For organisations, that means building an inventory of all certificates and keys now, relying on short lifetimes and automation, and designing systems so that algorithms can be swapped (crypto agility). With 47-day lifetimes from 2029, switching to new algorithms takes only weeks; see why certificate lifetimes are getting shorter.

Six rows: new NIST standards in 2024, NIST IR 8547 in October 2026, Merkle Tree Certificates in Chrome in 2027, UK planning by 2028, deprecation and priority migrations around 2030 to 2031, completion by 2035. — Key dates for quantum-safe certificates.

Try it with OpenSSL

From version 3.5, OpenSSL supports ML-DSA, ML-KEM and SLH-DSA directly. This creates a test key and a self-signed test certificate:

openssl genpkey -algorithm ML-DSA-65 -out pq.key
openssl req -new -x509 -key pq.key -subj "/CN=pq-test" -days 30 -out pq.pem
openssl x509 -in pq.pem -noout -text

The output shows a 1,952-byte public key. Older versions, such as OpenSSL 3.0 on Ubuntu 24.04, do not know these algorithms yet.

Frequently asked questions

Do I need to change anything on my website now?

No. Public CAs do not issue quantum-safe website certificates yet. What matters is renewing certificates automatically, so that the later switch needs no manual work.

Is my HTTPS connection already quantum-safe?

The encryption in current browsers usually is, thanks to hybrid key agreement with ML-KEM. The certificate check is not yet, but that only becomes a problem once a real quantum computer exists.

Why not just use longer RSA keys?

Shor’s algorithm breaks very long RSA keys too, with only moderate extra effort. Longer keys merely postpone the problem.

Are the new algorithms safe?

They went through about eight years of public scrutiny. Because they are younger than RSA, many organisations use hybrid solutions that combine both during the transition.

Conclusion

Quantum computers would break RSA and ECDSA and make certificate signatures forgeable. Their successors, ML-DSA and SLH-DSA, have been standardised since 2024, but their large signatures make certificate chains around 30 times bigger. That is why hybrid certificates and Merkle Tree Certificates are being developed alongside pure post-quantum certificates. The move is due to be complete by 2035.