Post-quantum signatures are still being chosen, so build PKI to switch twice

The week

August 13, 2026 marked two years since NIST published its first post-quantum standards: FIPS 203 for key establishment (ML-KEM), and FIPS 204 and FIPS 205 for digital signatures (ML-DSA and SLH-DSA). The signature side was still moving. In May 2026 NIST advanced nine candidates to the third round of its additional signature process, a phase it expected to last about two years. Updated submission packages were due on August 14, according to trade press reports of NIST’s schedule. The process was launched to add schemes that do not rely on lattices and to find shorter signatures. FN-DSA, a compact lattice signature planned as FIPS 206, was still awaiting a final standard. Separately, Google had said in February 2026 that Chrome would pursue Merkle Tree Certificates and a separate quantum-resistant root store, rather than placing large post-quantum signatures in today’s certificates.

Earlier in this series we argued that lower quantum resource estimates in spring 2026 moved signatures up the post-quantum queue, and that hardware refresh cycles set their pace. Federal policy agreed. A June 2026 executive order set the end of 2031 for post-quantum signatures on agencies’ high value assets and high impact systems. The harder fact is that the signature choice itself is not settled. ML-DSA signatures run to about 2.4 kilobytes at the smallest parameter set, against roughly 64 bytes for an ECDSA P-256 signature. SLH-DSA signatures are larger still. That size pressure is why NIST is still evaluating alternatives, and why the web may adopt a different certificate structure altogether. An organization that moves its signatures now should expect to move some of them again.

The useful question is therefore how costly a second change would be, and that depends on how long a signature must remain verifiable. Every signature an organization makes or relies on falls into one of three tiers: signatures checked in the moment, signatures that anchor trust for years, and signatures that must be verified decades later. Each tier needs a different kind of agility.

Signatures checked in the moment

This tier covers TLS handshakes, single sign-on assertions, API tokens and device authentication. A signature here is verified within seconds or hours, then discarded. A future quantum computer cannot go back and forge an authentication that has already happened. The quantum risk to this tier therefore begins only when such a computer exists, which makes it the least urgent.

The work is mostly about performance and protocol support. Larger signatures and certificate chains add bytes to every handshake. Constrained networks, older load balancers and embedded clients feel that first. Teams should test identity providers, gateways and mobile apps with post-quantum signatures in a lab before any vendor forces the issue. They should also avoid hard-coding algorithm identifiers in application code. Where configuration controls the algorithm, a second switch is a change ticket rather than a release.

Automation helps this tier more than any algorithm choice. Public TLS certificate lifetimes are falling to 47 days by 2029 under a CA/Browser Forum ballot, which forces automated issuance and renewal. The same automation that rotates certificates every few weeks will carry a new signature algorithm when browsers accept one. Teams that still renew certificates by hand should fix that first.

Signatures that anchor trust for years

This tier is where second changes become expensive. Root and intermediate certificate authorities, internal enterprise PKI, code and firmware signing keys, and the hardware security modules that hold them all have long lives. A private root often runs for well over a decade. A firmware signing key may be burned into devices that stay in service far longer than the team that chose it.

Federal policy has already put dates on part of this tier. NSA’s CNSA 2.0 guidance for national security systems calls for software and firmware signing to prefer quantum-resistant algorithms from 2025 and use them exclusively by 2030. It points to stateful hash-based signatures, LMS and XMSS, for that use. Those schemes are conservative, but they require careful state management in the HSM, and a mistake can be catastrophic.

Refresh cycles decide when hardware can change. Design decides whether it can change twice. For banks, health systems and agencies, three choices reduce the cost of a second switch. First, stand up a parallel post-quantum hierarchy for internal PKI rather than re-keying the existing one. That lets relying systems trust both during a transition. Second, buy HSMs whose firmware can add algorithms through updates, and write that into the contract with a support term. Third, make sure devices that verify firmware can accept a new root through an authenticated update. A medical device or payment terminal that trusts a single fixed key is a replacement project waiting to happen.

Signatures that must be verified decades later

The third tier holds signatures whose value lies in being checked long after they are made. Examples include signed loan and mortgage files, consent forms and attestations in medical records, contracts, regulatory filings, court and land records, and tamper-evident audit logs. Here the threat runs backward. Once a quantum computer can forge a classical signature, any old document signed only that way loses its evidential strength.

The remedy is an archival practice rather than an algorithm. Long-term validation renews the protection on stored signatures before the old algorithm weakens, typically by adding a fresh timestamp or an evidence record over the original. That can be done with ML-DSA or SLH-DSA today, then repeated with whatever comes next. Records managers, legal and the PKI team need a shared schedule for re-protection, keyed to the retention class of each record set. Document management and e-signature vendors should be asked whether their archive formats support adding a new protection layer without breaking the original signature.

Across the three tiers, the common control is a register of signing keys and trust anchors. It should record each key’s algorithm, lifetime, holder, the systems that verify it and the cost of replacing it. That register, more than any single algorithm decision, determines whether the second change is routine or a crisis.

With hindsight

By October 2026, the pattern is clear enough to plan around. NIST’s third signature round is under way and is expected to run about two years. FN-DSA has not reached a final standard that we have seen. On the web, the first certificate authority applications to Chrome’s Merkle Tree Certificate test program appeared in July, ahead of the quantum-resistant root store Google has targeted for 2027. Key establishment kept spreading quietly through browser, operating system and library updates. None of this suggests that ML-DSA or SLH-DSA are unsafe choices for internal PKI or code signing today. It does mean that public web certificates, internal hierarchies and archives may end up on different schemes. Organizations that separated those tiers, and kept their signing key register current, can follow each track at its own pace.