NIST Picked the Quantum-Safe Locks—So Why Are Most Companies Shipping a ‘Quantum Upgrade’ That Still Breaks in One Place?
NIST’s post-quantum standards made the locks official. But most real deployments still leave one brittle seam—often classical authentication or an un-upgraded last hop—where the promise collapses.
By TheMurrow Editorial
March 7, 2026
Key Points
- 1Track what NIST standardized: FIPS 203/204/205 (Aug 13, 2024) plus HQC as a backup KEM selected March 11, 2025.
- 2Assume most “quantum upgrades” are partial: hybrid key exchange may protect one hop while authentication and internal links remain classical.
- 3Demand end-to-end specifics: which connections, which functions (KEM vs signatures), which standards, and what rollback/downgrade protections exist.
A “quantum upgrade” sounds like the sort of thing you schedule: buy the new module, flip the switch, declare victory. Vendors encourage that impression. So do many demos—especially the ones that show a post-quantum handshake lighting up in a packet trace.
Yet cryptography almost never fails at the part that makes for a good demo. It fails at the seam: the one interface between old and new, the one certificate chain still anchored to yesterday’s math, the one “last hop” in a network path that never got the memo.
On August 13, 2024, the U.S. National Institute of Standards and Technology (NIST) took a decisive step toward reducing that seam risk by finalizing its first three post-quantum cryptography standards: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) as a hash-based signature fallback. That was the moment the “quantum-safe locks” became official federal standards.
But installing locks is not the same as securing a building. Most real-world “quantum upgrades” are partial, and partial upgrades have a habit of breaking in exactly one place.
“NIST standardized the locks. The market is still arguing about which doors matter.”
— — TheMurrow Editorial
What NIST actually standardized—and why it matters
NIST’s August 13, 2024 announcement matters because it marked the end of the “candidate algorithm” era for first-wave post-quantum cryptography (PQC). The agency finalized three standards, each with a specific purpose—and each aimed at public-key cryptography, the category most threatened by a large cryptographically relevant quantum computer.
The three core standards (August 13, 2024)
NIST’s first PQC standards are:
- FIPS 203 — ML-KEM, derived from CRYSTALS-Kyber, designed for key establishment / key exchange in protocols such as TLS and VPNs.
- FIPS 204 — ML-DSA, derived from CRYSTALS-Dilithium, designed for digital signatures used in certificates, code signing, document signing, and similar integrity/authentication tasks.
- FIPS 205 — SLH-DSA, derived from SPHINCS+, a stateless hash-based signature scheme intended as a conservative alternative if lattice-based signatures ever show serious weaknesses.
NIST summarized these releases as the first finalized PQC encryption standards for broad adoption, and it’s hard to overstate the practical value of that signal. Procurement teams buy standards. Auditors ask for standards. Engineers build to standards.
- FIPS 203 — ML-KEM, derived from CRYSTALS-Kyber, designed for key establishment / key exchange in protocols such as TLS and VPNs.
- FIPS 204 — ML-DSA, derived from CRYSTALS-Dilithium, designed for digital signatures used in certificates, code signing, document signing, and similar integrity/authentication tasks.
- FIPS 205 — SLH-DSA, derived from SPHINCS+, a stateless hash-based signature scheme intended as a conservative alternative if lattice-based signatures ever show serious weaknesses.
NIST summarized these releases as the first finalized PQC encryption standards for broad adoption, and it’s hard to overstate the practical value of that signal. Procurement teams buy standards. Auditors ask for standards. Engineers build to standards.
The “backup plan” for key exchange (March 11, 2025)
On March 11, 2025, NIST selected HQC as a backup key-encapsulation mechanism (KEM)—a code-based approach intended as a second line of defense if ML-KEM later shows weaknesses. NIST said a draft HQC standard is expected roughly “about a year” after selection and a final standard is expected in 2027.
That timeline is a reminder: PQC is not a one-and-done event. It’s a multi-year program with contingencies.
That timeline is a reminder: PQC is not a one-and-done event. It’s a multi-year program with contingencies.
“Post-quantum isn’t a product milestone. It’s a migration.”
— — TheMurrow Editorial
3
Finalized NIST PQC standards released on August 13, 2024: FIPS 203/204/205.
1
Additional algorithm selected as a backup KEM on March 11, 2025: HQC.
2027
Expected year for a final HQC standard, per NIST’s stated timeline.
Key statistics (with context)
Key statistics (with context):
- 3 finalized NIST PQC standards released on August 13, 2024 (FIPS 203/204/205).
- 1 additional algorithm selected as a backup KEM on March 11, 2025 (HQC).
- 2027 expected year for a final HQC standard.
- NIST’s migration playbook draft (NIST IR 8547) was published November 12, 2024, with comments closing January 10, 2025—a narrow window that underscores how quickly the transition conversation is moving.
- 3 finalized NIST PQC standards released on August 13, 2024 (FIPS 203/204/205).
- 1 additional algorithm selected as a backup KEM on March 11, 2025 (HQC).
- 2027 expected year for a final HQC standard.
- NIST’s migration playbook draft (NIST IR 8547) was published November 12, 2024, with comments closing January 10, 2025—a narrow window that underscores how quickly the transition conversation is moving.
The slippery meaning of “quantum upgrade” in the real world
“Quantum-safe,” “quantum-ready,” and “quantum upgrade” are phrases that travel well in headlines and poorly in threat models. In practice, they can describe very different changes, each with different security implications.
Hybrid key exchange: the easiest win (and the easiest to misread)
Many deployments focus on hybrid key exchange: combining a classical method such as X25519 with a PQC KEM such as ML-KEM-768 (often still referred to by its Kyber name in implementations). The idea is straightforward: the connection remains secure if either the classical or post-quantum component holds.
Cloudflare has described the operational reality clearly: you only get post-quantum protection if both ends negotiate it, and the details of the connection path matter. A user might see a post-quantum handshake to a CDN edge while the CDN-to-origin hop remains classical.
That’s not a moral failing; it’s how networks work. It is, however, how “quantum upgrade” becomes a half-truth.
Cloudflare has described the operational reality clearly: you only get post-quantum protection if both ends negotiate it, and the details of the connection path matter. A user might see a post-quantum handshake to a CDN edge while the CDN-to-origin hop remains classical.
That’s not a moral failing; it’s how networks work. It is, however, how “quantum upgrade” becomes a half-truth.
PQC signatures: harder, slower, and more consequential
Signatures are where the transition becomes politically and operationally difficult. A signature algorithm touches:
- PKI ecosystems (certificate authorities, intermediate chains, trust stores)
- Certificate formats and validation logic
- Hardware roots of trust
- Policy and compliance regimes
A vendor can deploy hybrid key exchange relatively quickly inside a controlled stack. Replacing signature infrastructure takes years, coordination, and risk tolerance.
- PKI ecosystems (certificate authorities, intermediate chains, trust stores)
- Certificate formats and validation logic
- Hardware roots of trust
- Policy and compliance regimes
A vendor can deploy hybrid key exchange relatively quickly inside a controlled stack. Replacing signature infrastructure takes years, coordination, and risk tolerance.
“Quantum-safe encryption at rest”: sometimes true, often beside the point
Some “quantum-safe at rest” claims boil down to “we use AES-256.” Symmetric cryptography is not threatened in the same way as RSA and ECC; quantum algorithms change the security margin but don’t produce the same clean break that Shor’s algorithm would imply for public-key schemes.
AES-256 hardening can be sensible. It can also distract from the core PQC migration problem: public-key encryption and signatures.
AES-256 hardening can be sensible. It can also distract from the core PQC migration problem: public-key encryption and signatures.
“If your ‘quantum upgrade’ is only a faster handshake demo, you didn’t upgrade trust—you upgraded a screenshot.”
— — TheMurrow Editorial
The seam where it all breaks: upgraded key exchange, classical authentication
The most common “one place” failure looks like progress: post-quantum confidentiality in the handshake. The missing piece is often authentication—the identity proof that tells you who you’re talking to.
The “signed by yesterday” problem
In many systems, engineers add PQC to the key exchange for protection against “harvest now, decrypt later” threats. Yet the server’s identity is still vouched for by a certificate chain signed with RSA/ECDSA/Ed25519—classical algorithms.
Net effect: you can gain post-quantum confidentiality while still relying on classical authentication. That split matters in several ways:
- Long-lived trust anchors: certificate roots and intermediate chains persist for years.
- Recorded contexts: if a transcript or artifact must be verifiable far into the future, future signature forgery risk becomes relevant.
- Audit and non-repudiation: a signature system that can be forged later undermines the value of archived signed records.
None of this implies “don’t deploy hybrid key exchange.” It means understand what you did—and what you didn’t do.
Net effect: you can gain post-quantum confidentiality while still relying on classical authentication. That split matters in several ways:
- Long-lived trust anchors: certificate roots and intermediate chains persist for years.
- Recorded contexts: if a transcript or artifact must be verifiable far into the future, future signature forgery risk becomes relevant.
- Audit and non-repudiation: a signature system that can be forged later undermines the value of archived signed records.
None of this implies “don’t deploy hybrid key exchange.” It means understand what you did—and what you didn’t do.
Multiple perspectives: pragmatism vs. purity
Security teams pushing for hybrid key exchange first are often being pragmatic. Key exchange changes can reduce exposure to future decryption of captured traffic, and they can often be rolled out with fewer governance barriers than PKI refits.
The purist critique is also valid: if the system still authenticates with classical signatures, then the upgrade can fail under threat models where identity integrity is paramount.
The responsible position sits between them: treat confidentiality and authentication as separate migration tracks, and track both explicitly.
The purist critique is also valid: if the system still authenticates with classical signatures, then the upgrade can fail under threat models where identity integrity is paramount.
The responsible position sits between them: treat confidentiality and authentication as separate migration tracks, and track both explicitly.
Key Takeaway
Hybrid key exchange can reduce “harvest now, decrypt later” risk, but it doesn’t automatically modernize authentication. Track both migration paths explicitly.
Protocol integration is where good algorithms go to die
NIST standardized algorithms. The internet runs on protocols, libraries, defaults, and compatibility choices—areas where security can degrade without anyone noticing.
“Two to tango” isn’t a metaphor; it’s an operational constraint
Cloudflare’s “two to tango” framing captures a basic fact: negotiated crypto only applies if both parties support and select it. A client can support a post-quantum hybrid handshake; the server might not. A browser-to-edge connection might be upgraded; the edge-to-origin leg might remain classical.
Even inside a single company, one team might upgrade the ingress tier while legacy services behind it continue using older stacks. The “quantum upgrade” becomes patchwork.
Even inside a single company, one team might upgrade the ingress tier while legacy services behind it continue using older stacks. The “quantum upgrade” becomes patchwork.
The last hop problem: where marketing stops and architecture begins
The last hop is rarely visible to end users. It is also where sensitive data often flows: origin requests, API calls, internal service-to-service traffic. If that segment remains classical, a sophisticated adversary doesn’t need to attack the upgraded edge link.
Practical takeaway: when a vendor or provider claims post-quantum protection “for TLS,” ask which TLS connections. Front door only, or also the hallways?
Practical takeaway: when a vendor or provider claims post-quantum protection “for TLS,” ask which TLS connections. Front door only, or also the hallways?
Key Insight
When you hear “post-quantum TLS,” demand routing clarity: client-to-edge, edge-to-origin, and internal service links are different threat surfaces.
NIST’s migration playbook: staged, deliberate, and unglamorous
While the standards got the headlines, NIST also published guidance aimed at the migration itself. NIST IR 8547 (Initial Public Draft), titled “Transition to Post-Quantum Cryptography Standards,” was published November 12, 2024, with a comment period that closed January 10, 2025.
That draft matters because it frames PQC as a program with stages: discover, prioritize, deploy, validate, and eventually retire quantum-vulnerable algorithms. The details of the draft are less important than the posture: NIST is signaling that the transition is not just a cryptographic choice; it’s a systems engineering exercise.
That draft matters because it frames PQC as a program with stages: discover, prioritize, deploy, validate, and eventually retire quantum-vulnerable algorithms. The details of the draft are less important than the posture: NIST is signaling that the transition is not just a cryptographic choice; it’s a systems engineering exercise.
What “staged transition” means for organizations
A staged migration typically implies:
- Inventory: where RSA/ECC are used (TLS, VPN, SSH, code signing, document signing, device onboarding).
- Prioritization: which use cases have long-lived confidentiality requirements vs. which require long-lived signature verifiability.
- Deployment sequencing: hybrid key exchange first where it reduces risk quickly; signature modernization as PKI ecosystems catch up.
- Validation: interoperability testing, performance benchmarking, and policy updates.
The hard part is not choosing between ML-KEM and ML-DSA. NIST already did that. The hard part is choosing which business processes must change so the cryptography can change safely.
- Inventory: where RSA/ECC are used (TLS, VPN, SSH, code signing, document signing, device onboarding).
- Prioritization: which use cases have long-lived confidentiality requirements vs. which require long-lived signature verifiability.
- Deployment sequencing: hybrid key exchange first where it reduces risk quickly; signature modernization as PKI ecosystems catch up.
- Validation: interoperability testing, performance benchmarking, and policy updates.
The hard part is not choosing between ML-KEM and ML-DSA. NIST already did that. The hard part is choosing which business processes must change so the cryptography can change safely.
A staged PQC transition (as implied by NIST’s posture)
- 1.1. Inventory where RSA/ECC live across TLS, VPN, SSH, signing, onboarding.
- 2.2. Prioritize by “confidentiality horizon” and “signature verifiability horizon.”
- 3.3. Deploy hybrid key exchange where it quickly reduces exposure.
- 4.4. Modernize signatures and PKI with longer timelines and coordination.
- 5.5. Validate interoperability, performance, and policy—then retire quantum-vulnerable algorithms.
Case studies you can recognize: CDN edges, VPNs, and the “quiet” PKI wall
Real-world examples are often less cinematic than “quantum computers will crack everything,” but more useful for decision-making.
Case study: post-quantum at the edge, classical inside
Cloudflare’s public discussions of post-quantum cryptography highlight a pattern many organizations share: upgrading the client-to-edge connection can be feasible and valuable. Yet the security story depends on the entire route, including the segment from edge to origin.
That architecture—modern perimeter, legacy interior—is common across CDNs, reverse proxies, and API gateways. A security team can truthfully say, “we deployed post-quantum hybrid TLS,” while the underlying application tier is still operating on classical assumptions.
That architecture—modern perimeter, legacy interior—is common across CDNs, reverse proxies, and API gateways. A security team can truthfully say, “we deployed post-quantum hybrid TLS,” while the underlying application tier is still operating on classical assumptions.
Case study: VPN rollout is easier than certificate ecosystem refits
VPN and tunnel technologies often control both endpoints (corporate-managed clients and gateways). That can make hybrid key establishment a manageable deployment.
By contrast, signature migrations collide with the reality of certificate lifetimes, trust stores, hardware security modules, and validation logic embedded in old devices. Some of the hardest work is not cryptographic—it’s institutional. Who owns the PKI? Who can rotate roots? Which regulators must approve?
The point isn’t pessimism. It’s specificity: “quantum upgrade” means very different things in different parts of your stack, and the hardest parts are usually the least visible.
By contrast, signature migrations collide with the reality of certificate lifetimes, trust stores, hardware security modules, and validation logic embedded in old devices. Some of the hardest work is not cryptographic—it’s institutional. Who owns the PKI? Who can rotate roots? Which regulators must approve?
The point isn’t pessimism. It’s specificity: “quantum upgrade” means very different things in different parts of your stack, and the hardest parts are usually the least visible.
Why key exchange moves faster than signatures
Before
- Hybrid key exchange in controlled stacks
- negotiated per-connection
- faster rollouts
- quick confidentiality gains
After
- Signature/PKI migration
- long-lived roots
- ecosystem coordination
- device constraints
- compliance and governance friction
What to ask before you trust a “quantum-safe” claim
Readers don’t need to become cryptographers to evaluate claims. They need a checklist that forces clarity.
A practical checklist for buyers and security teams
Ask vendors (and internal teams) questions that pin down scope:
Questions that force specificity
- ✓Which NIST standards are you using? Look for explicit references to FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) or FIPS 205 (SLH-DSA), not vague “quantum-resistant algorithms.”
- ✓Is it hybrid, and if so, what are the components? For example, X25519 plus ML-KEM-768.
- ✓Which connections are covered end-to-end? Client-to-edge only, or also edge-to-origin and internal service calls?
- ✓What about authentication? Are certificates still signed with classical algorithms? Is there a roadmap for PQC signatures?
- ✓What is the rollout and fallback plan? Compatibility failures can force downgrades; you want to know how those are detected and prevented.
What “good enough for now” can look like
A credible near-term stance often includes:
- Hybrid key exchange deployed where feasible to reduce exposure to future decryption of captured traffic.
- A parallel plan for migrating signature use cases, acknowledging longer timelines.
- Explicit acknowledgment of what remains classical.
Clarity builds trust. Ambiguity sells upgrades.
- Hybrid key exchange deployed where feasible to reduce exposure to future decryption of captured traffic.
- A parallel plan for migrating signature use cases, acknowledging longer timelines.
- Explicit acknowledgment of what remains classical.
Clarity builds trust. Ambiguity sells upgrades.
Buyer’s Filter
Credible “quantum-safe” claims name FIPS 203/204/205, describe whether the deployment is hybrid, and specify which links are protected end-to-end.
Conclusion: the future won’t break everything—only what you forgot to replace
The post-quantum transition has entered its grown-up phase. NIST’s August 13, 2024 standards—FIPS 203, 204, and 205—give the world a stable foundation. NIST’s March 11, 2025 selection of HQC as a backup KEM, with a draft expected about a year later and a final standard expected in 2027, underscores that the foundation will be reinforced over time, not swapped out overnight.
The practical risk now is less about whether lattice-based cryptography “works” and more about whether organizations can migrate without leaving one brittle dependency behind. The most common failure won’t be dramatic. It will be quiet: the upgraded key exchange paired with classical authentication, the post-quantum edge paired with a classical origin, the shiny “quantum-safe” label paired with no statement of what actually changed.
NIST has picked the locks. Security teams still have to walk the building—door by door—until there’s no single place left where the promise collapses.
The practical risk now is less about whether lattice-based cryptography “works” and more about whether organizations can migrate without leaving one brittle dependency behind. The most common failure won’t be dramatic. It will be quiet: the upgraded key exchange paired with classical authentication, the post-quantum edge paired with a classical origin, the shiny “quantum-safe” label paired with no statement of what actually changed.
NIST has picked the locks. Security teams still have to walk the building—door by door—until there’s no single place left where the promise collapses.
1) What did NIST standardize in 2024 for post-quantum cryptography?
On August 13, 2024, NIST finalized three PQC standards: FIPS 203 (ML-KEM) for key establishment (derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA) for digital signatures (derived from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA) for stateless hash-based digital signatures (derived from SPHINCS+). These target public-key cryptography use cases most vulnerable to quantum attacks.
2) What is ML-KEM used for in plain terms?
ML-KEM (FIPS 203) is meant for securely agreeing on encryption keys between two parties—commonly in protocols like TLS and VPNs. It replaces or supplements classical public-key methods that would be vulnerable to a sufficiently powerful quantum computer. In many deployments, it appears as part of a hybrid key exchange alongside a classical method.
3) Why do many “quantum upgrades” focus on TLS key exchange first?
Key exchange upgrades are often easier to deploy because they can be negotiated between endpoints and don’t always require rebuilding the entire certificate ecosystem. They also address a practical concern: captured encrypted traffic could potentially be decrypted later if classical public-key methods are broken. That said, key exchange is only part of the security story.
4) If my connection uses post-quantum key exchange, am I fully “quantum-safe”?
Not necessarily. A common gap is authentication: the server identity is frequently still proven using classical signatures in certificates (RSA/ECDSA/Ed25519). That can leave a “one place” weakness depending on your threat model, especially for long-lived trust and long-term verifiability of signed records.
5) What is SLH-DSA and why did NIST standardize it?
SLH-DSA (FIPS 205) is a stateless hash-based digital signature standard derived from SPHINCS+. NIST positioned it as a conservative alternative—often described as a backup—so organizations have an option that is structurally different from lattice-based signatures. It’s part of building resilience if a particular family of cryptographic assumptions weakens.
6) What is HQC and when will it become a standard?
NIST selected HQC on March 11, 2025 as a backup KEM (code-based), intended as a second line of defense in case ML-KEM later shows weaknesses. NIST indicated a draft standard about a year after selection and a final standard expected in 2027. HQC is not positioned as a replacement for ML-KEM today, but as a hedge.
7) What’s the most practical question to ask when a vendor claims “quantum-safe”?
Ask: “Which connections and which cryptographic functions are post-quantum?” Get specifics on whether the claim applies to key exchange, signatures, or both; whether it’s hybrid; and whether it covers only the “front door” (client-to-edge) or also internal and origin connections. A serious answer will name standards such as FIPS 203/204/205 and describe end-to-end coverage.
T
About the Author
TheMurrow Editorial is a writer for TheMurrow covering technology.
Frequently Asked Questions
What did NIST standardize in 2024 for post-quantum cryptography?
On August 13, 2024, NIST finalized three PQC standards: FIPS 203 (ML-KEM) for key establishment (derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA) for digital signatures (derived from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA) for stateless hash-based digital signatures (derived from SPHINCS+). These target public-key cryptography use cases most vulnerable to quantum attacks.
What is ML-KEM used for in plain terms?
ML-KEM (FIPS 203) is meant for securely agreeing on encryption keys between two parties—commonly in protocols like TLS and VPNs. It replaces or supplements classical public-key methods that would be vulnerable to a sufficiently powerful quantum computer. In many deployments, it appears as part of a hybrid key exchange alongside a classical method.
Why do many “quantum upgrades” focus on TLS key exchange first?
Key exchange upgrades are often easier to deploy because they can be negotiated between endpoints and don’t always require rebuilding the entire certificate ecosystem. They also address a practical concern: captured encrypted traffic could potentially be decrypted later if classical public-key methods are broken. That said, key exchange is only part of the security story.
If my connection uses post-quantum key exchange, am I fully “quantum-safe”?
Not necessarily. A common gap is authentication: the server identity is frequently still proven using classical signatures in certificates (RSA/ECDSA/Ed25519). That can leave a “one place” weakness depending on your threat model, especially for long-lived trust and long-term verifiability of signed records.
What is SLH-DSA and why did NIST standardize it?
SLH-DSA (FIPS 205) is a stateless hash-based digital signature standard derived from SPHINCS+. NIST positioned it as a conservative alternative—often described as a backup—so organizations have an option that is structurally different from lattice-based signatures. It’s part of building resilience if a particular family of cryptographic assumptions weakens.
What is HQC and when will it become a standard?
NIST selected HQC on March 11, 2025 as a backup KEM (code-based), intended as a second line of defense in case ML-KEM later shows weaknesses. NIST indicated a draft standard about a year after selection and a final standard expected in 2027. HQC is not positioned as a replacement for ML-KEM today, but as a hedge.
