Post-quantum cryptography readiness quantum threats 2026

Security Intelligence

Post-Quantum Cryptography Readiness & Quantum Threats — Where Enterprise Programmes Stand

PublishedJune 7, 2026

Read time8 min read

Originally reported viaNIST FIPS 203 (ML-KEM) · NIST FIPS 204 (ML-DSA) · NSA Commercial National Security Algorithm Suite 2.0 · NCSC Post-Quantum Cryptography Migration Guidance

NIST published its final post-quantum cryptography standards — FIPS 203 (ML-KEM/CRYSTALS-Kyber for key encapsulation) and FIPS 204 (ML-DSA/CRYSTALS-Dilithium for digital signatures) — in August 2024. Twenty-two months later, a Furix assessment of 200 enterprise security programmes found 78% had completed a cryptographic inventory for fewer than 25% of their systems, and only 11% had piloted ML-KEM in any production traffic flow. The migration gap is widening.

Why this is a 2026 problem, not a 2030 problem

The driving threat is harvest-now-decrypt-later (HNDL): nation-state actors are systematically collecting encrypted traffic — VPN sessions, TLS-protected API calls, email in transit — with the explicit intent to decrypt it once cryptographically relevant quantum computers are available. The NSA's CNSA 2.0 guidance assumes adversaries are collecting now. Data with a sensitivity lifetime exceeding 5–10 years — defence contracts, pharmaceutical R&D, M&A communications, health records — is already at risk.

Source: NSA Commercial National Security Algorithm Suite 2.0 — 2022, updated 2025

NSA mandates that National Security Systems transition to CNSA 2.0 algorithms (ML-KEM, ML-DSA, SLH-DSA) for all new products by 2026 and for legacy systems by 2030. The intelligence community's implicit assumption is that adversaries are already conducting HNDL operations at scale.

Where to start: a practical migration sequence

Step one is cryptographic inventory — the prerequisite for everything that follows. Tools such as Cryptosense Analyzer, Entrust PKI Spotlight, and open-source solutions like crypto-detector can scan codebases, TLS configurations, and certificate stores. Step two is triage by data sensitivity and longevity: TLS protecting financial transactions processed and forgotten has lower HNDL exposure than TLS protecting long-lived health records or IP. Step three is piloting hybrid TLS (X25519MLKEM768 key exchange) in non-production traffic flows to measure performance impact before committing to production rollout.

Source: NCSC Post-Quantum Cryptography Migration Guidance — 2025

The UK's NCSC recommends organisations prioritise migration for: (1) systems protecting data with confidentiality requirements exceeding 10 years; (2) firmware and hardware with long replacement cycles that cannot be easily patched; and (3) public key infrastructure (PKI) — root CAs and intermediate CAs have the longest lead times and must be migrated before dependent systems.

Complete a cryptographic inventory covering TLS configurations, SSH keys, code-signing certificates, VPN endpoints, and application-layer crypto libraries.
Identify your highest-HNDL-risk data flows: systems protecting data with 10+ year sensitivity requirements should be migrated first.
Test ML-KEM (CRYSTALS-Kyber) in a hybrid TLS configuration on a non-production traffic flow and benchmark performance against classical RSA/ECC.
Include PQC readiness requirements in vendor security assessments and software procurement criteria.
Engage your PKI vendor on post-quantum certificate roadmap — root CA migration has a 12–24 month lead time.