Lower quantum estimates moved signatures up the post-quantum queue
Spring 2026 research cut estimates of what it would take to break elliptic-curve cryptography. For agencies, that mattered less for encryption than for authentication, where certificates, smart cards and firmware keys take longest to replace.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
No single event defines this week. By this point in 2026, the post-quantum timeline had shortened on paper. On March 30, Google’s quantum research team published an estimate that breaking 256-bit elliptic-curve cryptography would need far fewer qubits than earlier work suggested, releasing a zero-knowledge proof rather than the algorithm itself. The startup Oratomic published a separate resource estimate for neutral-atom machines the same day. On April 7, Cloudflare moved its target for full post-quantum security, including authentication, to 2029, citing that research and Google’s move to a 2029 migration target of its own. The standards were already in place. NIST published FIPS 203 (ML-KEM) for key establishment and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures in August 2024. NSA’s CNSA 2.0 guidance expects new national security system acquisitions to be compliant from January 1, 2027.
For most of the post-quantum transition, the order of work was settled. Encrypted traffic captured today could be decrypted once a capable quantum computer exists, so key establishment came first. Signatures could wait, because a forged signature is only useful when it is used, and that requires the machine to exist. Vendors followed that order. Browsers, operating systems and large cloud providers shipped hybrid key exchange using ML-KEM, and much web traffic gained post-quantum protection through routine updates.
The spring estimates did not change that logic. They changed the arithmetic. If a cryptographically relevant quantum computer could arrive closer to 2030 than 2035, signature systems stop being a later phase. Their migration takes longest, and parts of it can only happen through hardware replacement. Cloudflare said as much when it put authentication inside its 2029 target.
For agencies, the signature estate splits three ways by who controls the fix: certificates the agency issues, keys locked in hardware, and signatures vendors apply to what the agency installs.
Certificates the agency issues
Agencies run, or rely on, public key infrastructure for internal TLS, device and server certificates, document signing and identity federation. Most of it uses RSA or elliptic-curve keys. In principle the agency can reissue all of it. In practice certificate estates are large and poorly inventoried, and the roots that anchor them often have lifetimes measured in decades.
The work runs in three steps. First, find where signature algorithms are configured, including identity providers, VPN gateways, load balancers and application code that validates tokens. Second, shorten certificate lifetimes and automate issuance, because an estate that can rotate certificates automatically can change algorithms the same way. Third, plan the root. Standing up a post-quantum or hybrid root of trust, and getting every relying system to accept it, is a multi-year exercise. It should begin before products are fully ready, because distributing trust is the slow part.
Many agency certificates chain to shared federal roots, so individual agencies depend on government-wide decisions about post-quantum certificate profiles. An agency CISO should know which trust chains the agency controls and which it inherits, and should raise the inherited ones with the program office that runs them.
Keys locked in hardware
Some signature keys live in hardware that cannot be patched to a new algorithm. Personal Identity Verification cards carry keys generated on the card. Hardware security modules protect signing keys for identity, payment and code-signing systems. Network appliances, building controls, radios and laboratory equipment often verify firmware against a key fixed at manufacture.
For these, migration means replacement, and replacement follows refresh cycles. Smart cards are reissued on multi-year cycles, and readers, middleware and relying applications must accept new algorithms before a new card is useful. Hardware security modules need firmware that supports ML-DSA or SLH-DSA, and sometimes a new model. Devices with fixed roots of trust need to be replaced or isolated.
A useful first pass is a short register of hardware types that hold fixed signature keys, with counts, installation dates and planned replacement years. It turns an abstract risk into a replacement schedule that budget staff can price, and it shows which refresh cycles already end before 2030 and which would need to be pulled forward.
That puts the deadline in procurement. Equipment bought in 2026 with a ten-year life will be in service into the mid-2030s. Requirements for hardware bought now should include support for NIST’s post-quantum signature standards or a documented upgrade path, and should say who pays if a firmware root cannot be changed. The CNSA 2.0 milestone for new national security system acquisitions applies this logic to one part of government. Civilian agencies can adopt it voluntarily, and the cost is lowest at the point of purchase.
Signatures vendors apply
The third group is signatures the agency does not control at all. Software updates, drivers, container images and firmware packages are signed by their publishers. Cloud and software-as-a-service providers sign the tokens that federated sign-in depends on. An adversary able to forge those signatures could deliver malicious updates that look legitimate, a supply chain attack that needs no compromised build system.
Agencies cannot fix this internally, but they can ask. Procurement and vendor risk teams should ask critical suppliers three things. When will their code-signing and update channels move to post-quantum signatures? Will they support hybrid signing during the transition? And how will they retire quantum-vulnerable algorithms, not only add new ones? Cloudflare stressed the last point. A system that accepts both old and new signatures remains open to downgrade until the old ones are switched off.
Many answers will be roadmaps rather than dates. Recording them still matters. It shows which suppliers sit on the critical path, and it gives contracting officers a basis for requirements at renewal.
None of this reverses the earlier priority. Key establishment still protects data with long confidentiality lives, and agencies that have not enabled hybrid key exchange should still do so. The change is that signature work can no longer wait its turn. Its longest elements are hardware cycles and trust distribution, and both have to start years before the risk is concrete.
With hindsight
Federal policy moved within two months. On June 22, 2026, the President signed Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks. It set December 31, 2030 for agencies’ high value assets and high impact systems to adopt post-quantum key establishment, and December 31, 2031 for post-quantum digital signatures. It asked each agency to name a migration lead and called for OMB guidance on migration plans. National security systems stayed on NSA’s separate schedule.
The order kept key establishment first, but only by a year, so signatures could no longer be scheduled as a distant second phase. The research figures remain estimates, and no machine capable of the attack has been demonstrated. We would not anchor planning to any single forecast. The hardware refresh cycles that govern signature migration are known, though, and they are long enough to make 2026 purchases matter.