up:: Doing the Work MOC
Deprecation, Not Deployment
Deprecation, not deployment is the principle that a system becomes genuinely quantum-resistant only once its quantum-vulnerable algorithms have been deprecated and removed, so that switching on a post-quantum algorithm counts as a milestone along the way while the finish line is the moment the breakable classical path is gone. It matters because most migration scoreboards measure the wrong thing. They count where ML-KEM has been enabled, which feels like progress, when the number that reflects actual security is how many systems can still fall back to RSA or ECDH. A migration that has deployed everywhere and deprecated nothing has closed zero exposure, because every classical primitive a Shor’s-algorithm machine breaks is still sitting on the wire.
The short version:
- Deploying a post-quantum algorithm is a milestone. The migration is finished when the quantum-vulnerable algorithm is deprecated and removed so nothing can fall back to it.
- A system running hybrid still contains the classical component a quantum computer breaks, so “we deployed ML-KEM” leaves real exposure until the classical half comes out.
- NIST IR 8547 frames the goal as removal: 112-bit RSA, ECDSA, and ECDH are deprecated after 2030, and all classical RSA, ECC, and Diffie-Hellman signature and key-establishment schemes are disallowed after 2035.
- The U.S. Department of War’s 2026 PQC Strategy sets the same shape for defense: every system supports PQC or is phased out by December 31, 2030, and every system uses PQC by December 31, 2031.
- Measure the program by what’s gone, not by what’s turned on. A CBOM that tracks deprecation is the honest scoreboard.
Think of upgrading the doors on a building. Installing a reinforced front door with a new lock nobody has learned to pick feels like the job is done. If the old back door is still standing and still opens with the flimsy lock you always had, a burglar just walks around and comes in the back. Deploying a post-quantum algorithm is the reinforced front door. Deprecating the classical one is bricking up the back door, and until that happens a quantum computer takes the same easy path in that was always there.
What does “deprecation, not deployment” mean?
It means the success condition of a post-quantum migration is the absence of the vulnerable algorithm, rather than the presence of the new one. The two are easy to confuse because deployment is visible and satisfying: a config change lands, a dashboard turns green, ML-KEM shows up in the handshake. Deprecation is quieter and harder. It means going back to every place the classical algorithm lived, confirming it can’t be selected, and removing the fallback that kept it available “just in case.”
The reason the distinction is load-bearing sits inside hybrid cryptography, which is how almost every organization deploys PQC first. A hybrid key exchange runs a classical algorithm and a post-quantum one together and derives the session key from both, so the connection holds as long as either half survives. That’s a deliberate hedge against a young post-quantum algorithm having an undiscovered flaw.
The catch is that the classical half is the exact thing a cryptographically relevant quantum computer breaks. While the hybrid runs, the classical component is still present in the protocol, and a system that has “deployed” hybrid and stopped there has not deprecated anything. NSA’s CNSA 2.0 is explicit that hybrid is a transitional accommodation and that the destination is standalone post-quantum algorithms, so the deployment of hybrid is the beginning of the work rather than its completion.
Source: NSA, “The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ,” CSI_CNSA_2.0_FAQ.
Why is switching on a post-quantum algorithm only the halfway point?
Because the quantum exposure lives in the algorithm that’s still reachable, and enabling a new one beside it does nothing to that exposure. Three things have to be true before a primitive stops being a quantum liability, and only the first is deployment:
- The replacement is available. The endpoint can perform the post-quantum operation. This is the deployment step, and it’s necessary.
- The replacement is preferred. Negotiation actually selects the post-quantum path in normal operation, rather than leaving it as an option that rarely wins.
- The vulnerable path is removed. The classical algorithm can’t be negotiated at all, so there’s nothing for an attacker to downgrade to and nothing a quantum computer can decrypt from captured traffic.
A program that stops after step 1 has spent real effort and closed no exposure, which is the trap. The harvest-now-decrypt-later threat makes this concrete: an adversary recording your traffic today doesn’t care whether ML-KEM is available on your servers. It cares whether the session it captured used a classical key exchange it can break later. If the classical path is still reachable and still gets negotiated on some fraction of connections, those sessions stay harvestable no matter how thoroughly the new algorithm was deployed. Removal is what shuts the recording off.
What is the difference between deprecated and disallowed?
They’re two different instructions, and NIST IR 8547 keeps the vocabulary precise. Deprecated means the algorithm is still permitted, but its use now carries a risk the data owner has to formally accept: the “you may, but you’re on the clock” state. Disallowed means prohibited for the stated purpose, with no exceptions. Deprecation is the on-ramp to removal, and disallowance is the hard stop where removal becomes mandatory. The gap between them is the migration window, deliberately built in so organizations can keep a vulnerable primitive running under formal risk acceptance while they do the work of taking it out, rather than facing a single overnight cutover.
Source: NIST IR 8547 ipd, “Transition to Post-Quantum Cryptography Standards,” November 2024, §3.
The practical reading is that deprecation is a countdown, not a reprieve. A primitive that’s merely deprecated is still exploitable, and the risk acceptance is a signature on the exposure rather than a fix for it. The point of naming a deprecation year is to force the removal work to start, so that disallowance is a formality the program already met instead of a wall it hits.
How do you measure a migration by deprecation instead of deployment?
You change what the scoreboard counts, from primitives added to primitives removed. A deployment metric and a deprecation metric can both be measured against the same cryptographic inventory, but they tell you opposite things about your quantum exposure. The deployment view flatters the program; the deprecation view is the one an auditor, a regulator, or a quantum computer actually tests.
| Question | Deployment metric (looks like progress) | Deprecation metric (real quantum resistance) |
|---|---|---|
| What it counts | Systems where a post-quantum algorithm is enabled or negotiable | Systems where the quantum-vulnerable algorithm has been removed and can’t be negotiated |
| What a green status means | ML-KEM is available on the endpoint | RSA and ECDH are gone, with no fallback path |
| Residual quantum exposure from that primitive | Full, because the classical path a quantum computer breaks is still reachable | Closed, because the breakable path has been removed |
| The failure it can hide | A hybrid or dual-stack running the classical half indefinitely | This is the state that ends the exposure |
| The governing deadline | None; deployment is a milestone, not the goal | Deprecate by the NIST or CNSA date, disallow after it |
Source: deprecate/disallow schedule per NIST IR 8547 ipd, §4; the hybrid classical-component exposure per draft-ietf-tls-hybrid-design.
The verification wrinkle is that a deprecation metric can only be trusted if it’s checked on the wire rather than read from a config file. A setting that says the classical algorithm is disabled is a claim, and the honest measurement is a packet capture or a scan showing the vulnerable group genuinely can’t be negotiated. This is where crypto-agility pays off in reverse: the same central control that let you turn the new algorithm on is what lets you turn the old one off everywhere and prove it, instead of chasing the fallback through hundreds of individual configurations.
When does the quantum-vulnerable algorithm actually have to be gone?
On the schedule the mandates set, and the mandates express the goal as removal with a date attached. Two primary sources put hard years on it. NIST IR 8547 sets the civilian and de facto industry clock, and the U.S. Department of War’s 2026 PQC Strategy sets the defense clock, both framing the endpoint as classical cryptography being retired rather than post-quantum cryptography being present.
| Authority | Deprecate / stop new use | Disallow / must be removed | What it binds |
|---|---|---|---|
| NIST IR 8547 (Initial Public Draft) | 112-bit RSA, ECDSA, ECDH deprecated after 2030 | all classical RSA, ECC, and DH signature and key-establishment schemes disallowed after 2035 | federal agencies, contractors, FIPS-validated vendors; de facto industry clock |
| U.S. Department of War PQC Strategy (2026) | every system supports PQC or is phased out by December 31, 2030 | every system uses PQC by December 31, 2031, with non-compliant systems retired | Department of War components, high-impact NSS and non-NSS infrastructure |
Source: NIST IR 8547 ipd, §4, Tables 2 and 4.
Source: U.S. Department of War, “Post-Quantum Cryptography (PQC) Strategy,” Department of War Chief Information Officer, released June 2026, DoW PQC Strategy; public-release reporting, DefenseScoop, “Uncertain quantum future presents ‘existential threat’ to US military missions, DOD warns,” June 25, 2026, defensescoop.com.
The years to watch are the disallowance and full-transition dates, because those are the ones that require the classical component to be gone rather than merely on notice. A system that reads “deployed” today but still negotiates classical key exchange in 2035 is out of compliance with NIST’s schedule, and a Department of War system doing the same in 2031 is slated to be phased out. The deadline was never “have PQC available.” It’s “have the vulnerable algorithm removed.”
Where does the deprecation-first principle come from?
It comes from the way the governing documents define done, and two of them say it plainly. NIST built its entire transition around a deprecation-and-disallowance schedule rather than a deployment target, so the official measure of the migration is which algorithms have exited, keyed to years. The Department of War’s 2026 PQC Strategy makes the same move for defense networks and states it directly, framing genuine readiness as the complete deprecation of legacy algorithms across an organization’s data pathways, software supply chain, and storage, rather than the rollout of new ones. The strategy pairs that framing with enforcement: systems that fail to meet the transition gates are retired.
Source: U.S. Department of War, “Post-Quantum Cryptography (PQC) Strategy,” 2026, DoW PQC Strategy, as reported in Quantum Computing Report, “Department of War Unveils Enterprise Post-Quantum Cryptography Strategy,” July 2026, quantumcomputingreport.com.
The reason both authorities landed in the same place is that the threat model forces it. Mosca’s theorem frames the migration as a race that finishes only when the vulnerable algorithm can’t be reached, because a machine that arrives while any classical path remains open still wins on that path. Standing up ML-KEM changes nothing about that race until the classical route is closed, which is why a serious mandate counts removals and a vanity dashboard counts deployments.
Common misconceptions
- “We deployed ML-KEM, so we’re done.” Deployment makes the fix possible; it doesn’t make it real. A migration is complete when the quantum-vulnerable algorithm has been deprecated and removed, so nothing can fall back to the path a quantum computer breaks.
- “Hybrid is the finished state.” Hybrid runs a classical algorithm and a post-quantum one together, and the classical half is the breakable part. A hybrid with no plan to retire its classical component is an unfinished migration wearing a reassuring label.
- “Deprecated means we have to rip it out today.” Deprecated means still permitted under formal risk acceptance by the data owner. Disallowed is the hard stop where removal becomes mandatory, and the gap between the two dates is the migration window.
- “A green ‘PQC enabled’ dashboard means we’re covered.” Enabled and removed are different states. The metric that reflects security is how many systems can still negotiate the classical algorithm, which a deployment dashboard doesn’t show.
- “This is only about key exchange.” Both jobs of public-key cryptography have to shed their classical algorithms. Key establishment is the HNDL-urgent lane, and signatures and PKI migrate on a more deliberate track, but the endpoint for each is the vulnerable primitive gone, not the new one merely present.
Questions people ask
Does deploying hybrid mean we’re quantum-resistant? Not yet. Hybrid protects new sessions immediately because the post-quantum half is running, which is genuinely valuable against harvesting. Full quantum resistance for that primitive arrives when the classical half is deprecated and removed, because until then a captured session still has a classical key exchange a quantum computer can break.
If we’ve turned on ML-KEM everywhere, what’s left to do? Confirm the classical algorithms can’t be negotiated and then remove them. Deployment is step one; the remaining work is making the vulnerable path unreachable and proving it on the wire, so there’s nothing left to downgrade to or decrypt from stored traffic.
What’s the difference between “deprecated” and “disallowed”? Deprecated means still usable with formal risk acceptance by the data owner, a countdown rather than a ban. Disallowed means prohibited outright. In NIST IR 8547 the 112-bit public-key algorithms are deprecated after 2030 and everything classical is disallowed after 2035.
Which deadline actually applies to us, 2030, 2031, or 2035? It depends on who binds you. Federal and FIPS-aligned organizations work to NIST IR 8547’s 2030 deprecation and 2035 disallowance. Department of War components work to the strategy’s 2030 support and 2031 full-transition gates. Application-specific standards for protocols like TLS can pull the real date years earlier for a given system.
How do we know the classical path is actually gone rather than only disabled in config? You verify it on the wire. A packet capture or an external scan of the handshake shows which groups the endpoint will genuinely negotiate, which is the honest test. A config flag is a claim about the state; the capture is the evidence, and this is exactly the kind of check a CBOM-driven program keeps running.
Why keep the classical algorithm at all during hybrid, if it’s the vulnerable part? As a hedge against the young post-quantum algorithm having an undiscovered flaw. The classical algorithm has decades of cryptanalysis behind it, so running both means a break of either one alone doesn’t expose the session. That hedge stops paying once the post-quantum algorithms have accumulated scrutiny and a quantum computer looks near, which is when the classical half should come out.
Does deprecation apply to symmetric algorithms like AES? Mostly no. NIST IR 8547 keeps AES-256 and the SHA-2 and SHA-3 families acceptable, since a quantum computer only weakens symmetric cryptography rather than breaking it. A narrow set of 112-bit symmetric primitives is disallowed after 2030, so those get swept up, but the deprecation-first pressure is overwhelmingly a public-key story.
Who decides when we can finally remove RSA and ECDH? During the deprecation window, the data owner accepts the risk of continued use, so the removal timing is a governance decision inside your program. The disallowance date is the hard stop that takes the choice away, which is why owning the removal early beats being forced into it against a deadline.
Everything here is the map, given freely. When your team needs its own estate measured by what’s actually been deprecated, and the classical paths sequenced out of your systems on a plan your board and your regulator will accept, that’s what an alignment briefing is for.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.