Quantum in Government and Defense: A Field Guide to Three Decisions

National Security Memorandum 10 sets 2035 as the target for mitigating quantum risk across federal systems, and the NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) expects National Security Systems to be running quantum-resistant algorithms exclusively by the same year. A commercial web service can treat that as a comfortable runway. A defense programme office signing a contract this year, on a platform with a thirty-year sustainment tail, is looking at a cryptographic end-of-life that lands inside the first third of the service life, and at a supply chain that will quote against the specification as written rather than the one that was intended.

That is the shape of most quantum questions in government and defense. The physics is genuinely interesting and the hardware timelines are genuinely uncertain, but the decisions arriving on desks this year are procurement decisions, architecture decisions, and hiring decisions. They are governed by dates that standards bodies and regulators have already published, not by dates that laboratories will announce later.

This guide is organised around those decisions rather than around the technology.

Three Decisions, Three Ways to Be Wrong

Everything a defense or civil-government organization currently has to decide about quantum technology falls into one of three groups, and each group fails differently.

The first is cryptographic migration. The deadlines exist, they are binding on a large share of government systems, and there is no version of the future in which the work is unnecessary. The failure mode here is lateness, and lateness is expensive in a specific way: a system that misses its window has to be re-engineered under time pressure by whoever is available, rather than re-engineered on schedule by whoever is competent.

The second is assessing claims about quantum hardware, sensing, and communications. Vendors will describe capabilities. Allies and adversaries will announce results. Someone inside the organization has to grade those descriptions before money moves. The failure mode is credulity, and its cost is a procurement that buys a laboratory demonstration dressed as a fielded system.

The third is building option value in quantum computing itself: simulation, optimization, and machine learning. Nothing here is deadline-driven, and a cryptographically relevant quantum computer, meaning one large and stable enough to break RSA or elliptic-curve keys, does not exist and may not for many years. The failure mode is absence. An organization with no working relationship with the technology, no benchmarked pilots, and nobody who can read a results paper will be starting from zero on the day it matters.

Only one of the three depends on when a large quantum computer arrives. We teach these as three separate competencies because they are three separate competencies, held by different people, on different timelines, with different evidence standards.

The Migration Already Under Way

Apologies in advance, because the next few paragraphs are mostly a list of dates. The dates are the whole argument.

The Deadlines That Bind

Post-quantum cryptography, or PQC, means classical algorithms that run on ordinary computers and are designed to resist attack by a future quantum computer. The mathematics is classical throughout, and only the threat it anticipates is quantum.

In August 2024 NIST published the first three standards: FIPS 203 for ML-KEM (formerly CRYSTALS-Kyber), a key-encapsulation mechanism used to establish shared secrets; FIPS 204 for ML-DSA (formerly CRYSTALS-Dilithium), a digital signature algorithm; and FIPS 205 for SLH-DSA (formerly SPHINCS+), a hash-based signature algorithm with a different security foundation. A fourth signature standard, FN-DSA (formerly FALCON), is still in progress, and NIST continues to evaluate an additional key-encapsulation mechanism built on different mathematics from ML-KEM, so that a break in one family does not leave agencies without an alternative. Details of both remain in flux, which is itself a planning input.

On the policy side, National Security Memorandum 10 set 2035 as the target for mitigating quantum risk across federal systems. OMB memorandum M-23-02 obliged federal civilian agencies to build and submit prioritised inventories of cryptographic systems. The Quantum Computing Cybersecurity Preparedness Act, signed in December 2022, put the inventory obligation into law. For National Security Systems, meaning the classified and mission-critical systems governed separately from civil federal IT, the NSA’s CNSA 2.0 sets its own category-by-category schedule, with software and firmware signing moving first and the whole estate expected to be exclusively CNSA 2.0 by 2035.

Read together, these documents say something narrower than “quantum is coming.” They say that a system procured in 2026 with hard-coded RSA will be non-compliant before it reaches mid-life, and that the compliance question will be asked by an auditor rather than by a physicist.

A Worked Timeline

The standard planning question is whether your data will still be sensitive by the time a quantum computer can break RSA, not when that computer arrives.

Take a defense communications system carrying material classified for twenty-five years. Suppose the migration to quantum-resistant algorithms across that system, including cryptographic modules in fielded hardware, takes seven years from funded start to last unit. Suppose you begin funded work in 2027 and finish in 2034.

Now add the collection assumption. Harvest now, decrypt later, usually shortened to HNDL, describes an adversary recording encrypted traffic today and storing it until a quantum computer can decrypt it. Traffic sent in 2027 under RSA is exposed if a capable machine exists at any point before 2052. Traffic sent in 2034 under ML-KEM is not.

The arithmetic gives you a number: seven years of traffic on that link, at whatever daily volume the system carries, sits permanently at risk. Whether that is tolerable is a classification and risk decision, not a technical one, and it is exactly the decision a programme office is positioned to make. What the office cannot make is a decision it never framed. The frame requires knowing three things: how long the data stays sensitive, how long migration takes, and which links are already carrying that data today.

The third of those is usually the missing one. A cryptographic bill of materials, or CBOM, is a structured record of every cryptographic algorithm, key, certificate, and library in a system, along with where each is used and what depends on it. Most organizations discover during inventory that they are running algorithms nobody documented, in appliances nobody can patch, under support contracts nobody can find. That discovery is the actual first deliverable, and it usually takes longer than the leadership briefing predicted.

Signatures Are the Harder Half

Most PQC coverage concentrates on key establishment, because that is where HNDL bites. In government and defense, signatures are frequently the harder problem.

Encryption protects confidentiality in transit, so a link can be upgraded on both ends and the problem is bounded. Signatures establish trust, and trust anchors are embedded. A secure boot chain in a fielded platform verifies firmware against a public key burned into hardware at manufacture. Munitions, avionics, radios, and cryptographic modules in the field may have no mechanism for rotating that key at all. If the anchor uses an algorithm that CNSA 2.0 replaces, the remedy is a hardware refresh, priced and scheduled accordingly.

This is why CNSA 2.0 moves software and firmware signing first, and why it names the stateful hash-based Leighton–Micali Signature (LMS) scheme for that purpose. NIST approves both LMS and XMSS in SP 800-208, but CNSA 2.0 specifies LMS for National Security Systems. Hash-based signatures rest on assumptions that have held for decades and are not threatened by known quantum algorithms. They also carry operational hazards, because a stateful scheme that reuses signing state loses its security guarantee, and state management in a manufacturing environment is an engineering discipline rather than a configuration setting.

The practical instruction for a programme office is to write crypto-agility into the requirement. Crypto-agility means the system can change algorithms without changing hardware or rewriting the application: algorithms are named in configuration rather than in code, key sizes are parameterised, and the trust anchor can be replaced through an authenticated update path. A contract clause specifying ML-KEM-1024 buys you the current answer. A clause specifying that the algorithm can be replaced within a defined maintenance window buys you the next three answers as well.

Grading Claims You Did Not Make

The second competency is evaluative. It has almost nothing to do with building quantum systems and almost everything to do with reading what other people say about theirs.

Physical Qubits, Logical Qubits, and Announcements

A physical qubit is a piece of hardware: a superconducting circuit, a trapped ion, a photon. It is noisy. Left alone, it loses its state in microseconds to milliseconds depending on the technology. A logical qubit is an error-corrected abstraction built from many physical qubits, in which errors are detected and corrected faster than they accumulate. Useful cryptanalysis needs logical qubits, and the conversion ratio between the two is where most confusion in defense reporting originates.

The ratio is not a constant. It depends on the physical error rate, the error-correcting code, and the length of the computation. In 2019, Craig Gidney and Martin Ekerå estimated that factoring a 2048-bit RSA key would take roughly 20 million noisy physical qubits running for eight hours. Later analyses have cut that figure substantially, on the back of algorithmic and error-correction improvements rather than hardware progress, and the requirement still sits far above anything that has been built.

Three things follow, and all three are useful in a briefing. Resource estimates move, and they have moved downward. They move because of software, which means hardware roadmaps alone do not bound the risk. And even the reduced estimates remain orders of magnitude above the largest devices anyone has demonstrated, which is why the responsible statement about timing is that it is uncertain rather than that it is imminent.

When a vendor or a national programme announces a qubit count, the questions that separate a demonstration from a capability are consistent. Is the count physical or logical? Was it demonstrated or announced as a roadmap target? What was the two-qubit gate error rate, and over how many operations? Was the result independently reproduced? DARPA built an entire programme around asking these questions institutionally: the Quantum Benchmarking Initiative exists to test industry claims against a defined utility-scale target rather than accept them, and its posture is a reasonable template for a programme office that lacks a national laboratory.

Quantum Key Distribution in a Procurement File

Quantum key distribution, or QKD, uses the properties of individual photons to establish a shared secret key between two points, in such a way that interception disturbs the photons and reveals itself. The security argument rests on physics rather than on computational hardness, which makes it rhetorically attractive in a defense context.

Both the NSA and the UK’s National Cyber Security Centre have declined to recommend QKD for government use, and the objections are specific enough to be checked against any vendor proposal. QKD establishes keys but does not authenticate the endpoints, so it still requires conventional cryptography or pre-shared keys to prevent an attacker from sitting in the middle. It is point-to-point, requiring dedicated fibre or line of sight, which makes it a poor fit for a routed, resilient network. It is trivially subject to denial of service, since disturbing the channel is the detection mechanism. Its security proofs describe idealised devices, and real detectors have been attacked through side channels. And it protects a key in transit, doing nothing for data at rest, endpoints, or the rest of the system.

China’s Micius satellite and the associated ground network demonstrated that the engineering works at continental scale, and Europe is building EuroQCI on similar principles. None of that resolves the objections above; it establishes feasibility, which is a different claim.

The procurement position that follows treats QKD as a candidate for a small number of fixed, high-value, point-to-point links where the threat model justifies dedicated infrastructure, and never as a substitute for migrating the estate to post-quantum algorithms. Any proposal presenting it as a substitute has answered the wrong question.

Sensing, Where the Ground Is Firmer

Quantum sensing is the part of this field closest to deployment.

The reason is structural. The fragility that makes a qubit difficult to compute with makes it an excellent detector, because a system that responds to tiny environmental changes is precisely what a sensor needs to be. Atomic clocks, which are quantum devices, have been fielded for decades. What is changing is the second generation: magnetometers sensitive enough to register the magnetic disturbance of a submerged mass, gravimeters that measure local variations in gravitational field, and inertial units based on atom interferometry, in which clouds of laser-cooled atoms are split, allowed to travel along separate paths, and recombined, with the interference pattern revealing acceleration and rotation with very low drift.

The defense application that drives funding is navigation without satellites. Conventional inertial systems drift, which is why aircraft and vessels correct against GPS. In a contested environment where GPS is jammed or spoofed, an inertial unit with dramatically lower drift changes what is possible, and it does so passively, emitting nothing an adversary can detect. Airborne trials of quantum navigation payloads have taken place, and the honest current status is prototype rather than product: the open problems are size, weight, power, and behaviour under vibration and temperature swing.

For an acquisition audience, this is a technology readiness question with a familiar shape. The useful discriminator when reading a sensing claim is where the measurement was taken. On an optical bench, in a shielded laboratory, is a physics result. In a vehicle, over a route, against a reference, is an engineering result. Only the second predicts anything about a fielded system.

Quantum radar sits at the other end of the credibility scale. Proposals to detect stealth aircraft using entangled microwave photons have been announced, most prominently from Chinese research groups, and no independent demonstration has shown an advantage at anything approaching operational range. The physics that makes the idea appealing also makes it fragile, since the entanglement is destroyed by the amplification and loss involved in transmitting a signal any distance. Treat it as an open research question, and treat a proposal to buy one as a claim requiring extraordinary evidence.

Buying an Option on Computation

The third decision concerns quantum computing as a computational tool rather than a threat. Here the correct posture is investment sized to option value, not to promised return.

Simulation is the strongest near-term case. Quantum computers are naturally suited to simulating quantum systems, because the thing being modelled and the machine doing the modelling obey the same rules. Materials with strongly correlated electrons, catalysis, energetic materials, and superconductors are all cases where classical approximation methods degrade and quantum simulation is expected to help first. For defense, the relevant downstream questions are propulsion materials, energy storage, and sensor materials. The relevant caution is that current devices are too small and too noisy to beat classical methods on any industrially interesting molecule, and the papers claiming otherwise generally compare against a weak classical baseline.

Optimization is the most oversold. Logistics routing, sortie scheduling, asset allocation, and interceptor assignment are all combinatorial problems, and they are the examples every quantum vendor uses. The known quantum algorithms for these problems offer modest speedups at best, not the exponential advantage that Shor’s algorithm gives for factoring, and the classical competition is decades of highly tuned heuristics. The genuine benefit organizations have reported from quantum optimization pilots is usually indirect: formalising a problem well enough to pose it to a quantum solver frequently exposes a better classical formulation. That is a real return, and it should be claimed honestly rather than reported as quantum advantage.

Machine learning is furthest out. Encoding classical data into quantum states is itself expensive enough to erase most theoretical advantages, and the sub-field has spent several years discovering that proposed quantum speedups had efficient classical equivalents. National programmes are running quantum machine learning experiments, including the UK Ministry of Defence’s work on a photonic system, and the value of those programmes is currently the experience rather than the results.

How to Write a Pilot That Produces a Decision

A pilot that cannot fail teaches nothing. Four conditions turn a demonstration into evidence.

1. Pick a problem you already solve. You need a classical baseline, and the baseline has to be your best classical method rather than your current one. Comparing a quantum solver against a spreadsheet is a comparison with no information in it.
2. Fix the success criterion in writing before you start. Solution quality, wall-clock time, and cost per solved instance, at a stated problem size.
3. Set the problem size where classical methods actually struggle. Small instances always favour the classical machine, so a pilot at toy scale answers nothing.
4. Budget for the write-up. The output of a pilot is a document that a programme office can act on, and the most common failure is a completed experiment that never becomes a decision.

Who Needs to Know What

The three decisions map onto three role families, and training them identically wastes money on all three.

Programme, acquisition, and policy staff need to write and evaluate requirements. Their working knowledge is the deadline structure, the difference between an algorithm and a protocol, how to specify crypto-agility, and how to recognise when a proposal has answered a different question from the one asked. They do not need to implement anything. They do need enough vocabulary to refuse a specification that names an algorithm without naming a replacement path.

Security architects and cryptographic engineers need implementation depth. Inventory tooling and CBOM generation, hybrid key establishment during transition, certificate hierarchies and the operational consequences of larger PQC keys and signatures on bandwidth-constrained links, hardware security module capability and firmware limits, and stateful hash-based signature management. This is the group whose work determines whether those dates are met, and it is usually the group with the largest gap between required and available headcount.

Science and technology assessment staff grade claims. Their competence is reading a results paper, distinguishing physical from logical qubits, distinguishing a demonstration from a product, and recognising a weak classical baseline. In a small organization this may be one person. It should not be zero, and it should not be the vendor.

There is also a structural constraint that civil-sector guidance tends to skip. Government and defense hiring is slower than the commercial market, and cleared quantum-literate staff are scarce in every country that has looked. Training existing cleared personnel is frequently faster than recruiting cleared specialists, which is a reason to start the training conversation earlier than the hiring conversation.

A Twelve-Month Sequence

For an organization with nothing formal under way, the following order has held up in practice.

1. Months 1 to 3. Name an accountable owner with budget authority. Complete a first-pass cryptographic inventory of externally facing and highest-classification systems, accepting that it will be incomplete. Establish the data-lifetime question for each major system, since that number drives everything downstream.
2. Months 4 to 6. Train the acquisition and programme layer first, because they are writing requirements now and every month of delay produces contracts that will need reopening. Insert crypto-agility language into template specifications and into any contract reaching signature.
3. Months 7 to 9. Train the architect and engineer layer to implementation depth. Build the full CBOM. Identify the hardware-anchored systems that cannot be migrated in software, and get them into the capital planning cycle, since those have the longest lead time.
4. Months 10 to 12. Stand up claim-assessment capability, whether that is one trained analyst or a standing review panel. Run one benchmarked computing pilot with a documented classical baseline. Report the migration position to leadership against the published deadlines rather than against internal milestones.

The sequence puts the deadline-bound work first and the exploratory work last, which inverts the order most organizations follow when the subject is introduced by a vendor briefing.

Where to Start

The distinction running through all of this is between what has a date attached and what does not. Cryptographic migration has a date: 2035, published in National Security Memorandum 10 for federal systems and in CNSA 2.0 for National Security Systems, with CNSA 2.0 sequencing categories ahead of it. Sensing has readiness levels and a growing procurement pipeline. Quantum computing has an uncertain arrival and a certain requirement that somebody in the building be able to tell a demonstration from a capability.

Quantum Academy builds training for each of those three groups, and the two pathways that carry most of this material are a post-quantum migration track aimed at the architects and engineers who will do the implementation work, and an executive and programme track aimed at the people writing requirements and defending budgets. Both are private professional credentials rather than accredited degrees or government licences, and both are designed to be completed alongside a working role.

You can see the current programs and enrolment options at quantumacademy.com/.

For the migration methodology behind the inventory and crypto-agility material, see pqcframework.org. For deeper technical analysis of quantum hardware progress and resource estimates, PostQuantum.com tracks the primary literature. And for individuals mapping a route into this work rather than an organization mapping a programme, QuantumCareers.com covers the role families and their entry points.