Skip to content
Quantum Defense

Home / Learn / Practitioner / Lesson 12

Part II, Practitioner · Lesson 12

Migrating certificates, code signing and firmware

By Kyeson Blake Utley15 min read1 interactiveSome tech background
The short version

Signatures are like wax seals that prove who sent a letter. Quantum computers can't fake old seals that were already checked, but one day they could fake new ones. The new quantum-resistant seals are much bigger, and websites send several on every visit, so engineers are inventing smarter ways to send fewer of them.

You'll learn to

  • Explain why signature migration has different timing from key-exchange migration.
  • Estimate how much post-quantum signatures add to a TLS certificate chain and why that matters for performance.
  • Describe the current direction of web PKI (Merkle Tree Certificates) and the state of post-quantum X.509 standards.
  • Plan code-signing and firmware-signing migration, including the trade-offs of LMS/XMSS, ML-DSA and SLH-DSA.

The previous lessons moved key exchange to post-quantum algorithms. That protects secrets. This lesson is about the other half of public-key cryptography: signatures, which protect trust. Certificates, software updates, firmware, documents and DNS records all depend on them.

Why signatures run on a different clock

A quantum computer in 2035 can't retroactively forge a signature that your browser checked in 2026; that check is over. So signatures don't face harvest-now-decrypt-later. But two things make them urgent anyway:

  • Long-lived trust anchors. Root certificates, firmware signing keys and secure-boot keys can stay in service for a decade or more. If a device's boot ROM only verifies ECDSA, then once ECDSA can be forged, anyone can sign malware the device will accept, and no update can fix it because updates are verified the same way.
  • Size. Post-quantum signatures are big, and some protocols send a lot of them. Making room takes engineering time.

That's why CNSA 2.0 puts software and firmware signing first: support and prefer by 2025, exclusive by 2030.

How many signatures does a website send?

More than you'd think. Cloudflare's engineers counted that a first visit to their blog involves six signatures and two public keys: the certificate chain, two Certificate Transparency receipts and an OCSP staple, plus the server's signature over the handshake. Each one grows from roughly 64–72 bytes (ECDSA P-256) to thousands of bytes with ML-DSA.

Some definitions:

  • A certificate chain links the website's own (leaf) certificate to a trusted root via one or more intermediate certificates. Each certificate holds a public key and is signed by its issuer.
  • A signed certificate timestamp (SCT) is a signed receipt from a Certificate Transparency log, proving the certificate was publicly logged.
  • CertificateVerify is the TLS 1.3 message in which the server signs the handshake with its leaf key, proving it holds the private key.

Choose the algorithms and see the byte bill:

The marker that matters is TCP's initial congestion window: how much a server may send before waiting for the client's acknowledgment. RFC 6928 set it at 10 segments, roughly 14 KB with typical packet sizes. Cross it and the handshake needs an extra round trip. Cloudflare's measurements found that adding about 9 KB slowed handshakes by about 15%, and that crossing the roughly 10 KB mark with a typical congestion window likely adds a round trip, which could mean a slowdown of more than 60%. They also found that large certificate chains broke some connections outright, suggesting clients or middleboxes that choke on bigger chains.

Where the web PKI is heading

Because simply swapping ECDSA for ML-DSA everywhere is so expensive, the web is unlikely to do it the obvious way.

In February 2026, Google's Chrome team said it has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Instead it is backing Merkle Tree Certificates (MTCs), developed in the IETF's PLANTS working group (PKI, Logs, And Tree Signatures). In an MTC system, a certificate authority signs a single "tree head" covering many certificates, and the browser receives a compact proof that a certificate is included, instead of a chain of separate signatures. Chrome's announced phases:

  • Phase 1 (underway): a feasibility study with Cloudflare, where every MTC connection is backed by a traditional certificate.
  • Phase 2 (Q1 2027): Certificate Transparency log operators invited to bootstrap public MTCs.
  • Phase 3 (Q3 2027): launch of a Chrome Quantum-resistant Root Store that supports only MTCs.

Chrome also said it expects to support post-quantum X.509 certificates in private PKIs, the internal certificate systems companies run for themselves. Plans like these can shift; check the current status before committing.

Private PKI: you can start now

Inside your organization you control both ends, so you can move sooner. The standards exist: RFC 9881 (October 2025) defines how to use ML-DSA in X.509 certificates, and RFC 9909 does the same for SLH-DSA. Practical steps:

  1. Inventory your internal CAs, what they issue, and which relying parties (servers, clients, devices) verify them.
  2. Check whether your CA software, HSMs and relying-party libraries support ML-DSA. Many need upgrades first.
  3. Stand up a test hierarchy with an ML-DSA root and intermediate, and issue to non-critical services.
  4. Measure. Larger chains affect constrained devices and high-volume service-to-service traffic most.
  5. Plan root lifetimes. A new root created now may need to be trusted into the 2040s, so its algorithm choice deserves conservatism.

The IETF is also standardizing composite certificates that carry both a classical and a post-quantum signature, the signature equivalent of hybrid key exchange. Watch that work if you need to support old and new verifiers with one certificate.

Code signing and firmware

Code and firmware signing is where the lead time bites hardest, and where the algorithm choice is most interesting.

Option 1: stateful hash-based signatures (LMS, XMSS)

LMS (RFC 8554) and XMSS (RFC 8391) are approved in NIST SP 800-208, and CNSA 2.0 specifies them for software and firmware signing. They rest only on hash functions, they're compact and verification is simple enough for small boot loaders. The catch: they're stateful. Each signature uses up a one-time key, and the signer must never reuse one. Reuse is catastrophic, because two signatures from the same one-time key can let an attacker forge others. (Lamport signatures show why.) They fit a controlled signing service, typically inside an HSM, that signs a limited number of releases. They don't fit anything that might restore a backup of the key and accidentally sign again from old state.

Option 2: ML-DSA

Stateless, fast and general-purpose, with signatures of 2,420 to 4,627 bytes. It's a natural fit for signing software packages and containers, where a few kilobytes per artifact are irrelevant. CNSA 2.0 requires ML-DSA-87 for general signatures.

Option 3: SLH-DSA

Stateless and hash-based, so it combines the conservative assumption with no state to manage, at the cost of large signatures (7,856 bytes for SLH-DSA-SHA2-128s) and slow signing. Reasonable for rarely used, high-value keys such as a root that signs other keys.

A firmware plan

  1. New hardware: require that the boot ROM or secure element can verify a post-quantum signature (LMS, XMSS or ML-DSA) before you sign a purchase order. This is the one step you can't add later.
  2. Dual signing: during the transition, sign releases with both the classical and the post-quantum key, so old and new verifiers both work.
  3. Protect the state: if you choose LMS or XMSS, keep the signing key and its counter in an HSM that supports stateful signatures, and design backup and disaster recovery so state can never roll back.
  4. Plan key rotation: make sure devices can accept a new signing key via an authenticated update, so you aren't stuck with today's key for the life of the device.

Putting the track together

You now have the practitioner's map: the standards (lesson 7), hybrid key exchange already live on the web (lesson 8), the deadlines (lesson 9), the inventory (lesson 10), agility (lesson 11) and the signature migration. In order of urgency for most organizations: protect harvestable key exchange, make sure new hardware can verify post-quantum signatures, inventory everything, then work through the long tail while the web PKI settles. The Engineer track opens the hood on how these algorithms work.

Summary

  • Signatures aren't threatened by harvest-now-decrypt-later, but long-lived trust anchors and firmware need lead time.
  • A TLS handshake carries several signatures; swapping ECDSA for ML-DSA can push it past TCP's initial window and add a round trip.
  • Chrome has no immediate plan for post-quantum X.509 in its root store and is backing Merkle Tree Certificates, with phases planned for 2027.
  • Private PKIs can start now: RFC 9881 and RFC 9909 define ML-DSA and SLH-DSA in X.509.
  • For firmware, LMS/XMSS are compact but stateful (never reuse state); ML-DSA and SLH-DSA are stateless alternatives.
  • The one irreversible step: new hardware must be able to verify a post-quantum signature before it ships.

Questions

Get five of six right to mark the lesson complete. They also feed the final exam.

Sources

CourseQuantum Defense
Sheet12 of 18
PartII · Practitioner
Rev.18 Oct 2026
Sources10 cited
Found an error?Send a correction