Post quantum signatures and certificates the hardest part of migration

[DeanAmbrose11]

TL;DR

• Post quantum key exchange is already widely deployed, but post quantum signatures and certificates are only beginning
• ML-DSA signatures are far larger than today's: ML-DSA-44 is about 2,420 bytes and ML-DSA-65 is 3,309 bytes, compared with about 64 bytes for ECDSA P-256
• RFC 9881, published in October 2025, defines how ML-DSA keys and signatures appear in X.509 certificates, and composite certificate work continues in the IETF
• Chrome plans to favour Merkle Tree Certificates for the web, with a quantum resistant root store targeted for the third quarter of 2027, and Let's Encrypt aims for production MTCs in 2027
• Code signing, firmware and private PKI can move sooner, and Microsoft made ML-DSA generally available in Active Directory Certificate Services in May 2026

Why signatures are harder than key exchange

Over the past two years, post quantum key exchange has gone from experiment to default. Browsers, content delivery networks, OpenSSH and major libraries now negotiate hybrid ML-KEM key exchange automatically, and Cloudflare reports that more than two thirds of browser traffic to its network is protected this way. That progress tackles the most urgent risk, harvest now, decrypt later. It also creates a false impression that the post quantum transition is mostly finished

Signatures and certificates are a different story. Cloudflare itself described the authentication transition in mid 2026 as having only just begun. Signatures sit inside certificate chains, software updates, firmware, identity tokens, documents and hardware roots of trust, many of which are long lived and hard to change. They also depend on ecosystems of certificate authorities, browsers, operating systems and devices agreeing on formats and policies at the same time

This thread explains why signatures are the hardest part of migration, what standards exist, how the web plans to handle certificates and where organisations can make progress today. It is intended as a practical reference rather than a deep cryptographic dive. The good news is that a credible path now exists. It simply takes more coordination than key exchange did

The timeline logic

Key exchange is urgent because recorded traffic can be decrypted later. Signatures are different. A forged signature only causes harm once an attacker can forge it, which requires a capable quantum computer to exist. That is why the US Executive Order 14412 gives federal high value systems until 31 December 2031 for signatures, one year after the key establishment deadline. Many other national plans follow the same priority order

There is an important exception. Signatures used in systems that must remain trustworthy for many years need to be quantum resistant well before Q-Day. Firmware roots of trust in cars, industrial controllers and medical devices may stay in service for fifteen years or more. Root certificates often have very long lifetimes. For these, signature migration needs to begin now, which is why Google's 2029 target places particular emphasis on authentication

The size problem

Post quantum signatures are much larger than classical ones. An ECDSA P-256 signature is about 64 bytes and its public key about 64 bytes. ML-DSA-44, the smallest ML-DSA parameter set, has a signature of about 2,420 bytes and a public key of 1,312 bytes, while ML-DSA-65 has a signature of 3,309 bytes. SLH-DSA signatures range from roughly 7,800 bytes to nearly 50,000 bytes depending on the parameter set

Those sizes matter because a typical TLS handshake contains several signatures and public keys. The server certificate, intermediate certificates, Certificate Transparency proofs and the handshake signature all add up. Let's Encrypt has noted that a straightforward switch to post quantum certificates would push a typical handshake past 10 kilobytes, and Cloudflare research links handshakes of that size to failed and slower connections on real networks. The web cannot simply swap algorithms and carry on

Bandwidth is not the only issue. Some network middleboxes, embedded TLS stacks and older clients assume handshake messages fit within certain limits. Larger messages can trigger fragmentation, extra round trips or outright failures. Early tests of post quantum key exchange exposed similar problems, and signatures are several times larger

FN-DSA, based on FALCON and planned as FIPS 206, offers smaller signatures of around 666 bytes at its lower security level. That makes it attractive for constrained settings. However, it is harder to implement safely because of its floating point arithmetic, and as of April 2026 NIST said the draft was still in the administrative approval chain without a release date. Most organisations are therefore planning around ML-DSA first

Standards in place and in progress

The core algorithms are standardised in FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA, both published in August 2024. RFC 9881, published by the IETF in October 2025, specifies algorithm identifiers for using ML-DSA in X.509 certificates. That gives certificate authorities and software vendors a common format for pure ML-DSA certificates. Work on using ML-DSA directly in TLS is progressing in a separate IETF draft

Composite certificates combine a classical and a post quantum signature in a single certificate, so that an attacker must break both. The IETF LAMPS working group has been developing composite ML-DSA signatures through many draft revisions. Composite approaches appeal to organisations that want a cautious hybrid transition, especially in Europe where agencies favour hybrids. They add size and complexity, however, which is part of why the web is exploring other options

Stateful hash based signatures, LMS and XMSS, have been standardised for longer. NIST approved them in SP 800-208 in 2020, and the NSA's CNSA 2.0 recommends them for software and firmware signing in national security systems. They are very conservative cryptographically, but they require careful state management, because reusing a one time key breaks security. They suit tightly controlled signing environments such as firmware builds

Choosing between signature algorithms is therefore a matter of fit. ML-DSA is the general purpose default, SLH-DSA offers very conservative security based only on hash functions at the cost of size, LMS and XMSS suit controlled firmware signing, and FN-DSA may later serve constrained settings. Many organisations will use more than one. Crypto agility makes that mix manageable

How the web plans to handle certificates

The web PKI is the most visible certificate system, and it faces the hardest size constraints. In early 2026, the Chrome team set out a plan built around Merkle Tree Certificates, developed in the IETF's PLANTS working group. Instead of each certificate carrying its own chain of signatures, a certificate authority signs a tree head covering many certificates at once. Browsers receive compact proofs that a certificate is included in a published tree, which also builds transparency into issuance

Chrome has said it does not plan to add traditional X.509 certificates containing post quantum signatures to the Chrome Root Store, focusing instead on Merkle Tree Certificates. Its published timeline includes a feasibility study with Cloudflare, certificate transparency log operators bootstrapping public MTCs in the first quarter of 2027, and the launch of a Chrome Quantum-resistant Root Store in the third quarter of 2027. The existing root program continues alongside. Plans like this can change, so watching official Chrome announcements is wise

Let's Encrypt announced on 3 June 2026 that it will pursue Merkle Tree Certificates, aiming for a staging environment in late 2026 and production readiness in 2027. Certificates will remain free and automated through ACME. In the common case, the authentication data in a handshake would be one signature, one public key and one inclusion proof, smaller than today's handshakes. Until then, Let's Encrypt advises server operators to enable hybrid key exchange now, since encryption is the more urgent risk

Where organisations can move today

Private PKI is one of the best places to start. Internal certificate authorities issue certificates for employees, devices, servers and services, and organisations control both ends of those relationships. On 13 May 2026, Microsoft made ML-DSA support generally available in Active Directory Certificate Services on Windows Server 2025, bringing post quantum signatures into the PKI that many enterprises already run. Testing internal ML-DSA certificates now builds skills and exposes compatibility issues early

Code signing and software updates are another strong candidate. Organisations control their own build pipelines and can add post quantum signatures alongside existing ones. Google has said Android 17 will include ML-DSA based signature protection, and open source projects such as Sigstore have begun adding ML-DSA support to their specifications. Dual signing during a transition lets old clients keep working while new clients verify post quantum signatures

Firmware and hardware roots of trust need the earliest attention of all. Devices being designed today may still be in service in 2040. Choosing hardware security modules, secure elements and boot loaders that support LMS, XMSS or ML-DSA now avoids being locked into quantum vulnerable roots for the life of the product. Many silicon vendors have begun shipping such support

Documents and archives raise a different question. Signed contracts, records and certificates of authenticity may need to be verifiable for decades. Some organisations plan to re-sign archives with post quantum signatures or add long term timestamping before classical signatures lose their value. Thinking about this early avoids a scramble later

A practical signature migration checklist

• Inventory every place signatures are created or verified: TLS, code signing, firmware, documents, tokens, email and hardware roots
• Rank by lifetime: long lived roots, firmware and archived documents first
• Test ML-DSA in private PKI, starting with internal services you control
• Plan dual or composite signing where old and new clients must coexist
• Ask suppliers for ML-DSA, LMS or XMSS support in HSMs, secure elements and signing services
• Track Chrome, Let's Encrypt and IETF PLANTS for public web certificates

Common pitfalls

One pitfall is assuming public web certificates must move first. In reality, the public web will follow browser and certificate authority timelines, and individual site owners have little to do beyond keeping software current. Internal systems, code signing and firmware are where organisations can and should act. Focusing effort there delivers far more value in the near term

Another pitfall is underestimating size effects in constrained protocols. IoT protocols, smart cards, vehicle networks and some industrial systems have tight message limits. Larger signatures may require protocol changes, fragmentation or different algorithm choices. Early testing on real hardware prevents unpleasant surprises

A third pitfall is neglecting verification. Signatures only protect anyone if verifiers check them correctly. Every client, device and service that verifies signatures must be updated to understand the new algorithms. Old verifiers that silently ignore unknown signatures could undermine the whole effort

Closing thoughts

Signatures and certificates are the hardest part of post quantum migration because they touch long lived trust anchors and need whole ecosystems to coordinate. The path is clearer than it was a year ago. Standards exist, major vendors are shipping support, and the web has a concrete plan for compact certificates. The work is substantial, but it is well understood

If you have tested ML-DSA in your own PKI or code signing pipeline, please share your results below. Practical experience is the most valuable contribution anyone can make to this topic. Version numbers and dates will help others compare




Key references for citation

• NIST FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), August 2024
• RFC 9881, Algorithm Identifiers for ML-DSA in X.509, October 2025
• NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes, 2020
• Chrome team plans for Merkle Tree Certificates and a quantum-resistant root store, 2026
• Let's Encrypt, post-quantum certificates announcement, 3 June 2026
• Cloudflare, post on Executive Order 14412 and authentication status, 23 June 2026