Post-Quantum Cryptography in 2026: ML-KEM, HQC, and How to Check a Quantum-Safe Claim

Bottom line

If a product page says it is quantum-safe in 2026, the useful question is not whether quantum computers are scary. The useful question is narrower: which NIST-recognized algorithm is used, where is it used, and can the deployment be checked in technical documentation?

NIST’s post-quantum cryptography work separates several ideas that often get compressed into one marketing phrase. ML-KEM, ML-DSA, and SLH-DSA are standardized post-quantum algorithms. HQC is different: NIST selected it for standardization as an additional post-quantum encryption algorithm with a backup KEM role, not as an immediate replacement standard for ML-KEM.

Treat 2026 as a current-state checkpoint, not a hard deadline. The label quantum-safe, post-quantum ready, or PQC enabled is only the start. The evidence is in the algorithm name, protocol location, hybrid deployment, fallback behavior, and documentation trail.

What happened

NIST has been standardizing cryptographic algorithms designed to resist attacks from future cryptographically relevant quantum computers. For readers evaluating systems now, the first split is between standardized algorithms, algorithms selected for future standardization, and vendor claims about deployment.

Category	Examples	What to check in 2026
Standardized post-quantum algorithms	ML-KEM, ML-DSA, SLH-DSA	Whether the product or protocol actually implements the named standard.
Selected for additional standardization	HQC	Whether it is presented as a backup KEM, not as a current drop-in replacement standard for ML-KEM.
Vendor or service claim	quantum-safe, post-quantum ready	Whether the claim is tied to protocol location, configuration, documentation, and fallback behavior.

Post-quantum cryptography is not a single product feature. It touches key establishment, signatures, certificates, protocol negotiation, software libraries, operational policy, and migration planning.

Evidence level

For standards status and migration framing, the main reference points are NIST’s official post-quantum cryptography project, the NIST NCCoE migration FAQ, and NIST’s announcement that HQC was selected as an additional post-quantum encryption algorithm.

That source mix supports the distinction between standardized algorithms, selected algorithms, and migration planning. It does not prove that any specific commercial product is correctly implemented, fast enough, interoperable, or safely configured by default. Product-level conclusions require current vendor documentation, configuration evidence, and testing.

NIST NCCoE’s migration framing also moves the problem away from a simple instruction to turn on a new algorithm. The first task is to know where cryptography is used, which systems depend on long-lived confidentiality, and which trust relationships would be difficult to change later.

Key terms

Post-quantum cryptography, or PQC, means cryptographic algorithms intended to run on conventional computers while resisting attacks from future quantum computers. It does not mean cryptography that requires a quantum computer to operate.

KEM, or key encapsulation mechanism, is a way to establish a shared secret over an insecure channel. ML-KEM and HQC should be read in that key-establishment context.

ML-KEM is a NIST-standardized key-establishment algorithm. If a service says it supports ML-KEM, the next question is where it appears in the protocol and whether administrators can verify that it is active.

ML-DSA and SLH-DSA are post-quantum signature algorithms. They address a different problem than a KEM. A claim that treats key exchange and digital signatures as one interchangeable feature should be read carefully.

HQC is a KEM that NIST selected for additional standardization. In NIST’s public materials, its significance is algorithm diversity and backup planning, not a statement that every ML-KEM deployment should be replaced by HQC.

How to check a quantum-safe claim

Start with the algorithm name. A credible claim should say whether it uses ML-KEM, ML-DSA, SLH-DSA, HQC, or something else. If the wording stops at next-generation encryption or quantum-ready security, it is too vague for engineering or procurement review.

Then find the protocol location. Is post-quantum cryptography used in TLS key exchange, a VPN connection, code signing, certificate issuance, authentication, stored-data protection, or some internal service-to-service path? A broad claim that the whole service is quantum-safe can hide a very narrow deployment.

Ask whether the deployment is hybrid. Many migration discussions involve combining existing classical cryptography with post-quantum mechanisms during transition. NIST’s standards and migration materials do not evaluate any vendor’s hybrid implementation quality, but you can still ask what combination is used and where it is documented.

Check fallback behavior. If post-quantum negotiation fails, does the connection fail closed, fall back to classical cryptography, or follow an administrator-defined policy? That answer affects security, reliability, and auditability.

Finally, look for documentation that can be reproduced by someone outside the sales conversation. Stronger evidence includes algorithm names, versions, configuration options, protocol diagrams, limitations, and an observable state in logs, admin consoles, or test output.

Practical checklist

Checkpoint	Better signal	Weak signal
Algorithm status	Names the NIST standard or selected-for-standardization status.	Uses broad phrases such as next-generation encryption.
Deployment location	Identifies TLS, VPN, signatures, certificates, or another specific layer.	Says the entire service is quantum-safe without scope.
Hybrid mode	Explains the classical and PQC combination.	Does not say whether hybrid deployment is used.
Fallback behavior	Documents what happens when PQC negotiation fails.	Leaves readers guessing whether the system silently falls back.
Documentation	Provides configuration, limitations, versions, and auditable state.	Relies on a blog post or sales sheet only.
Inventory fit	Can be mapped to assets in a cryptographic inventory.	Cannot be connected to the systems it protects.

Use the checklist to separate a real implementation claim from a broad security label. It is not a product ranking.

What changes if the claim is real

A genuine post-quantum deployment changes more than the wording on a security page. Network teams need to understand protocol negotiation and operational impact. Application teams need to know which libraries and certificate flows are involved. Procurement and security teams need requirements that mention algorithm status, deployment scope, documentation, and fallback behavior.

The first concrete artifact is a cryptographic inventory. Without a map of where public-key cryptography is used, which data needs long-term confidentiality, and which external connections depend on current cryptographic assumptions, algorithm names alone do not produce a migration plan.

The second change is vendor evaluation. A useful request for information should ask for the algorithm, protocol location, hybrid mode, configuration controls, fallback behavior, and documentation. A one-line quantum-safe claim should not be treated as enough.

The third change is training. Internal explanations that repeat quantum computers will break encryption do not prepare teams for implementation decisions. Teams need to distinguish key establishment from signatures, standards from selected algorithms, and deployed mechanisms from backup candidates.

What remains uncertain

NIST’s standards and migration materials do not validate any specific vendor’s implementation quality, performance, interoperability, default configuration, or operational maturity. Those questions need current product documentation and, where the deployment matters, testing in the relevant environment.

HQC’s selection also does not mean the post-quantum transition is complete. Standardization status, protocol adoption, library support, operational tooling, and enterprise migration plans can move at different speeds.

The phrase quantum-safe remains imprecise unless it names an attack model, data lifetime, system boundary, and deployed mechanism. A system can use a post-quantum algorithm in one place while leaving other cryptographic dependencies unchanged.

What to watch next

Track four things. First, updates from the NIST post-quantum cryptography project on standards and selected algorithms. Second, NIST NCCoE migration material on cryptographic inventory and risk management.

Third, watch how major protocols, libraries, and cloud services document ML-KEM or other standardized algorithms in specific deployment locations. Fourth, follow how HQC’s backup KEM role develops through the standardization process.

For any near-term buying, architecture, or migration conversation, keep the review grounded in five checks: standard status, protocol location, hybrid mode, fallback behavior, and auditable documentation.