PQC Is Not About the Quantum Computer

Brian Couzens

1 day ago

12 min read

The front cover of the carousel with the same title as the blog in red

Post-quantum cryptography (PQC) is not about the quantum computer. Assume the machine is never built and nine pieces of PQC work remain: eight driven by a published date, a regulator, a browser rule, a supplier or an audit finding, and a ninth, ownership, that follows from them. This article sets them out, explains the one item that does depend on the machine, and gives a remediation path a board can test without waiting for one.

The experiment

Before the next post-quantum cryptography budget meeting, run one experiment. Assume that a cryptographically relevant quantum computer, a machine able to break the public-key cryptography in use today, is never built. Not in 2030, not in 2040, not at all.

Then go through the programme plan and strike out every task that depended on the machine arriving.

Very little goes. The final step, swapping today's public-key algorithms for post-quantum ones, is driven by the machine. Nearly everything that makes that step possible is not: knowing what cryptography the organisation runs, who owns it, which suppliers control it, what it will cost to change and how quickly it can be changed. Several of those are already demanded by a standards body, a regulator, a browser rule or an auditor, on dates that are already published, and the rest follow from them.

The quantum computer is the reason post-quantum cryptography exists. It is not the work, and it is not the deadline. The sections below set out nine items that survive the experiment, the one item that does not, and what to do about all ten.

1. Your algorithms already have retirement dates

In November 2024 the US National Institute of Standards and Technology (NIST), the federal standards agency, published the initial public draft of Internal Report 8547, Transition to Post-Quantum Cryptography Standards. It sets a schedule for the public-key algorithms in use today. Schemes at 112 bits of security strength are deprecated after 2030. For RSA, 112 bits corresponds to a 2048-bit modulus, according to NIST's own guidance on algorithm transitions. RSA, ECDSA, EdDSA, and finite field and elliptic curve Diffie-Hellman are disallowed after 2035 at every security strength.

Two qualifications matter. The report is still a draft, and NIST has said the detailed schedules will be written into its transition guidance, SP 800-131A. And the report states where 2035 comes from: National Security Memorandum 10 sets it as the primary target for completing the federal migration. The date was set by policy, in response to the quantum threat. It is not tied to any laboratory milestone. If the machine were somehow known never to arrive, the date would in time be revisited. That cannot be known, so the date stands, and an organisation that waits for a laboratory milestone before planning against it has misread what kind of date it is.

The national timetables that sit alongside it are mapped in The State of Post-Quantum Cryptography in 2026.

2. The target dates are already published

On 20 March 2025 the UK National Cyber Security Centre (NCSC) published Timelines for migration to post-quantum cryptography. Aimed primarily at large organisations and critical national infrastructure, it sets three milestones that it says all organisations should work towards. By 2028: define migration goals, carry out a full discovery exercise and build an initial plan. By 2031: carry out the early, highest-priority migration activities and refine the plan into a full roadmap. By 2035: complete migration of all systems, services and products. How the UK measures up against its own guidance is assessed in UK Post-Quantum Cryptography Readiness: What the Evidence Actually Shows.

On 23 June 2025 the European Commission announced a coordinated implementation roadmap, written by EU Member States through the NIS Cooperation Group. All Member States should start transitioning by the end of 2026. Critical infrastructure should transition as soon as possible, and no later than the end of 2030. The roadmap itself sets the end of 2030 as the point by which the transition for high-risk use cases should be complete.

These are targets and recommendations, not statutes. Their force arrives through supervisors, public procurement and the supply chain. None of them waits for a lab result, and the first milestone on each is a discovery or planning milestone, which is work no quantum computer is needed to start.

3. Certificates are getting shorter anyway

On 11 April 2025 voting closed on CA/Browser Forum Ballot SC-081v3. The CA/Browser Forum is the body through which browser makers and public certificate authorities set the rules for the certificates that secure websites. Under the Baseline Requirements that resulted, the maximum validity of a public web certificate is 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029.

A certificate renewed once a year by hand until March 2026, and roughly twice a year now, will need renewing around eight times a year once the 47-day limit applies. An organisation that does not know where its certificates are, who owns each one and how it is replaced will meet that limit as a series of outages.

The capability this rule demands is the same one a post-quantum migration demands: a complete record of where cryptography sits, and a way to replace it without a project. That capability is what cryptographic agility means in practice. The browser makers set this rule for their own reasons. It applies whether or not a quantum computer is built.

4. The last algorithm retirement is still not finished

The SHA-1 hash algorithm entered US federal standards in 1995. In March 2006 NIST's policy on hash functions told federal agencies to stop using SHA-1 for digital signatures and digital time stamping as soon as practical. On 15 December 2022 NIST announced that SHA-1 should be phased out by 31 December 2030. Its hash function policy, updated the same day, adds that after that date any validated cryptographic module still listing SHA-1 as an approved algorithm will be moved to the historical list.

That is 24 years from NIST's first instruction to stop to the final removal date. The main use, digital signatures, was cut off within a decade. The residual uses have taken the rest. SHA-1 was retired because of classical attacks on it, and no quantum computer was involved.

The lesson is about the estate, not the algorithm. An algorithm lives on in protocols, embedded products, supplier code and old integrations long after the instruction to stop. A post-quantum migration retires RSA and elliptic curve cryptography, which sit far deeper in the estate than SHA-1 did. The sequence of errors that turns such a retirement into a decade-long overrun is set out in The PQC Baker's Dozen.

5. Certificates inside supplier software already stop businesses

On 6 December 2018, O2's mobile data service in the United Kingdom went down. Ericsson's statement that day gave its initial root cause: "an expired certificate in the software versions installed with these customers", in two versions of its SGSN-MME core network software. Computing reported the outage as affecting around 32 million people. ITPro reported that 4G service was not fully restored until after 03:00 the following morning.

The certificate sat inside a supplier's software, running in the operator's core network. It is a clean example of cryptography that an organisation depends on, that carries operational consequence, and that sits outside the line of sight of the people accountable for the organisation's risk. The condition is examined in full in Shadow Cryptography: The Estate Nobody Signed For.

No quantum computer was involved. The failure was a lifecycle failure, and the same supplier dependency will govern how fast a post-quantum migration can move. Contract terms are where that dependency is controlled, as set out in Stop Buying Cryptographic Debt.

6. Regulators already ask for the register

The European Union's Digital Operational Resilience Act (DORA) applies to banks, insurers, investment firms and other financial entities. Its technical standard on ICT risk management, Commission Delegated Regulation (EU) 2024/1774, sets out what it expects of cryptography.

Article 6 requires a policy on encryption and cryptographic controls, including provision for updating or changing, where necessary, cryptographic technology on the basis of developments in cryptanalysis.
Article 7(4) requires a register of all certificates and certificate-storing devices, kept up to date, covering at least the ICT assets that support critical or important functions.
Article 7(5) requires certificates to be renewed before they expire.

The threat from quantum advancements is mentioned in the recitals. The obligations themselves sit in the articles and apply now. A financial entity under DORA's full ICT risk framework that cannot produce the register is not meeting Article 7(4) today, whether or not a quantum computer is ever built.

7. One in 24 had the inventory

In October 2026 the US Government Accountability Office (GAO) published GAO-27-108740, the public version of a report it issued in September 2025. It evaluated the 24 agencies covered by the Chief Financial Officer Act against three preparatory practices drawn from the Office of Management and Budget's memorandum M-23-02 of November 2022. The agencies also operated under a statute, the Quantum Computing Cybersecurity Preparedness Act, and alongside NIST in the same government.

One of the 24 had a complete inventory of its priority systems using vulnerable cryptography. GAO found that 18 agencies reported a lack of expertise in cryptography and in building the inventories, and had no plans to fill the gap. Twenty-three had no documented process for maintaining the inventory. Nineteen used no automated tools to identify and verify inventory data.

Two limits apply. The audit ran from February 2024 to September 2025, so part of it predates NIST's final post-quantum standards of August 2024, and the public version does not name the agency behind each finding. Neither limit changes the point. An inventory does not need a quantum computer, a final standard or a supplier product to begin, and 23 of 24 agencies, with the OMB instruction and the statute in place, had not completed one. The full audit is analysed in None of 24: The GAO Audit of Federal PQC Readiness, and the difference between discovery and the record it produces is set out in Discovery Is Table Stakes for PQC. A CBOM Is Not Discovery.

8. None of 24 had fully priced it

The same audit found that no agency had fully identified the funding its migration needs. Twenty-one produced funding assessments and three did not. Only one assessment rested on a complete inventory of priority systems, and each of the 21 agencies acknowledged that its figures were not fully accurate.

Replacing cryptography runs across several budget cycles, through suppliers' release schedules and hardware refresh dates. A budget built on an incomplete inventory is a guess, and a programme funded on a guess will be re-baselined when the inventory catches up. Pricing the work needs the inventory, the supplier positions and an owner. It does not need a quantum computer.

9. Somebody has to own it

Algorithms, keys and certificates sit across systems, supplier contracts and products that no single technical function controls. The decisions that follow are structural: which data must stay confidential for longest, which supplier is held to which date, which systems are replaced rather than upgraded, how much capital is committed across which budget cycles, and which residual risk is accepted on the board's behalf.

Those decisions need authority over risk appetite, capital and third parties. In SITG-Consulting's view that authority, and the accountable ownership of the programme, belongs with the Chief Risk Officer. Security and technology leaders are essential delivery partners. Where no single executive is named as accountable, there is no programme, only activity. The wider pattern is described in PQC Is Exposing the Cryptographic Governance and Control Gap.

The one item that does need the machine

One item fails the experiment, and it should be stated plainly. GAO describes the threat in its report: an actor with a cryptographically relevant quantum computer could "decrypt (or unlock and view) data that the actor acquires and stores prior to the development of such a computer". This is harvest now, decrypt later. Encrypted traffic is recorded today and held until it can be read.

If the machine is never built, recorded traffic stays unreadable and this item carries no risk. If it is built, the exposure applies to data whose confidentiality depends on today's public-key key exchange. GAO notes that symmetric cryptography is not currently projected to be vulnerable to such a machine. The test for which data is exposed is Mosca's theorem: if the period for which data must stay confidential, plus the time the migration will take, exceeds the time until such a machine exists, data crossing a network today is already at risk. How credible the published timelines for that machine are is examined in Beyond Q-Day Hype.

This is the item that sets the urgency. It does not change the work. The nine items above are what an organisation must have in place before it can act on that urgency at all.

What PQC is about

Strip the machine out and one question is left: can the organisation change its cryptography when it is told to?

The instruction can come from NIST, a national cyber security agency, a financial supervisor, the CA/Browser Forum, a supplier's end-of-life notice or a cryptanalysis result. The quantum computer is one source of such instructions among several. It is the largest, because it retires the public-key algorithms that sit under almost every secure connection, but the capability it tests is the same one the other sources test every year.

That capability has four parts.

Know what you run: algorithms, keys, certificates, libraries and protocols, with their owners and the data they protect.
Name who owns it: one accountable executive, and named owners beneath.
Bind your suppliers to dates: disclosure, a replacement path and a date for each product with embedded cryptography.
Fund it across budget cycles: from the inventory, not from an estimate.

Deploying post-quantum algorithms without those four in place produces a migration that cannot be evidenced, as set out in Deploying PQC Is Not the Same as Proving It Works.

Remediation, part one: build the capability

Remediation has two parts. The first builds the capability. The second proves it works, without waiting for a quantum computer to test it.

Build the inventory from more than one method: network observation, code and binary analysis, configuration review, certificate and key management systems, and supplier disclosure. Record for each item the algorithm, key length, certificate expiry, owner, supplier and the data it protects, with that data's confidentiality period.
Name the accountable executive and the owners beneath, in writing, with authority over the budget and the supplier decisions.
Map the obligations by market: the NIST schedule, NCSC milestones, the EU roadmap, DORA's register and renewal requirements, and the CA/Browser Forum validity limits. Each becomes a dated requirement against the inventory.
Bind suppliers by contract: disclosure of algorithms and key lengths, a replacement path, notification of changes and a date for post-quantum support. Start with the products that cannot be changed without replacing them.
Automate certificate issuance and renewal for public certificates before the 100-day limit takes effect in March 2027.
Price the migration from the inventory and the supplier positions, across the budget cycles it will actually take, and record what is still unknown.

An independent baseline of where the organisation stands is the purpose of a PQC Readiness Assessment. Starting from a vendor product instead of this capability is the error described in Why PQC Vendors Are Not the Starting Point for Your Post-Quantum Transition.

Remediation, part two: prove it without a quantum computer

Every part of the capability can be tested now, with measurable results.

Certificate drill: choose a critical service and replace its certificates and keys out of cycle. Measure the time from decision to completion, and record every system that broke.
Algorithm drill: in a non-production environment, change one algorithm or key length by configuration. Record whether it needed a code change or a supplier release.
Supplier drill: write to the ten suppliers whose products carry the largest share of embedded cryptography in the estate and ask for their algorithm inventory and post-quantum date. Record who answers, how fully and how fast.
Register reconciliation: compare the inventory with what network observation finds. Every difference is a finding, and the size of the gap is a measure of the record's reliability.
Board reporting: report time to change, inventory coverage, supplier responses and open exceptions to the risk committee each quarter.

The standard of evidence those results should meet is set out in What Evidence Actually Proves a PQC Migration Is Good.

Questions for the board

One question tests the programme: if the quantum computer were cancelled tomorrow, would the programme stop? If the answer is yes, it was never a programme. It was a reaction to a headline.

Six more test whether the capability exists.

Who is the one executive accountable for our cryptography, and where is that written down?
What share of our cryptographic estate is in the inventory, and how do we know?
How many of our public certificates are renewed automatically, and are we ready for the 100-day limit in March 2027?
Which of our suppliers have told us, in writing, when their products will support post-quantum cryptography?
How long would it take us to replace a compromised algorithm on a critical service, and when did we last test it?
Is our migration budget built on a complete inventory, and if not, what is missing?

The position

The quantum computer is why the post-quantum dates exist. It explains the urgency of one risk, harvest now, decrypt later, and it is the reason the public-key algorithms will be retired. Everything else on the programme plan is driven by dates already published, rules already in force and failures that have already happened.

An organisation that treats post-quantum cryptography as a bet on when a machine arrives will spend its time arguing about timelines. An organisation that treats it as the capability to change cryptography on instruction will find that the capability pays for itself against the certificate rules, the regulators and its own suppliers well before any machine is built. That capability is a governance matter, it needs an accountable owner, and it can be tested this quarter.

About the authors

Brian Couzens is CEO of SITG-Consulting and Katima Meewaew is the CAO which is an independent advisory firm working on post-quantum cryptography transformation, cryptographic governance and quantum risk management. The PQC Discovery Sprint is SITG-Consulting's structured engagement for establishing what cryptography an organisation runs and who owns it.

SITG-CONSULTING