Post-Quantum Cryptography and Quantum Readiness

Key Control Areas

• Cryptographic Inventory and Discovery (CM-08, PM-05, SA-04): Maintain a complete Cryptographic Bill of Materials (CBOM) covering all X.509 certificates, TLS configurations, VPN transforms, SSH key types, key management systems, data-at-rest encryption, code signing, firmware signing, and application-level cryptography. Use automated discovery across network traffic, host configurations, source code, and cloud services. CycloneDX supports CBOM as a standard capability. Without a complete inventory, systematic migration is impossible — you cannot migrate what you cannot find.
• Crypto Agility Architecture (SC-13, SA-08, SA-17): Design abstraction layers between applications and cryptographic implementations. Applications call generic operations (sign, encrypt, key-exchange) with algorithm selection driven by policy configuration, not hard-coded in source. Protocol negotiation (TLS 1.3 cipher suites, IKEv2 transforms, SSH key exchange) already supports this model. Extend to application-layer cryptography, KMS integration, and certificate management. Eliminate hard-coded algorithm choices, proprietary fixed-cipher protocols, and non-upgradeable firmware crypto.
• Post-Quantum Key Exchange (SC-12, SC-13, SC-08): Deploy hybrid key exchange combining classical (X25519/P-256) with PQC (ML-KEM-768) on all TLS, SSH, VPN, and IPsec endpoints. Hybrid mode ensures that both algorithms must be broken to compromise the session — protecting against both classical and quantum attacks during the transition. OpenSSH 10.0 already defaults to ML-KEM hybrid. Browser support (Chrome, Firefox, Edge) covers approximately 38% of HTTPS traffic via X25519MLKEM768. Enable on load balancers and API gateways immediately.
• Post-Quantum Digital Signatures and PKI (SC-13, SC-17, IA-05): Migrate certificate infrastructure to support hybrid and composite certificates containing both classical and PQC signatures. ML-DSA-65 is the primary signature algorithm; SLH-DSA provides a conservative hash-based backup. IETF LAMPS working group is standardising composite certificate formats. Re-sign long-lived digital signatures (contracts, regulatory filings, archival documents) with PQC algorithms before CRQCs arrive. Note: PQC certificates are significantly larger — an ML-DSA-65 chain adds approximately 10KB versus 1.5KB for ECDSA.
• HSM and Key Management Migration (SC-12, AC-06): Upgrade hardware security modules to PQC-capable models with FIPS 140-3 Level 3 validation. Migrate key wrapping from RSA/ECDH to ML-KEM. Ensure all data-at-rest encryption uses AES-256 minimum (AES-128 provides only 64-bit post-quantum security via Grover's algorithm). Centralised KMS must support PQC key types for generation, storage, and distribution without requiring application changes.
• Code and Firmware Signing (SI-07, CM-14): Implement dual-signing with classical and PQC signatures on all firmware, software artifacts, and boot chains. NIST SP 800-208 approves LMS/XMSS (stateful hash-based schemes) for code signing now — these are already quantum-safe. CNSA 2.0 mandates dual-signing of firmware immediately. Hardware root of trust (secure boot) must support firmware-upgradeable crypto modules.
• Supply Chain Cryptographic Assurance (SR-03, SR-04, SR-05, SA-04): Assess vendor PQC roadmaps covering algorithm support timelines, hybrid mode capability, FIPS 140-3 validation scope, firmware upgradeability, and CBOM availability. Require PQC support in all new procurement contracts. Embedded devices and OT/ICS systems with non-upgradeable crypto are the highest-risk supply chain element — compensating controls (network segmentation, crypto gateways) may be required for systems that will never support PQC.
• Migration Planning and Governance (PL-02, PM-01, CP-02): Execute phased migration aligned with regulatory timelines: Phase 1 (now to 2028) — inventory, discovery, planning; Phase 2 (2025-2031) — hybrid key exchange, SSH migration, firmware dual-signing, HSM upgrades; Phase 3 (2031-2035) — complete PKI migration, retire quantum-vulnerable algorithms. Apply the Mosher equation: if data shelf life plus migration time exceeds time until CRQCs, the data is already at risk. Maintain contingency plans for premature algorithm compromise — deploy algorithms from different mathematical families (lattice, hash-based, code-based) to avoid single-point cryptographic failure.
• Monitoring, Compliance, and Algorithm Diversity (CA-07, AU-06, SC-13): Continuously monitor cryptographic algorithm deployment across the estate. Track migration progress against CNSA 2.0, NCSC, and BSI timelines. Verify that hybrid mode is active on all external-facing endpoints. Maintain algorithm diversity — deploy ML-KEM alongside SLH-DSA and future HQC (code-based backup, expected 2027) to ensure resilience against breakthrough attacks on any single mathematical family.

When to Use

Any organisation handling data with long-term confidentiality requirements (government, financial services, healthcare, legal, IP-intensive industries). Organisations subject to CNSA 2.0 (US government contractors, defense), NCSC guidance (UK regulated entities), or BSI recommendations (German/EU regulated entities). Organisations operating critical infrastructure with long equipment lifecycles.

When NOT to Use

Organisations with exclusively short-lived data and no regulatory cryptographic requirements may defer migration planning, though crypto agility investment still provides value against classical algorithm compromises. Organisations with no asymmetric cryptography usage (extremely rare).

Typical Challenges

Incomplete cryptographic inventory across a heterogeneous estate. Hard-coded algorithm choices in legacy applications. OT/ICS and embedded systems with non-upgradeable firmware and 15-30 year lifecycles. HSM vendors not yet achieving combined FIPS 140-3 Level 3 with PQC algorithm validation. Larger PQC key and signature sizes impacting constrained devices, certificate transparency logs, and bandwidth-limited channels. Multi-jurisdictional regulatory requirements (CNSA 2.0, NCSC, BSI, ETSI) with differing algorithm preferences and timelines. Fewer than 5% of enterprises currently have a formal quantum-transition plan.

Threat Resistance

Addresses the Harvest Now Decrypt Later threat by deploying hybrid PQC key exchange on all encrypted channels. Protects against CRQC emergence through phased algorithm migration. Crypto agility architecture provides resilience against both quantum and classical algorithm compromises. Algorithm diversity (lattice + hash-based + code-based) prevents single-point cryptographic failure. Supply chain assurance prevents migration being blocked by vendor dependencies.

Assumptions

The organisation uses standard cryptographic protocols (TLS, SSH, IPsec) and has a PKI infrastructure. Hardware security modules are in use for key management. The organisation has data with confidentiality requirements exceeding 10 years. Symmetric encryption (AES) is already deployed for data at rest.

Developing Areas

• NIST PQC standards are finalised (FIPS 203/204/205) but the migration ecosystem remains immature. HSM vendors are still working toward combined FIPS 140-3 Level 3 validation with PQC algorithm support, certificate authorities are piloting hybrid certificates without production SLA commitments, and TLS library support varies across implementations. The gap between standard availability and production-ready tooling means that organisations starting migration in 2026 face significant integration engineering that will diminish as the ecosystem matures over 2-3 years.
• Hybrid certificates combining classical and PQC signatures are the recommended transitional approach but introduce practical challenges. An ML-DSA-65 certificate chain adds approximately 10KB compared to 1.5KB for ECDSA, impacting TLS handshake latency, certificate transparency log storage, and bandwidth-constrained channels. The IETF LAMPS working group is still finalising composite certificate formats, meaning early adopters face potential format changes. Negotiation of hybrid versus classical-only connections adds protocol complexity that load balancers and API gateways must handle correctly.
• Crypto agility in legacy systems is the hardest practical migration challenge. Many enterprise applications have hard-coded algorithm choices, use proprietary cryptographic libraries, or depend on middleware that does not support PQC algorithms. The CBOM (Cryptographic Bill of Materials) concept is sound but discovery tooling is immature -- automated scanning covers network protocols well but misses application-layer cryptography, data-at-rest encryption configurations, and embedded firmware crypto. Fewer than 5% of enterprises have completed a comprehensive cryptographic inventory.
• Harvest-now-decrypt-later (HNDL) threat urgency assessment is contested among practitioners. The timeline to cryptographically relevant quantum computers (CRQCs) remains uncertain, with estimates ranging from 10 to 30+ years. Organisations with long-lived sensitive data (government classified, patient records, trade secrets) face immediate HNDL risk, while those with shorter data sensitivity windows must balance migration investment against uncertain threat timelines. The Mosher equation (data shelf life + migration time versus time to CRQC) provides a framework but depends on unknowable inputs.
• PQC performance impact on constrained devices -- IoT sensors, embedded controllers, smartcards, and mobile devices -- is a significant deployment concern. ML-KEM key encapsulation is computationally efficient, but ML-DSA signature verification requires substantially more processing and memory than ECDSA. Devices with limited compute budgets may need hardware upgrades or alternative lightweight PQC schemes (currently under NIST evaluation as additional standards) that are not yet standardised. This creates a multi-year gap where constrained device populations cannot participate in PQC migration.