Lower quantum estimates moved signatures up the post-quantum queue

The week

On March 31, 2026, Google’s quantum research team published an estimate that breaking 256-bit elliptic-curve cryptography would need far fewer qubits than earlier work suggested. No single event defines this week, but by this point in 2026 the post-quantum timeline had shortened on paper.

Almost everything secure online rests on a few mathematical puzzles that ordinary computers cannot solve in any useful amount of time. Those puzzles protect the padlock in a web browser, the login to a government system and the check that a software update really came from its maker. For years, experts have warned that a sufficiently powerful quantum computer, a machine that computes using the physics of tiny particles, could solve some of those puzzles. The open issue has always been when.

Elliptic-curve cryptography is one of the most widely used families of those mathematical locks. A qubit is the basic unit of a quantum computer; the fewer needed for an attack, the sooner a machine might manage it. Google released a zero-knowledge proof rather than the algorithm itself: a way of demonstrating that it had the method without publishing the method, so attackers could not copy it.

At about the same time, the startup Oratomic published a separate resource estimate for neutral-atom machines, a different way of building quantum computers. On April 7, Cloudflare, which carries a large share of the world’s web traffic, moved its target for full post-quantum security, including authentication, to 2029. It cited that research and Google’s move to a 2029 migration target of its own.

The standards for the replacement locks were already in place. NIST, the federal agency that sets technical standards, 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, which covers national security systems, expects new acquisitions for those systems to be compliant from January 1, 2027.

So the new locks existed, the estimated arrival of the lock-picker had moved closer, and a major internet company had pulled its own deadline forward. Agency heads had to decide what to do first.

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 useful only when it is used, and that requires the machine to exist.

The spring estimates did not change that logic. They changed the arithmetic. The reason lies in what these two jobs, secrecy and proof, actually are.

Secrecy and proof

Cryptography is the science of protecting information with mathematics. In government systems it does two different jobs, and the post-quantum story treats them differently.

The first job is secrecy. When a laptop connects to an agency website, the two machines need to agree on a secret key to scramble the conversation, without anyone listening being able to work it out. That agreement is called key establishment. The new standard for it is ML-KEM.

The second job is proof. A digital signature proves who created something and that it has not been altered. It is how a laptop knows the website really belongs to the agency, how a device knows a software update really came from the manufacturer, and how a system knows a login token was really issued by the agency’s sign-in service. The new standards for signatures are ML-DSA and SLH-DSA. A signature works like a wax seal: anyone can check it, but only the holder of the seal can make it.

Today, both jobs mostly rely on two older families of mathematics, RSA and elliptic curves. A large enough quantum computer could break both, which is why the replacement standards exist.

Secrecy came first because of a threat often called “harvest now, decrypt later.” An adversary can record encrypted traffic today and store it, waiting for the day a quantum computer can unlock it. Anything that must stay secret for many years, such as personnel records, investigations or diplomatic material, is already at risk in that sense. Signatures are different. A forged seal is dangerous only at the moment someone uses it, and nobody can forge one until the machine exists.

What a quantum computer can and cannot do

A common misunderstanding needs clearing up. A quantum computer is a different kind of machine from a faster laptop. It works on different principles, and it is very good at a narrow set of problems while offering little advantage for most everyday computing. Unfortunately for security teams, the puzzles behind RSA and elliptic-curve cryptography are among the problems it is expected to be good at.

Today’s quantum machines are small and error-prone. Breaking real cryptography would need a much larger, more reliable machine, which is why researchers publish resource estimates: calculations of how many qubits, how much time and how much error correction an attack would require. Falling estimates mean that researchers have found cleverer ways to do the job with less, which moves the finish line closer to where the engineering already is; they do not mean a machine has been built.

The spring 2026 research did exactly that. Google’s estimate concerned the qubits needed against 256-bit elliptic-curve cryptography; Oratomic’s concerned neutral-atom machines. Neither demonstrated an attack. Both narrowed the distance between today’s hardware and a machine that matters.

The new standards, by contrast, rest on different mathematical puzzles that neither ordinary nor quantum computers are known to solve efficiently. Replacing the old locks with these new ones is the whole of the post-quantum transition. The hard part is not inventing the locks. It is finding and changing every door.

Why the new estimates change the schedule

Vendors followed the settled order. Browsers, operating systems and large cloud providers shipped hybrid key exchange using ML-KEM, which combines an old method and a new one so that the connection stays safe as long as either holds. Much web traffic gained post-quantum protection through routine updates. Most agencies received that protection without a project, simply by keeping software current.

The spring estimates changed the arithmetic for the second job. If a cryptographically relevant quantum computer, meaning one powerful enough to break the locks in practice, 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.

The reasoning is about lead time rather than certainty. Nobody needs to believe a particular forecast. It is enough to notice that some signature systems take most of a decade to replace, and that the estimated window has narrowed. A program that takes eight years must start eight years before it is needed, whatever the odds.

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

A certificate is a digital identity card for a server, device or person. It contains a public key and is signed by a trusted issuer, so others can check it. The system of issuers, certificates and trust rules is called public key infrastructure, or PKI. At its top sits a root of trust: the issuer that every system has been told to believe.

Agencies run, or rely on, public key infrastructure for internal TLS (the protocol behind the browser padlock), device and server certificates, document signing and identity federation, which lets one organization’s sign-in be trusted by another’s systems. 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:

1. Find where signature algorithms are configured. That includes identity providers, VPN gateways, load balancers and application code that validates tokens. A VPN gateway is the entry point for remote staff; a load balancer spreads traffic across servers; tokens are the digital passes users carry after signing in.
2. Shorten certificate lifetimes and automate issuance. An estate that can rotate certificates automatically can change algorithms the same way. An agency that replaces certificates by hand every few years will find an algorithm change slow and error-prone.
3. 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, the smart cards federal employees use to badge in and sign in, carry keys generated on the card. Hardware security modules, tamper-resistant boxes that guard an organization’s most valuable keys, 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. Firmware is the low-level software built into a device; checking its signature at start-up is how the device knows it has not been tampered with.

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 sensible 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. The attacker would not need to break into the vendor at all; a forged seal would be enough.

Agencies cannot fix this internally, but they can ask. Procurement and vendor risk teams should ask critical suppliers three things:

• When their code-signing and update channels will move to post-quantum signatures.
• Whether they will support hybrid signing during the transition.
• How they will retire quantum-vulnerable algorithms, as well as 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. A downgrade attack tricks a system into using the weaker of two options.

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.

One agency’s signature map

Take a civilian agency with around ten thousand staff whose CISO asks for a signature inventory, separate from its encryption work.

The certificate review finds several internal issuers, some set up by former staff, and thousands of server certificates renewed by hand. Several applications check sign-in tokens with code nobody has touched in years. The agency’s main trust chain is inherited from a shared federal root, so its root decisions belong to someone else.

The hardware register lists staff smart cards and readers, two generations of hardware security modules, building access controllers and specialized laboratory instruments that verify firmware against keys fixed at the factory. The laboratory instruments are newly purchased, with a long expected life, and their vendor has no stated upgrade path.

The vendor review sends the three questions above to the agency’s top suppliers. Some reply with dates, most with roadmaps, a few not at all.

The result is a plan anyone can read. Automate certificate issuance this year. Raise inherited roots with the program office. Add post-quantum signature requirements to the next hardware security module purchase and every device solicitation. Isolate the laboratory instruments on their own network segment and flag them for early replacement. Make vendor answers a standing item at contract renewals. Every step is useful before a quantum computer exists, and each shortens the time the agency would need if one did.

Signature work can no longer wait its turn

For an agency head, the stakes are trust in the agency’s own systems. If signatures fail, an agency cannot be sure who is signing in, whether a website is real, or whether a software update is genuine. The risk runs to mission, to the public’s data and to the agency’s credibility.

The earlier priority still stands. 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.

The costs deserve naming too. Replacing smart cards, readers, hardware security modules and long-lived devices on an accelerated schedule is expensive. Replacing them on their normal schedule, with the right requirements in each purchase, costs little extra. The difference between those two paths is mostly a matter of when an agency starts asking.

A well-run program looks unremarkable from the outside: a signature inventory that someone keeps current, automated certificate management, a hardware register tied to the budget cycle, purchasing language that asks the right question every time, and a short list of vendor answers reviewed at each renewal. It produces no dramatic milestones, which is exactly why it needs an executive sponsor to keep it funded.

The errors are understandable. One is treating “post-quantum” as a single project and measuring it only by encryption progress. Another is assuming vendor updates will handle everything, when hardware keys and trust roots cannot be updated that way. A third is buying long-lived equipment in 2026 without asking about signature support. A fourth is adding new algorithms and forgetting to switch off the old ones.

Where the signature exposure lies

• Do we have an inventory of where we use digital signatures, separate from where we use encryption, how many of our certificates are renewed automatically, and which trust chains do we inherit from shared federal roots?
• Which hardware holds signature keys that cannot be updated, and when is each type due for replacement?
• Do our current solicitations require support for NIST’s post-quantum signature standards or a documented upgrade path?
• Have we asked our critical vendors when their code signing and update channels will move, and how they will retire old algorithms?
• Who in our agency owns this work end to end, and does that person have the authority to change purchasing requirements and budget timing?

One more test is worth running: if the estimates moved closer again next year, which parts of the plan could be sped up, and which are fixed by hardware cycles that cannot be shortened? The answer shows where the plan’s real deadline lies.

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. High value assets and high impact systems are, broadly, the systems whose compromise would most damage an agency’s mission or the public.

The order asked each agency to name a migration lead and called for OMB guidance on migration plans. OMB, the Office of Management and Budget, sets management rules and budget expectations for federal agencies, so its guidance is where deadlines turn into plans and money. National security systems stayed on NSA’s separate schedule. The order also confirmed, in effect, that this is now a leadership responsibility with a named owner in every agency rather than a technical side project.

The order kept key establishment first, but only by a year, so signatures could no longer be scheduled as a distant second phase. Read against the hardware refresh cycles described above, a 2031 signature deadline is close. Equipment bought in 2026 will still be in service then, which means the purchasing decisions of 2026 are, in practice, part of the compliance plan.

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.

The sensible posture sits between alarm and complacency. A quantum computer that can break today’s locks may come sooner or later than the estimates suggest. The work that would protect an agency, from inventories and automation to purchasing rules and vendor questions, is worthwhile under any of those futures, and the parts that take longest are the ones that must start first.