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

The week

Every time you open a banking app, install a software update or sign a mortgage electronically, a piece of mathematics vouches that what you are seeing is genuine. It is called a digital signature, and it does for computers what a notary’s seal does for paper: it proves who produced something and that nobody has altered it since. Today’s signatures rely on math problems that ordinary computers cannot solve in any useful time. A large enough quantum computer, a machine that works on very different physical principles, is expected to be able to solve some of them, which would let an attacker forge signatures.

For that reason the US National Institute of Standards and Technology, NIST, has spent years choosing replacement algorithms, known as post-quantum cryptography. August 13, 2026 marked two years since NIST published its first post-quantum standards: FIPS 203 for key establishment (ML-KEM), the process two computers use to agree on a secret key, 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. On July 29 the HAWK team withdrew its scheme, leaving eight. 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, the family of math problems behind ML-DSA, 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 current certificates. The world’s most widely used browser was signaling that the web might change the structure of how websites prove their identity instead of swapping one signature for another.

For anyone responsible for an organization’s security, the week posed an uncomfortable question. If the replacement is still being chosen, how do you start replacing?

Signatures had already moved up the post-quantum queue, and 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, one of the most common signatures in use today. The post-quantum signature is many times larger, and 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. First, what signatures and certificates actually do.

Keys, certificates and the chain of trust

A digital signature works with a pair of keys. The private key is kept secret by the signer and used to create signatures. The public key is shared with everyone and used to check them. If a document is changed by even one character, the check fails. The security depends on it being practically impossible to work out the private key from the public one, and that is exactly the kind of problem a large quantum computer is expected to be able to crack for today’s algorithms.

Proving that a public key really belongs to your bank, and not to an impostor, is the job of a certificate, a small digital document that binds a public key to an identity, signed by a trusted certificate authority. The certificate authority’s own key is vouched for by a higher authority, and so on up to a root, a key that devices and browsers are configured to trust from the start. The whole arrangement, of roots, intermediate authorities, certificates and the rules for issuing and revoking them, is called public key infrastructure, or PKI. Trust passes down that chain, and it ends in a key that everyone has agreed in advance to accept.

Two more terms matter. A hardware security module, or HSM, is a tamper-resistant device that stores private keys and performs signing without ever letting the keys out; banks and certificate authorities rely on them. And TLS is the protocol behind the padlock in a browser, which uses certificates and signatures every time a secure connection is set up.

With that in mind, 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, meaning the ability to change algorithms without rebuilding everything around them.

Tier one: signatures checked in the moment

This tier covers TLS handshakes, single sign-on assertions (the digital note that tells an application you have already logged in elsewhere), API tokens (the passes that let one system call another) 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. A load balancer, the device that spreads incoming traffic across servers, may have fixed limits on how much data it expects at the start of a connection; a few extra kilobytes can push it over. 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. The difference is real: a change ticket can be approved and applied in days, while a software release means development, testing and deployment across every place the code runs.

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 CA/Browser Forum is the industry body where certificate authorities and browser makers agree the rules for website certificates. 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.

Tier two: 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 HSMs 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. Code signing is how a device or operating system confirms that a software update really came from its maker; firmware is the low-level software built into hardware, from routers to infusion pumps.

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, built on well-understood mathematics, but they require careful state management in the HSM. “Stateful” means the signer must keep track of which one-time keys it has already used; reusing one by mistake, after a backup restore for instance, 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.

• 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.
• Buy HSMs whose firmware can add algorithms through updates, and write that into the contract with a support term. An HSM that can only ever do what it did on delivery day locks in the current choice.
• 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.

Take a regional hospital network with thousands of connected devices, from bedside monitors to badge readers. If each model checks its updates against one fixed key that cannot be changed, then when that key’s algorithm must be retired, every one of those devices has to be physically replaced or reworked. If, instead, the devices accept a new trusted root delivered through a properly signed update, the change becomes a scheduled software rollout. The difference between those two outcomes is set at the moment of purchase, often years before anyone thinks about quantum computers.

Tier three: 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. A borrower disputing a loan agreement, or a litigant challenging a consent form, could argue that the signature no longer proves anything.

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. It works like a notary re-certifying an old document: the original signature remains, and a new, stronger seal is added on top, dated now, attesting that the document existed in this form at this time. That can be done with ML-DSA or SLH-DSA today, then repeated with whatever comes next.

Say a county land records office has accepted electronically signed deeds for years and must keep them indefinitely. Each deed carries a classical signature. If nothing is done, the day classical signatures can be forged is the day every one of those deeds becomes harder to defend in a property dispute. If the office periodically wraps its archive in fresh protection, using current algorithms and a trusted timestamp, each deed carries a continuous chain of evidence that it has not changed since it was recorded. The work is routine if it is scheduled, and very difficult if it is attempted in a hurry.

Records managers, legal and the PKI team need a shared schedule for re-protection, keyed to the retention class of each record set. A mortgage file kept for the life of a loan and a clinical consent form kept for decades may need different schedules. Document management and e-signature vendors should be asked whether their archive formats support adding a new protection layer without breaking the original signature.

How it works in practice: a regional bank sorts its signatures

Suppose a regional bank decides to start. Its security team does not begin by picking an algorithm. It begins by listing every place the bank signs something, or relies on someone else’s signature, and asking one question of each: how long must this signature stay trustworthy?

The first group is large and familiar. The bank’s website and mobile app use TLS certificates. Staff log in to dozens of internal applications through single sign-on. Branch systems call central services with API tokens. All of these are checked in the moment. The team confirms that certificate renewal is automated, finds two older internal applications where renewal is still manual, and fixes those. It also discovers that one payments gateway has the signature algorithm written into its code; a change request goes to the vendor.

The second group is smaller and more consequential. The bank runs its own internal certificate authority, with a root created years ago. Its ATMs and branch card readers accept software updates signed with a key held in the bank’s HSMs. The team learns that the HSMs’ current support contract says nothing about adding new algorithms, and that one model of card reader trusts a single fixed key. Both go onto the procurement agenda for the next refresh, with clear requirements.

The third group surprises the executive committee. The bank holds electronically signed loan agreements, account-opening forms and board resolutions that must remain valid evidence for many years. Nobody has a plan for re-protecting them. Legal, records management and security agree to draft a schedule, starting with the record sets kept longest.

At the end, the bank has not made a single irreversible choice. It has a register, a short list of fixes and a set of procurement requirements, which is exactly what makes a second change affordable.

Decisions made this year set the cost

Post-quantum cryptography is a problem for this year’s decisions and for the whole bank, for three reasons.

First, the costs are set by decisions made now. HSM contracts, device purchases, PKI designs and archive formats chosen this year will determine whether a future algorithm change is a configuration update or a hardware replacement program. Those are capital decisions, and they belong in procurement criteria today.

Second, regulators and government buyers have begun to put dates on the work. The executive order’s 2031 target for agencies’ high value assets and high impact systems, and NSA’s 2030 date for exclusive use in national security software and firmware signing, will shape what vendors build and what government customers require of their suppliers.

Third, the evidential value of signed records is a legal and reputational asset. A bank, insurer or hospital that cannot, years from now, show that its signed documents are authentic has a problem that no algorithm choice can fix after the fact.

The register that makes a second change routine

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.

The other controls are algorithms held in configuration rather than code, automated certificate issuance and renewal, a parallel post-quantum hierarchy for internal PKI, HSM and device contracts that require algorithm updates, and a re-protection schedule for archives agreed among records, legal and security teams.

The failures are easy to recognize. One is waiting for NIST to finish before doing anything, which leaves no time for long-lived hardware to cycle. Another is the opposite: picking one algorithm, hard-wiring it everywhere and declaring victory, which makes the second change as painful as the first. A third is focusing only on websites and forgetting firmware, code signing and archives, where the long lifetimes are. A fourth is buying devices and HSMs on price alone, without asking whether they can ever learn a new algorithm.

Where a second change would hurt

1. Do we have a register of every signing key and trust anchor we operate or rely on, with algorithm, lifetime, holder, verifying systems and replacement cost?
2. Are signature algorithms set in configuration, or written into application code?
3. Can our HSMs add new algorithms through firmware updates, and is that in the contract?
4. Which of our devices verify firmware against a single fixed key, and how many of them are there?
5. For signed records we must keep for years, do we have a schedule for adding fresh protection, and do our vendors’ archive formats support it?

With hindsight

The pattern has since become 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. The choice of signature schemes will keep shifting well into the second half of the decade.

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. The applications suggest that public website certificates may move along their own path, shaped by browser makers, rather than simply adopting the same algorithms organizations use internally.

Meanwhile, key establishment kept spreading, with little fanfare, through browser, operating system and library updates. An organization can gain quantum-resistant key exchange on some connections without a project of its own, simply by keeping software current. Signatures are unlikely to be so effortless, because they live in certificates, hardware and archives that do not update themselves.

The divergence does not make ML-DSA or SLH-DSA 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. There may be several migrations, running on different clocks, rather than one.

That also changes how progress should be reported. A single percentage complete for “post-quantum readiness” hides more than it reveals. A board is better served by a short view of each tier: what has been inventoried, what has been made agile, and which long-lived purchases are coming up for renewal.

Organizations that separated those tiers, and kept their signing key register current, can follow each track at its own pace. Those that treated post-quantum signatures as one decision to be made once will find themselves making it again, and possibly again after that, without the inventory or the design choices that would make it routine.