Q-Day Planning Guide: Preparing for Cryptographically Relevant Quantum Computers

Nobody can say when a cryptographically relevant quantum computer will exist, but data encrypted today can be recorded now and decrypted then, so planning cannot wait for a date. "Q-Day" is the informal name for the point at which a quantum computer can break the public-key algorithms (RSA, elliptic curve and finite field Diffie-Hellman, ECDSA, EdDSA) that protect most key exchange and signatures. Governments have responded with migration deadlines rather than predictions: the UK NCSC sets 2028, 2031 and 2035 milestones, the EU roadmap targets 2030 for high-risk uses and 2035 for everything, and NIST's draft transition plan disallows quantum-vulnerable algorithms after 2035. This guide is for security leaders, risk owners and architects who need to turn that into a funded, sequenced plan. Technical migration steps are covered separately in the Post-Quantum Cryptography Migration Guide.

Key takeaways

• Plan to the deadlines, not to a guess: official sources give migration dates, not a Q-Day date, and the NCSC states its 2035 target is driven by how long migration takes.
• Confidentiality is exposed today: harvest-now-decrypt-later means data with a long secrecy life is already at risk; signatures and authentication only need to hold at the moment of use.
• Estimates have moved closer: Google researchers estimated in May 2025 that RSA-2048 could in theory be factored with under a million noisy qubits in about a week, roughly twenty times fewer than their 2019 estimate.
• Long-lived hardware decides the timeline: roots of trust, firmware signing keys and devices with fixed cryptography take longest to replace and must be identified by 2028.
• Treat it as a programme with a board owner: inventory, supplier engagement, budget and exercises, with crypto-agility so the next change is cheaper.

What Q-Day means and what it does not

A cryptographically relevant quantum computer (CRQC) is one large and reliable enough to run Shor's algorithm against real key sizes. It would break the public-key algorithms used for key establishment and digital signatures. It does not break symmetric cryptography in the same way: the NIST IR 8547 draft maps AES-128, AES-192 and AES-256 to post-quantum security categories 1, 3 and 5 and says NIST does not expect to need to transition away from its symmetric standards, while SHA-256 and stronger hashes remain at full strength.

What the sources say about timing

Treat any single Q-Day year with caution. The primary sources read for this guide state deadlines and resource estimates, not an arrival date:

• NCSC (UK): its PQC migration timelines guidance (20 March 2025) refers to future large-scale, fault-tolerant quantum computers without giving a date, and bases 2035 on the time needed for standards, products and uptake.
• Google Quantum AI: Craig Gidney and Sophie Schmieg wrote on 23 May 2025 that a preprint estimates 2048-bit RSA could be broken by a quantum computer with one million noisy qubits running for one week, down from 20 million physical qubits in the 2019 estimate. That is a resource estimate, not a forecast of when such a machine will exist, and the authors urged migration on NIST's schedule.
• NIST: the IR 8547 draft does not predict Q-Day; it sets a deprecation and disallowance schedule and notes that application guidance may require earlier migration of key establishment because of harvest-now-decrypt-later.
• Expert surveys: the Global Risk Institute publishes an annual Quantum Threat Timeline Report by Michele Mosca and Marco Piani, combining the views of 32 experts in its 2024 edition. Quote its probabilities only from the report itself.

A practical way to frame urgency is Mosca's inequality: if the years your data must stay secret plus the years your migration takes exceed the years until a CRQC, you are already exposed. Because the third term is unknown, organisations use the regulatory deadlines as the planning horizon and the first two terms to set priorities.

Regulatory and government timelines

Sector regulators increasingly expect firms to show a plan. In financial services, the DORA Guide covers the ICT risk framework that a PQC programme sits within.

Prioritising what to protect first

Prioritise by two clocks: how long the data or trust must last (shelf life) and how long the asset takes to change (migration time).

The NCSC specifically asks organisations to identify long-lived hardware roots of trust by 2028. The MSI signing keys leak shows why: once firmware and Boot Guard keys were exposed, reporting noted they could not easily be revoked on devices already in use. A root of trust that cannot be changed is the same problem whether the key leaks or the algorithm breaks.

Building the Q-Day plan

The CISA, NSA and NIST factsheet Quantum-Readiness: Migration to Post-Quantum Cryptography recommends a quantum-readiness roadmap, a cryptographic inventory, supply chain assessment and engagement with technology vendors. The NCSC milestones give the order.

1. Appoint an owner and sponsor. Name an accountable executive and a programme lead; put quantum risk on the enterprise risk register with the 2028, 2031 and 2035 milestones (or your jurisdiction's equivalents).
2. Discover and assess (by 2028). Build the cryptographic inventory across code, infrastructure, network traffic, HSMs, cloud KMS, PKI and suppliers. See the Cryptographic Inventory and CBOM Guide.
3. Classify by shelf life and migration time. Tag data stores and flows with how long confidentiality must hold; tag assets with replacement cycles and whether cryptography is fixed.
4. Engage suppliers. Ask each critical supplier for its PQC roadmap, supported algorithms (ML-KEM, ML-DSA, SLH-DSA), hybrid TLS support and the cryptographic components in its products. Write requirements into contracts and renewals.
5. Fund it. Fold hardware refresh, HSM and PKI upgrades into existing lifecycle budgets rather than a separate one-off request. See the Security Budget and Investment Planning Guide.
6. Start with quick wins. Enable hybrid key exchange (X25519MLKEM768, registered in RFC 10024) on external TLS endpoints after a pilot ring; many libraries, including OpenSSL 3.5, already offer it by default.
7. Migrate the highest priority (by 2031). Long-secrecy data flows, roots of trust and PKI, in pilot, staged and production rings, with the previous configuration kept for rollback.
8. Build agility for the rest (to 2035). Each migration should leave the system able to change again. See the Crypto-Agility Guide.

Small and large organisations

• Small organisations and SaaS-first businesses: most change will arrive through cloud, browser and operating system updates. Focus on supplier questions, staying on supported versions, and a short list of in-house systems such as VPNs and custom applications.
• Large and regulated organisations: need a formal programme with inventory tooling, a crypto policy authority, a PKI roadmap and board reporting against milestones.
• Operators of long-lived assets (OT, telecoms, payments, defence): the procurement decisions made now determine whether devices can be migrated before 2035.

Algorithm decisions the plan should record

A Q-Day plan does not need to settle every engineering detail, but it should record the organisation's default choices so projects do not decide independently:

• Key establishment: ML-KEM (FIPS 203, parameter sets ML-KEM-512, ML-KEM-768 and ML-KEM-1024), deployed as a hybrid with X25519 or an approved elliptic curve during the transition. Record which parameter set is the default and where the stronger set is required.
• Signatures: ML-DSA (FIPS 204) as the general-purpose choice and SLH-DSA (FIPS 205), a stateless hash-based scheme, where conservative assumptions matter more than size and speed, such as long-lived roots of trust.
• Hybrid or pure: the NIST IR 8547 draft treats hybrids as typically temporary because they add cost and complexity and imply a later move to post-quantum only. Record when the organisation expects to drop the classical component.
• Backup algorithms: note HQC as the planned code-based backup KEM so that systems are designed to accept a second family if a lattice weakness emerges.
• Size and performance budgets: post-quantum keys and signatures are much larger than their classical equivalents, which affects constrained devices, certificate chains and protocols with fixed field sizes. Test early on the slowest and smallest devices you run.

Exercising Q-Day scenarios

A tabletop exercise turns an abstract risk into decisions. Useful scenarios include:

• Credible CRQC announcement: a government or researcher announces a working CRQC earlier than expected. Which systems must change first, who decides, and what can be switched by configuration in days?
• Algorithm break: a weakness is published in a deployed post-quantum algorithm (the reason NIST selected HQC as a backup KEM). Can you switch?
• Harvested data disclosure: data stolen years ago is shown to be decryptable. Which records, which notification duties?
• Root of trust forgery: firmware or code signing can be forged. How do you revoke, re-sign and redistribute?

See the Tabletop Exercise Guide and the Business Continuity and Disaster Recovery Guide for running and recording the exercise.

Where identity fits

Most signatures that a CRQC would forge belong to non-human identities: workload certificates, identity provider token signing keys, SSH host and user keys, code signing keys and device identities. Forged signatures would let an attacker impersonate services rather than read data. The Storm-0558 key breach shows the impact of a single forged-token capability today; Q-Day would make every quantum-vulnerable signing key a candidate. See the Post-Quantum Migration for NHIs Guide and the Post-Quantum Readiness Guide.

Measuring progress

Report progress against milestones with measures that a board can follow:

For monitoring, log negotiated TLS groups at load balancers and proxies, track certificate key types in PKI and certificate management tooling, and alert on new deployments of quantum-vulnerable-only configurations after your cut-off date.

Framework mapping

Common failure patterns

• Waiting for a date: treating Q-Day as a prediction problem and deferring work until a CRQC is announced, when replacement cycles for hardware alone exceed the time left.
• Quoting unsourced Q-Day years: board papers that cite a specific year without attribution lose credibility; cite the deadlines and attribute any estimate.
• Inventory without prioritisation: a long list of every RSA key with no view of data shelf life or migration time does not tell anyone what to do first.
• Ignoring roots of trust: the systems hardest to change, such as secure boot and firmware signing, are found last. The MSI signing keys leak shows how hard such keys are to replace in the field.
• Like-for-like replacement without agility: swapping RSA for ML-DSA in hard-coded form repeats the problem for the next change.
• Supplier assumptions: assuming vendors will handle it, without written roadmaps or contract terms.

Practitioner checklist

• Record quantum risk on the enterprise risk register with an accountable executive and milestones aligned to NCSC, EU or NIST dates.
• Complete a cryptographic inventory and classify data by required secrecy life.
• Identify long-lived roots of trust, firmware signing keys and fixed-crypto devices, with replacement dates.
• Send a PQC questionnaire to critical suppliers and add PQC requirements to contracts and renewals.
• Enable hybrid ML-KEM key exchange on external TLS endpoints after a pilot ring.
• Set a cut-off date after which new systems must support ML-KEM and ML-DSA or be crypto-agile.
• Build PQC costs into hardware, HSM and PKI lifecycle budgets.
• Run a Q-Day tabletop exercise and track resulting actions.
• Report the progress metrics to the board at least twice a year.

Standards and references

• NCSC: Timelines for migration to post-quantum cryptography
• NIST: IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards
• NIST: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST: NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption
• European Commission: A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography
• CISA, NSA and NIST: Quantum-Readiness: Migration to Post-Quantum Cryptography
• NSA: NSA Releases Future Quantum-Resistant Algorithm Requirements for National Security Systems
• Google: Tracking the Cost of Quantum Factoring

Related NHI Mgmt Group resources: Post-Quantum Cryptography Migration Guide · Crypto-Agility Guide · Cryptographic Inventory and CBOM Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Cryptography Basics Guide