← Patterns / SP-040

Machine-readable: Markdown JSON API guide

Post-Quantum Cryptography and Quantum Readiness

Post-quantum cryptography (PQC) is the replacement of quantum-vulnerable asymmetric algorithms (RSA, ECDSA, ECDH, EdDSA, DH) with algorithms resistant to attack by cryptographically relevant quantum computers (CRQCs). NIST finalised three PQC standards in August 2024: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a conservative hash-based signature backup. The migration is not a simple algorithm swap. Enterprise cryptography is embedded across TLS endpoints, VPN concentrators, PKI infrastructure, SSH configurations, code signing pipelines, HSMs, key management systems, data-at-rest encryption, IoT devices, and OT/ICS systems with 15-30 year lifecycles. The Harvest Now Decrypt Later (HNDL) threat means nation-state adversaries are already archiving encrypted traffic for future quantum decryption, making the migration urgent for any data with long-term confidentiality requirements. Crypto agility — the ability to swap algorithms without major rearchitecture — is the prerequisite capability. Organisations that invest in crypto agility now gain immediate benefits: faster response to algorithm compromises, easier compliance with evolving standards, and reduced technical debt. The PQC migration is the forcing function, but crypto agility is the enduring architectural improvement. This pattern defines a phased migration architecture aligned with CNSA 2.0 (US), NCSC (UK), BSI (Germany), and ETSI (EU) timelines, targeting complete migration by 2035. It covers cryptographic inventory and discovery, hybrid transitional deployments, PKI migration, supply chain assurance, and contingency planning for algorithm compromise.
Release: 26.02 Authors: Aurelius, Vitruvius Updated: 2026-02-09
Assess
ATT&CK This pattern addresses 445 techniques across 13 tactics View on ATT&CK Matrix →
POST-QUANTUM CRYPTOGRAPHY MIGRATION ARCHITECTURE PL-02 | PM-01 PM-05 PM-14 | CA-07 | CP-02 | AU-06 | SR-03 SR-04 SR-05 HARVEST NOW, DECRYPT LATER Nation-state adversaries archiving encrypted traffic T-40-001 · T-40-010 intercepts PHASE 1: DISCOVER · INVENTORY · PLAN Now → 2028 Cryptographic Bill of Materials X.509 certs · TLS configs VPN · SSH · KMS · HSMs Code signing · Data-at-rest CM-08 PM-05 Migration Risk Assessment If X + Y > Z, data already at risk X = data shelf life Y = migration time Z = time to CRQC SA-04 PL-02 REGULATORY TIMELINES CNSA 2.0 2027 2035 NIST IR 8547 Deprecate 2030 Disallow 2035 NCSC (UK) 2028 2031 2035 BSI (DE) Hybrid now FrodoKEM alt Phase: Urgent Execute Complete Discover CRYPTO AGILITY ABSTRACTION LAYER Policy-driven algorithm selection · No hard-coded crypto · Protocol negotiation · Abstracted KMS integration The architectural prerequisite — benefits accrue before Q-Day SC-13 SA-08 SA-17 PHASE 2: HYBRID TRANSITION · 2025–2031 Hybrid Key Exchange TLS 1.3: X25519MLKEM768 SSH: sntrup761x25519 → ML-KEM IPsec/IKEv2: hybrid transforms ~38% HTTPS traffic covered SC-12 SC-13 SC-08 HSM and Key Management FIPS 140-3 Level 3 PQC validation Key wrapping: RSA/ECDH → ML-KEM AES-256 minimum (Grover mitigation) Centralised PQC key type support SC-12 AC-06 SC-28 Code and Firmware Dual-Signing Classical + PQC signatures on all artifacts · LMS/XMSS (NIST SP 800-208) already quantum-safe Secure boot root of trust · Firmware-upgradeable crypto modules · CNSA 2.0 mandates now SI-07 CM-14 PHASE 3: PQC TARGET STATE · 2031–2035 PQC PKI Infrastructure Composite certificates: ML-DSA + ECDSA SLH-DSA hash-based backup Re-sign archival documents +10KB cert size (vs 1.5KB ECDSA) SC-17 IA-05 SC-13 Algorithm Diversity Lattice: ML-KEM, ML-DSA (primary) Hash: SLH-DSA, LMS/XMSS (backup) Code: HQC (expected 2027) No single-point cryptographic failure SC-13 CP-02 Classical Algorithm Retirement RSA, ECDSA, ECDH, EdDSA, DH → DEPRECATED by 2030 → DISALLOWED by 2035 (NIST IR 8547) Quantum-only algorithms required for all National Security Systems · AES-128 provides only 64-bit post-quantum security migrate SUPPLY CHAIN ASSURANCE Vendor PQC Roadmap Assessment: • Algorithm support timelines • Hybrid mode and FIPS 140-3 scope • Firmware upgradeability and CBOM • OT/ICS compensating controls (segmentation) SR-03 SR-04 SR-05 SC-07 NIST PQC STANDARDS (Aug 2024) FIPS 203 ML-KEM Key Encapsulation FIPS 204 ML-DSA Digital Signatures FIPS 205 SLH-DSA Hash-Based Backup Based on: CRYSTALS-Kyber · CRYSTALS-Dilithium · SPHINCS+ CONTINUOUS MONITORING Migration Progress Tracking: • Algorithm deployment coverage • Hybrid mode verification (external endpoints) • CNSA 2.0 / NCSC / BSI timeline compliance • Algorithm diversity audit (lattice + hash + code) CA-07 AU-06 SC-13 NIST 800-53 Rev 5 CONTROL MAPPINGS — 26 Controls Across 12 Families SC-07 SC-08 SC-12 SC-13 SC-17 SC-23 SC-28 | SR-03 SR-04 SR-05 | SA-04 SA-08 SA-17 PM-01 PM-05 PM-14 | CM-08 CM-14 | AC-03 AC-06 | CP-02 | IA-05 | AU-06 | CA-07 | SI-07 | PL-02 SP-040: Post-Quantum Cryptography 26 controls across 12 families · Authors: Vitruvius, Aurelius · Active · 2026-02-07 opensecurityarchitecture.org FIPS 203 ML-KEM · FIPS 204 ML-DSA · FIPS 205 SLH-DSA · NIST IR 8547 · CNSA 2.0 · NCSC PQC Timelines · CBOM · BSI PQC Guidance

Click any control badge to view its details. Download SVG

Key Control Areas

Cryptographic Inventory and Discovery

CM-08PM-05SA-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-13SA-08SA-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-12SC-13SC-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-13SC-17IA-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-12AC-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-07CM-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-03SR-04SR-05SA-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-02PM-01CP-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-07AU-06SC-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.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.

SP-032 Modern Authentication SP-033 Passkey Authentication SP-039 Client-Side Encryption and Data Privacy SP-029 Zero Trust Architecture
SC: 7CM: 2SA: 3SR: 3SI: 1IA: 1PL: 1CP: 1CA: 1PM: 3AU: 1AC: 2
SC-12 Cryptographic Key Establishment and Management
SC-13 Cryptographic Protection
SC-17 Public Key Infrastructure Certificates
CM-08 System Component Inventory
SC-08 Transmission Confidentiality and Integrity
SI-07 Software, Firmware, and Information Integrity
SA-08 Security and Privacy Engineering Principles
SA-17 Developer Security and Privacy Architecture and Design
SA-04 Acquisition Process
SR-03 Supply Chain Controls and Processes
SR-04 Provenance
SR-05 Acquisition Strategies, Tools, and Methods
IA-05 Authenticator Management
SC-28 Protection of Information at Rest
CM-14 Signed Components
PL-02 System Security and Privacy Plans
CP-02 Contingency Plan
CA-07 Continuous Monitoring
PM-05 System Inventory
PM-01 Information Security Program Plan
PM-14 Testing, Training, and Monitoring
AU-06 Audit Record Review, Analysis, and Reporting
AC-03 Access Enforcement
AC-06 Least Privilege
SC-07 Boundary Protection
SC-23 Session Authenticity

References