How To Prepare For Quantum Computing, The Complete Readiness Guide

Knowing how to prepare for quantum computing now means two separate jobs, and most organisations only think about one of them. The first is defensive, because a future quantum computer will break the public-key cryptography that protects almost everything you send and store, and the deadlines for fixing that are already published, and in the US federal sector they already bind. The second is offensive, because quantum machines are now rentable by the hour and the people who can use them are scarce.

This guide is the practical version. It tells you which deadline actually applies to you, how to find the cryptography you did not know you had, what to do in what order, and how to build the capability to use these machines rather than just defend against them. The threat itself is covered in our guide to Q-Day, and the vendors in our directory of post-quantum cryptography companies, so neither is repeated here.

The two things you are preparing for

The question of how to prepare for quantum computing covers two programmes that share a name and almost nothing else. They have different owners, different budgets and different clocks, and conflating them is the most common planning error we see. Separate them on day one.

Defending is a cryptography migration. It is mandatory, it is dated, and it is mostly an inventory and engineering problem rather than a quantum problem. You do not need to understand qubits to do it, and it will consume years of engineering time whether or not a quantum computer ever arrives.

Adopting is a capability question. It is discretionary, it has no deadline, and it is genuinely about quantum. It costs very little to begin and the main risk is spending real money too early on problems that classical computers still solve better.

The defensive job is urgent and the adoption job is not. If you only have budget for one thing this year, the cryptography migration is the one with a published deadline attached, and for US federal agencies and their suppliers a binding one. The rest of this guide treats them in that order.

Why the timing question is already settled

The old debate asked whether quantum computers were really coming. That question no longer governs the decision, for a reason that has nothing to do with hardware progress. The data you transmit today can be recorded today and decrypted years later, once a machine exists.

This is harvest now, decrypt later. An adversary with storage and patience does not need a quantum computer in 2026, they need one eventually. Any secret with a shelf life into the 2030s, which includes health records, financial data, state secrets, source code signing keys and most intellectual property, is already exposed if it crosses a network protected only by RSA or elliptic curve cryptography.

That flips the planning logic. You are not racing the arrival of a quantum computer, you are racing the lifetime of your own data. If your data must stay confidential for ten years, and migration takes you five, then you needed to start five years ago.

What the hardware estimates actually say

The engineering picture has moved sharply in the wrong direction for defenders. In 2019 Craig Gidney and Martin Ekerå estimated that breaking RSA-2048 would take a quantum computer with 20 million noisy qubits about eight hours. In May 2025 Gidney, who works at Google Quantum AI, published a revised estimate.

The new figure is fewer than one million noisy qubits, running for under a week. That is roughly a twentyfold reduction in the machine you need, achieved in six years, and it came from better algorithms rather than better hardware. Note the word noisy, because these are physical qubits, not logical ones, and anyone quoting a million logical qubits has misread the paper.

Expert opinion has moved with it. The Global Risk Institute surveys quantum researchers annually, and its Quantum Threat Timeline Report puts the likelihood of a cryptographically relevant quantum computer within ten years at 28 to 49 percent, and within fifteen years at 51 to 70 percent. The ten-year figure is the highest in the survey’s seven-year history.

None of this means a machine exists. It means the responsible planning assumption is no longer “probably never” and the people setting your deadlines have already concluded as much.

The deadlines that already apply to you

Most of how to prepare for quantum computing comes down to a date, and the single most useful thing you can do this week is work out which of these regimes you fall under. Most organisations are governed by at least one, and many discover they are governed by a customer’s regime rather than their own.

Every date below is summarised from a published document, and each document is linked. Check the primary source before you plan against a date, because several of these instruments are still drafts and all of them can be revised.

The standards themselves

NIST published the first three post-quantum standards on 13 August 2024, and they are final. FIPS 203 specifies ML-KEM, derived from CRYSTALS-Kyber, for key establishment. FIPS 204 specifies ML-DSA, derived from CRYSTALS-Dilithium, and FIPS 205 specifies SLH-DSA, derived from SPHINCS+, both for digital signatures.

Two more are coming and neither is finished. As of July 2026 NIST has published no draft of FIPS 206, which covers FN-DSA and is based on Falcon. HQC was selected in March 2025 as a backup key-encapsulation mechanism built on error-correcting codes rather than lattices, and NIST has said it expects to finalise that standard in 2027. If you see a vendor citing “FIPS 207” for HQC, treat it as a signal to check their other claims, because NIST has assigned no such number.

What NIST says about your existing cryptography

NIST IR 8547 is the transition document, and it remains an initial public draft from November 2024 rather than a final publication. Its draft intention is nonetheless the number everyone is planning against, because US federal policy now instructs agencies to align to it.

The intention is that RSA, ECDSA and Diffie-Hellman at the 112-bit security level, which is where RSA-2048 and the P-224 curve sit, are deprecated after 2030 and disallowed after 2035. NIST’s own definitions matter here and are widely misreported. Deprecated means the data owner may still use it while accepting a stated security risk. Disallowed means it may not be used for that purpose at all.

Read the security level carefully, because it is the detail most coverage gets wrong. The widely deployed P-256 curve sits at the 128-bit level rather than the 112-bit one, so it is disallowed after 2035 with no 2030 deprecation step of its own, and EdDSA is listed only at 128 bits and above for the same reason. RSA-2048 does carry the 2030 date, and so does P-224.

The United Kingdom

The NCSC published its guidance on how to prepare for quantum computing in the UK in March 2025, and it is the clearest of the national schedules because it tells you what to have finished rather than what to stop using. There are three milestones and they are cumulative.

By 2028 you should have defined your migration goals, carried out a full discovery exercise and built an initial migration plan. By 2031 you should have completed your highest-priority migration activities and refined that plan into a thorough roadmap. By 2035 you should have completed migration across all systems, services and products.

Read the 2028 milestone carefully, because it is the one that binds. Discovery across a large estate is a multi-year exercise, and 2028 is not far away for work that has not started.

The United States, which changed in June 2026

This is the part most published guidance has not caught up with. Executive Order 14412, signed on 22 June 2026, and OMB memorandum M-26-15, issued on 24 June 2026, together reset the federal timeline. The memorandum does not apply to national security systems, and the executive order excludes them from its civilian transition requirements, so they run on the separate NSA track.

M-26-15 gives every agency 120 days to submit a post-quantum migration plan to OMB and the Office of the National Cyber Director, which falls due around 22 October 2026. It sets out five phases: strategy and discovery through 2026 and 2027, pilots and early migration through 2027 and 2028, prioritised migration to post-quantum key establishment by the end of 2030, signature migration during 2031, and full migration by 2035. It requires agencies to align their plans with NIST IR 8547, and it requires TLS 1.3 support no later than 2 January 2030.

For national security systems, the NSA’s CNSA 2.0 suite runs to its own dates. Under CNSSP-15, new acquisitions must be CNSA 2.0 compliant from 1 January 2027, equipment that cannot support it must be phased out by 31 December 2030, and CNSA 2.0 is mandated from 31 December 2031. The stated intent is that all national security systems are quantum-resistant by 2035.

If you sell to the US government, these dates are your dates too, and they are already specific. Executive Order 14412 directs the FAR Council to propose a procurement rule requiring covered contractors to comply with the post-quantum FIPS standards by 31 December 2030. That is how this reaches most suppliers, through a contract clause rather than a statute.

Europe and Canada

The European Commission issued a recommendation on a coordinated post-quantum transition in April 2024, and the NIS Cooperation Group published the coordinated implementation roadmap in June 2025. Member states are expected to have initial national roadmaps by the end of 2026, to have migrated high-risk use cases by the end of 2030, and to complete the transition as far as is feasible by the end of 2035.

Canada is the most specific of the lot. The Canadian Centre for Cyber Security published ITSM.40.001 in June 2025, requiring federal departments to produce an initial migration plan by April 2026, complete migration of high-priority systems by the end of 2031 and finish the remainder by the end of 2035. Its definition of completion is the sharpest sentence in any of these documents, because it says the quantum-vulnerable algorithms must actually be disabled, isolated or tunnelled, rather than merely joined by post-quantum ones.

That distinction is worth stealing regardless of where you operate. Supporting a post-quantum algorithm is not the same as having removed the vulnerable one, and only the second one reduces your risk.

Step one, find the cryptography you did not know you had

Every framework for how to prepare for quantum computing starts here, and it is the step organisations consistently underestimate. You cannot migrate an algorithm you do not know you are running, and cryptography hides in places that no architecture diagram records.

It is embedded in application code and in libraries those applications import. It is in TLS terminators, load balancers, VPN concentrators and the firmware of hardware you have not logged into for years. It is in code-signing pipelines, in the certificates your build system trusts, in database encryption, backup systems, payment terminals, and in whatever a third-party supplier is doing on your behalf.

What discovery should produce

The output is not a report, it is an inventory that stays alive. For every system you want the algorithms in use, the key sizes, where the keys live, who owns the system, what data it protects and how long that data must stay confidential. That last field is the one that drives everything else, because it converts a technical inventory into a prioritised queue.

Discovery is also where you find the things you cannot fix. Hardware with cryptography burned into silicon, vendors who have gone out of business, systems whose source code nobody has. Those are not migration problems, they are replacement problems, and they have the longest lead times of anything on your list.

The cryptographic bill of materials

A cryptographic bill of materials, or CBOM, is the machine-readable version of that inventory. It lists every cryptographic asset in a system, meaning the algorithms, key lengths, certificates, protocols and libraries, along with the relationships between them. It is to cryptography what a software bill of materials is to dependencies.

The standard to use is OWASP CycloneDX, which introduced CBOM support in version 1.6 in April 2024 and carries it forward in the current 1.7 releases. CycloneDX is also an Ecma International standard, ECMA-424, which matters if you need to justify the choice to an architecture board.

The reason to do this now rather than later is that it is becoming an expectation rather than a best practice. Executive Order 14412 directs CISA to publish CBOM guidance, and OMB M-26-15 asks agencies for an automated and continuously updated cryptographic inventory. A CBOM you generate from your build pipeline satisfies that. A spreadsheet somebody maintained by hand for one quarter in 2026 does not.

Crypto-agility is the actual goal

The deeper point of the inventory is not this migration, it is the next one. HQC exists precisely because NIST wants a backup in case lattice-based cryptography is broken, and the history of cryptography suggests that something on today’s approved list will eventually fall.

Crypto-agility means an algorithm is a configuration choice rather than an architectural assumption. If swapping a signature algorithm requires you to recompile forty services and renegotiate six vendor contracts, you are not agile, and you will be doing this whole exercise again from scratch in a decade.

Step two, migrate in priority order

You cannot do everything at once and nobody expects you to. The order is dictated by two variables, and only two: how long the data must stay secret, and how hard the system is to change.

Data with a long confidentiality lifetime and a network path is the emergency, because that is exactly what harvest now, decrypt later takes. Data that is already public, or that is worthless in five years, can wait however long it needs to.

Key establishment before signatures

Every serious schedule migrates key establishment first and signatures second, and the US federal plan makes the split explicit with key establishment due by the end of 2030 and signatures during 2031. The logic is the harvest problem again. A key exchange you perform today can be recorded today and broken later, which retroactively exposes that session forever.

A signature, by contrast, is verified at the time it is used. Forging one requires a quantum computer that exists at the moment of the forgery, so a recorded signature from 2026 is not a liability in the same way. Signatures still have to migrate, and code-signing keys with long validity periods are a real exception, but the key exchange is what is bleeding right now.

Hybrid, and where it is not welcome

The common deployment pattern is hybrid, running a classical and a post-quantum algorithm together so the session is secure if either survives. OMB M-26-15 points at exactly this, naming ML-KEM-768 alongside x25519 in a TLS 1.3 key exchange as the example. It is the low-risk path, because a flaw in the new algorithm does not leave you worse off than you started.

Be aware that not every regulator agrees. Some national schemes prefer a clean break to post-quantum only, on the grounds that hybrid doubles the implementation surface and lets teams claim completion while the vulnerable algorithm is still doing the work. Check your own regulator before standardising on hybrid, because this is one of the few places where the guidance genuinely conflicts.

Step three, build the capability to use quantum computers

This is the half of how to prepare for quantum computing that gets ignored, and it is the half with upside. It is also far cheaper than most people assume, because you no longer need to buy anything to get started.

Getting hands on real hardware

Quantum computers are rentable, and one of them is free. IBM’s Open Plan gives you up to ten minutes of real QPU time per rolling 28-day window, which is the only no-cost route to real hardware on the major providers’ standard self-service plans. Ten minutes is more than it sounds when a circuit runs in microseconds.

Beyond that, the hyperscalers act as brokers rather than manufacturers. As of July 2026, Amazon Braket resells AQT, IonQ, IQM, QuEra and Rigetti. Azure Quantum resells IonQ, Pasqal, Quantinuum and Rigetti. It is worth being precise about Google, because this trips people up constantly: Cirq is a software library and gives you no hardware access at all, and Google’s own processors are not available for public self-service booking. Our guide to the quantum cloud providers covers the routes in detail.

Choosing a problem worth the effort

The failure pattern here is picking a problem because it sounds quantum rather than because it is painful. A candidate worth your time has three properties. It is genuinely hard classically, meaning you are already accepting a bad approximation. It is small enough to express on hardware that has error rates. And you have a classical baseline good enough to tell you honestly whether the quantum version is better.

That last one is where most pilots quietly fail, because without a real baseline any result looks like a result. If you cannot say what “better” would look like before you start, you are not running a pilot, you are running a demonstration.

People

The scarcity is real and measurable. QED-C counted 16,482 pure-play quantum workers worldwide in its 2026 industry report, and separately counted 8,261 new quantum-related job openings posted during 2025. The two figures count different populations, so they do not divide into a tidy ratio, but the direction of travel is not in doubt.

The good news is that the hiring bar is lower than the folklore suggests. You do not need a room of physics PhDs to start, you need software engineers who can learn a new computational model. The European Competence Framework for Quantum Technologies describes quantum roles across proficiency levels, including those below research scientist. Growing people internally is currently faster than hiring them.

What quantum computers will actually be good at

Adoption planning goes wrong when people expect a faster computer. A quantum computer is not a faster computer, it is a differently-shaped one, and it is worse than your laptop at almost everything. The value sits in a narrow set of problems where the shape happens to match.

Knowing which problems those are is most of the work, because it tells you which parts of your business to even look at. It also tells you which vendor pitches to ignore.

Simulating nature, which is the strongest case

Chemistry and materials science are quantum systems already, and simulating them on classical hardware means approximating away the quantum behaviour that matters. This is the application with the clearest theoretical advantage, because you are using a quantum system to model a quantum system rather than forcing it through a classical abstraction.

The practical targets are catalyst design, battery chemistry and drug binding. If your business depends on discovering molecules or materials, this is the case worth watching, and it is the one most likely to produce genuine value first.

Optimisation, where the hype is loudest

Routing, scheduling and portfolio problems get the most vendor attention and deserve the most scepticism. Classical solvers for these problems are extremely good, decades of engineering have gone into them, and a quantum advantage has to beat that moving target rather than a naive baseline.

This does not mean the case is empty, it means the burden of proof is high and the honest baseline matters more here than anywhere else. Treat any optimisation demo that does not name the classical solver it beat as marketing.

Machine learning, where the case is weakest

Quantum machine learning attracts funding because both words are fashionable, and the theoretical position is considerably less settled than the marketing suggests. Several early claims of advantage have been overturned by better classical algorithms, which is a healthy scientific process and an expensive one to have bet a budget on.

Watch this space rather than staffing it. If your quantum programme depends on machine learning producing an advantage, it is a research project rather than a business initiative, and it should be funded and governed as one.

What this means in your sector

The defensive deadlines are universal but the urgency is not, because urgency is a function of how long your data must stay secret. These are the patterns we see most often.

Financial services

You are near the front of the queue, because transaction data, customer records and long-dated contracts all carry confidentiality lifetimes measured in decades. Regulators are also moving, and in finance a regulator expectation tends to arrive well before a legislative deadline. Payment infrastructure and hardware security modules are the hard part, since they are the systems least likely to accept a software-only upgrade.

Healthcare and life sciences

Patient records have among the longest confidentiality lifetimes of any data anybody holds, which puts you squarely in the harvest-now-decrypt-later target set. You also have the strongest adoption case of any sector, because molecular simulation is the application where quantum advantage is most plausible. This is the one sector where both halves of the programme deserve real funding at the same time.

Government and defence

Your deadlines are the hardest and they are already written down. In the United States, national security systems follow CNSA 2.0 rather than the civilian schedule, and procurement requirements will reach your suppliers before they reach you. If you sell into this sector, your customer deadline is your deadline, and it will appear in a contract long before it appears in the news.

Manufacturing, energy and logistics

Your defensive exposure is often lower, because much operational data is worthless once it is stale. Your problem is different and harder, because operational technology carries cryptography embedded in devices installed decades ago that cannot be patched. That is a replacement programme with a capital budget rather than a migration, and it needs to start earliest precisely because it moves slowest.

How to evaluate a post-quantum vendor

The market has filled with post-quantum products, and a fair number of them are existing products wearing a new label. These questions separate them quickly, and none of them require you to understand the mathematics.

Which named NIST standard do you implement? The answer should be FIPS 203, 204 or 205, by number. Anything citing a standard that does not exist yet, or a proprietary algorithm of their own devising, is a red flag rather than an innovation.

Does this give me an inventory, or does it just add an algorithm? Products that help you discover what cryptography you are already running are worth more right now than products that encrypt something new, because discovery is the step you cannot skip.

What happens when the algorithm changes again? If the answer involves replacing the product, you are buying the next migration along with this one. Crypto-agility is a property to procure deliberately, not an adjective in a brochure.

Can you evidence this to an auditor? A CBOM generated by your build pipeline is evidence. A vendor assertion is not, and that difference will matter as CBOM guidance moves from recommendation to expectation. OMB M-26-15 already names the artefact, calling for a dynamic and continuously updated inventory of cryptographic assets that should populate a central cryptographic bill of materials.

The five ways organisations get this wrong

These are the recurring errors in how to prepare for quantum computing, and each one is expensive in a different way. Most of them come from treating the deadline as the problem rather than the estate.

Waiting for the quantum computer

The most costly mistake, and the most understandable. It treats the arrival of the machine as the starting gun, when the harvest problem means the gun went off when your data was created. By the time a cryptographically relevant quantum computer is announced, the data you sent last year is already sitting in somebody’s archive.

Buying a product instead of doing the inventory

Vendors will happily sell you a post-quantum solution before you know what you are running. A quantum-safe VPN protects the traffic in that VPN and does nothing about the code-signing key in your build pipeline. Discovery is unglamorous and it is the only step that tells you which product you actually need.

Treating 2035 as the deadline

2035 is when the vulnerable algorithms become disallowed. The dates that will govern your actual programme are 2028 for UK discovery, 2030 for deprecation and for US federal key establishment, and 2031 for high-priority completion. Planning to the last date in the sequence is how you miss the three that come first.

Forgetting the supply chain

Your cryptography is only as migrated as your least-prepared supplier. If a payment processor, an identity provider or an embedded device vendor cannot support post-quantum algorithms, your migration stops at their boundary. Procurement language is a migration tool, and it is the one with the longest lead time, so it belongs in year one rather than year three.

Believing anything with a made-up standard number

A working test for vendor credibility. As of July 2026, NIST has published no draft of FIPS 206 and has assigned no FIPS number to HQC. Anyone selling you compliance with a standard that does not exist yet is telling you something useful about their other claims.

What it costs, roughly

Nobody can price your migration from the outside, because the cost is driven by how much cryptography you own and how much of it is embedded in things you cannot patch. What can be said is which line items dominate, and they are rarely the ones in the budget request.

Discovery is mostly people and time rather than licences, and it is the item most often underfunded. Replacement of unpatchable hardware is the item most often missed entirely, and it carries the longest lead time and the largest number. Testing is the item most often underestimated, because post-quantum keys and signatures are larger than the ones they replace, and that shows up as latency and payload size in protocols that were tuned around the old sizes.

The adoption side, by contrast, is genuinely cheap to start. A free IBM account, two engineers and one honestly-baselined problem will tell you more about whether quantum matters to your business than any consulting engagement, and it costs a rounding error by comparison.

Your first twelve months

If you do nothing else, do this. It is ordered so that the long-lead items start early, because the binding constraint on how to prepare for quantum computing is almost never the cryptography, it is the calendar.

Months one to three

Name an owner, because a programme without one will not survive its first budget cycle. Establish which regulatory regime binds you, and check whether a major customer’s regime binds you harder than your own. Begin discovery on your most sensitive systems rather than your easiest ones.

Months four to six

Extend discovery across the estate and start producing a CBOM from your build pipeline rather than by hand. Classify data by how long it must stay confidential, since that is what converts the inventory into a priority order. Get post-quantum clauses into your procurement templates now, because contracts signed this year will still be running when the deadlines land.

Months seven to twelve

Pilot a hybrid key exchange somewhere real but survivable, typically an internal TLS path, and measure what it costs you in latency and payload size. Identify the systems that cannot be migrated and start the replacement conversations, because those have multi-year lead times. In parallel, and for almost no money, put two engineers on a free IBM account with one honestly-baselined problem.

At the end of that year you will not be migrated. You will know what you have, what order to fix it in, what it will cost and who cannot help you, and that is what how to prepare for quantum computing actually delivers in year one. It is the difference between a programme and a good intention.

Frequently asked questions