Post-Quantum Certificates and PKI: The Hard Part of Securing the Web
The other half of the handshake
A secure connection has two jobs. First, agree on a secret (key exchange, covered in the hybrid guide). Second, prove you are talking to the real website and not an impostor. The second job is done with certificates and digital signatures, organized into a system called public key infrastructure, or PKI. Both halves need to become post-quantum in the end, and the second half is harder.
Why signatures are urgent later, but harder now
Recorded traffic can be cracked years after the fact, which is why key exchange came first. A forged signature is different: an attacker needs a working quantum computer at the time of the connection to impersonate a site. That makes the deadline softer, but certificates are slow to change, because browsers, operating systems, certificate authorities (CAs), servers and devices must all agree. Old devices in the field may never be updated.
The size problem
NIST's new signature standards, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), produce signatures and keys that are many times larger than today's elliptic curve ones. A normal TLS handshake sends a chain of certificates containing several keys and signatures. Replace each with a post-quantum version and the handshake could grow by many kilobytes, slowing page loads, hurting mobile users and stressing networks. One analysis in the trade press claimed authentication data could shrink from about 14,700 bytes to as little as 736 bytes with the new Merkle design, but that comes from a secondary blog and I could not verify it against Google's own materials, so treat it as illustrative.
Google's answer: Merkle Tree Certificates
In early 2026, the Chrome team reported it has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Instead it is working with partners in the IETF (the PLANTS working group) on Merkle Tree Certificates (MTCs). The idea in plain English: a certificate authority signs one "tree head" that covers potentially millions of certificates. Your browser then receives a short proof that the site's certificate is inside that tree, instead of a long chain of signatures. Fewer big signatures travel over the wire, and transparency logging becomes built in.
The reported plan, as relayed by The Hacker News in March 2026:
- Phase 1 (in progress): a feasibility study with Cloudflare on real traffic.
- Phase 2 (Q1 2027): invite Certificate Transparency log operators to help bootstrap public MTCs.
- Phase 3 (Q3 2027): finalize requirements for onboarding more CAs to a new Chrome Quantum-resistant Root Store that supports only MTCs.
Plans like this can shift, so check Chrome's own announcements.
What software support looks like
Cloudflare's documentation says no listed browser supports post-quantum signatures yet. On the library side, OpenSSL, BoringSSL, AWS-LC and Botan support the ML-DSA parameter sets, and NGINX supports signatures when built with OpenSSL 3.5 or later. Caddy and Traefik are reported as waiting on ML-DSA support in Go, and rpxy on Rust support. In short, the building blocks exist, and the web ecosystem is deciding how to assemble them.
Private PKI is a faster path
Not every certificate lives on the public web. Companies run private PKIs for devices, internal services, code signing and VPNs. Those are controlled by one organization, so it can move earlier, test new signature types and replace roots on its own schedule. Long-lived items, such as firmware signing keys and device identity certificates, deserve the earliest attention, because devices that last 15 years need to verify updates for 15 years. See crypto agility for why being able to swap algorithms matters.
Other challenges
- Hardware security modules and smart cards may need firmware or replacement to handle new algorithms.
- Certificate lifetimes are being shortened across the industry, which makes automated renewal more important and rollouts easier.
- Standards still in motion: NIST's FN-DSA, a compact signature option, is not finalized (see the standards status guide).
Why this is exciting
This is an unusually clean-slate moment for internet identity. The same effort that makes certificates quantum resistant may also make them smaller, faster to verify and more transparent. A safer web and a quicker web at the same time is an optimistic outcome, and it exists because researchers took the quantum threat seriously early.
None of this is financial advice or a statement about any token. The QNT memecoin is independent of Quantinuum Ltd and of any standards body.
Sources and further reading
- The Hacker News: Google develops Merkle Tree Certificates (March 2026)
- Cloudflare docs: post-quantum support, signatures and certificates
- Cloudflare blog: post-quantum IPsec and authentication standards (April 30, 2026)
- SecurityBrief: Google tests Merkle Tree Certificates
Reported as of 2026-10-09. Standards and rollout numbers change often, so check the primary documents before relying on any figure. This is education, not financial advice. The QNT memecoin is independent of Quantinuum Ltd, the real company, and of any lab or government.
Frequently asked questions
Why are certificates harder to upgrade than key exchange?
Post-quantum signatures and keys are much larger, and many parties (browsers, CAs, servers, devices) must change together.
What are Merkle Tree Certificates?
A proposed design where a CA signs one tree head covering many certificates and the browser gets a short inclusion proof instead of a full chain. It is being developed in the IETF.
Does Chrome support post-quantum certificates today?
Per Cloudflare's documentation no listed browser supports post-quantum signatures yet. Google reported a phased MTC plan through Q3 2027.
Is a forged certificate a harvest now, decrypt later risk?
No. Forging needs a quantum computer at connection time, so urgency is lower than for key exchange, but long-lived trust anchors still need early planning.
Does this affect QNT?
No. The token is an independent memecoin. This is not financial advice.
Keep reading
- ML-DSA Explained: The Post-Quantum Signature Standard
ML-DSA (FIPS 204) is NIST's main post-quantum digital signature standard. Learn how lattice signatures work, how they compare to ECDSA, and the trade-offs. - SLH-DSA Explained: Hash-Based Stateless Signatures
SLH-DSA (FIPS 205) is NIST's hash-based, stateless post-quantum signature standard. Learn how it works, why it is cautious, and its size and speed trade-offs. - Quantum-Resistant Signatures Explained
What are quantum-resistant digital signatures? Learn the main families, the NIST standards and the trade-offs blockchains face when upgrading. - Crypto Agility Explained: Preparing for Algorithm Change
Crypto agility is the ability to swap cryptographic algorithms without rebuilding a system. Learn why it matters for the post-quantum shift and for blockchains.
All Quantum events, catalysts and roadmap guides | Back to top | Search the site
Main pages: Quantum computing explained | Quantum and crypto | Companies | Quantum news | Glossary