{"data":{"id":"SP-040","slug":"post-quantum-cryptography","title":"Post-Quantum Cryptography and Quantum Readiness","description":"Architecture pattern for migrating enterprise cryptographic infrastructure to post-quantum algorithms. Covers crypto agility, cryptographic inventory (CBOM), hybrid key exchange, PQC certificate migration, HSM readiness, and phased migration planning aligned with NIST FIPS 203/204/205, CNSA 2.0, and NCSC timelines. Addresses the Harvest Now Decrypt Later threat and the structural challenge of migrating cryptography across an enterprise estate with 10-15 year equipment lifecycles.","url":"https://www.opensecurityarchitecture.org/patterns/sp-040","metadata":{"release":"26.02","classification":"Cryptography and Key Management","status":"active","type":"pattern","datePublished":"2026-02-09","dateModified":"2026-02-09","authors":["Aurelius","Vitruvius"],"reviewers":[],"provenance":"Tobias Christen (Aurelius) built post-quantum security expertise at Migros from 2023, winning the DigiCert Award for Quantum Readiness. This pattern captures the architectural approach to enterprise PQC migration, emphasising crypto agility as an investment protection that pays off even without Q-Day."},"diagram":{"svg":"/images/sp-040-post-quantum-cryptography.svg","png":""},"content":{"description":"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.\n\nThe 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.\n\nCrypto 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.\n\nThis 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.","keyControlAreas":["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."],"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.","typicalChallenges":"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.","indications":"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.","contraIndications":"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).","threatResistance":"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."},"examples":{"Financial Services PQC Migration":["Phase 1: Cryptographic inventory across trading platforms, payment systems, and client-facing portals using automated discovery and CBOM generation","Phase 2: Enable X25519MLKEM768 hybrid key exchange on all external TLS endpoints (API gateways, web portals, partner connections)","Phase 3: Migrate internal PKI to hybrid certificates, upgrade HSMs to PQC-capable models, dual-sign all firmware","Phase 4: Retire classical-only algorithms, re-sign regulatory archival documents with ML-DSA"],"Government/Defence (CNSA 2.0 Compliance)":["ML-KEM-1024 and ML-DSA-87 for all National Security Systems (Level 5 security)","Dual-signing all firmware and software artifacts immediately","All new equipment acquisitions CNSA 2.0 compliant by January 2027","Complete migration of all NSS by 2035 per NSM-10"],"Healthcare with Long-Lived Patient Data":["HIPAA-mandated patient confidentiality extends for decades — HNDL threat is immediate","Priority: encrypt all patient data channels with hybrid TLS, migrate EHR system key wrapping to ML-KEM","Medical device firmware requires PQC consideration — many devices have 10-15 year lifecycles","CBOM inventory of all medical device cryptographic capabilities before next procurement cycle"],"Enterprise with Crypto Agility Focus (Migros Model)":["Build crypto agility as investment protection — benefits accrue before Q-Day through faster incident response and compliance","Centralise cryptographic configuration management — policy-driven algorithm selection across the estate","Retain control over cryptographic configurations across all vendor products","Use DigiCert/Keyfactor/Venafi for automated certificate lifecycle management with PQC readiness tracking"],"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."]},"references":[{"title":"NIST FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism)","url":"https://csrc.nist.gov/pubs/fips/203/final","note":"The primary PQC standard for key exchange, based on CRYSTALS-Kyber. Finalised August 2024."},{"title":"NIST FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm)","url":"https://csrc.nist.gov/pubs/fips/204/final","note":"The primary PQC standard for digital signatures, based on CRYSTALS-Dilithium. Finalised August 2024."},{"title":"NIST FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)","url":"https://csrc.nist.gov/pubs/fips/205/final","note":"Conservative hash-based signature backup, based on SPHINCS+. For high-assurance scenarios where lattice assumptions are not acceptable."},{"title":"NIST IR 8547 — Transition to Post-Quantum Cryptography Standards","url":"https://csrc.nist.gov/pubs/ir/8547/ipd","note":"Sets the deprecation timeline: RSA/ECDSA deprecated after 2030, disallowed after 2035."},{"title":"NSA CNSA 2.0 Algorithm Suite","url":"https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF","note":"US government algorithm suite and migration timeline for National Security Systems."},{"title":"NCSC Post-Quantum Cryptography Migration Timelines","url":"https://www.ncsc.gov.uk/guidance/pqc-migration-timelines","note":"UK three-phase migration timeline: discover (to 2028), execute (2028-2031), complete (2031-2035)."},{"title":"BSI Migration to Post-Quantum Cryptography","url":"https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Crypto/Migration_to_Post_Quantum_Cryptography.pdf","note":"German BSI guidance favouring hybrid approaches and algorithm diversity including FrodoKEM."},{"title":"NIST SP 800-208 — Stateful Hash-Based Signature Schemes","url":"https://csrc.nist.gov/pubs/sp/800/208/final","note":"Approves LMS/XMSS for code and firmware signing now — already quantum-safe."},{"title":"CycloneDX CBOM Capability","url":"https://cyclonedx.org/capabilities/cbom/","note":"Standard format for Cryptographic Bill of Materials within the OWASP CycloneDX SBOM framework."},{"title":"PKI Consortium PQC Capabilities Matrix","url":"https://pkic.org/pqccm/","note":"Tracks vendor PQC readiness across CA software, HSMs, libraries, and tools."}],"relatedPatterns":["SP-032","SP-033","SP-039","SP-029"],"relatedPatternNames":["Modern Authentication","Passkey Authentication","Client-Side Encryption and Data Privacy","Zero Trust Architecture"],"threats":[{"id":"T-40-001","name":"Harvest Now Decrypt Later (HNDL) — Nation-state adversaries archive encrypted traffic for future quantum decryption, exposing data with long-term confidentiality requirements","mitigatedBy":["SC-08","SC-12","SC-13"]},{"id":"T-40-002","name":"Cryptographically Relevant Quantum Computer (CRQC) emergence — Shor's algorithm breaks RSA, ECDSA, ECDH, EdDSA, DH, rendering all classical asymmetric cryptography obsolete","mitigatedBy":["SC-12","SC-13","SC-17"]},{"id":"T-40-003","name":"Incomplete cryptographic inventory — Unknown algorithm usage across the estate prevents systematic migration, leaving quantum-vulnerable endpoints undiscovered","mitigatedBy":["CM-08","PM-05","SA-04"]},{"id":"T-40-004","name":"Hard-coded cryptography — Applications with algorithm choices embedded in source code resist agile migration, creating persistent quantum-vulnerable endpoints","mitigatedBy":["SA-08","SA-17","SC-13"]},{"id":"T-40-005","name":"Supply chain cryptographic dependency — Vendor products using quantum-vulnerable algorithms with no firmware upgrade path, blocking migration of dependent systems","mitigatedBy":["SR-03","SR-04","SR-05","SA-04"]},{"id":"T-40-006","name":"Legacy system stranding — OT/ICS and embedded systems with 15-30 year lifecycles and non-upgradeable firmware that cannot support PQC algorithms","mitigatedBy":["SR-03","SC-07","CP-02"]},{"id":"T-40-007","name":"Certificate infrastructure disruption — PKI unable to issue, distribute, or validate PQC or hybrid certificates, breaking authentication chains during migration","mitigatedBy":["SC-17","IA-05","SC-12"]},{"id":"T-40-008","name":"Signature forgery and non-repudiation loss — Quantum computers forge digital signatures on contracts, code, firmware, and regulatory filings, undermining legal and operational trust","mitigatedBy":["SI-07","CM-14","SC-13"]},{"id":"T-40-009","name":"Premature PQC algorithm compromise — A selected algorithm (e.g., lattice-based) is cryptanalytically broken before migration completes, requiring emergency fallback to alternative mathematical families","mitigatedBy":["SC-13","CP-02","SA-08"]},{"id":"T-40-010","name":"Migration window exhaustion — Data shelf life plus migration time exceeds time until CRQCs (Mosher equation: X+Y > Z), meaning sensitive data is already irrecoverably exposed","mitigatedBy":["PL-02","PM-01","SC-08"]},{"id":"T-40-011","name":"Performance degradation from PQC overhead — Larger key sizes, signature sizes, and handshake payloads degrade performance on constrained devices, high-throughput systems, and bandwidth-limited channels","mitigatedBy":["SA-08","SC-13","CA-07"]},{"id":"T-40-012","name":"Regulatory non-compliance — Failure to meet CNSA 2.0, NIST IR 8547, NCSC, or BSI PQC migration deadlines, resulting in loss of operating authority, contract disqualification, or regulatory sanction","mitigatedBy":["PL-02","CA-07","PM-14"]}],"controls":[{"id":"SC-12","name":"Cryptographic Key Establishment and Management","family":"SC","emphasis":"critical"},{"id":"SC-13","name":"Cryptographic Protection","family":"SC","emphasis":"critical"},{"id":"SC-17","name":"Public Key Infrastructure Certificates","family":"SC","emphasis":"critical"},{"id":"CM-08","name":"System Component Inventory","family":"CM","emphasis":"critical"},{"id":"SC-08","name":"Transmission Confidentiality and Integrity","family":"SC","emphasis":"critical"},{"id":"SI-07","name":"Software, Firmware, and Information Integrity","family":"SI","emphasis":"critical"},{"id":"SA-08","name":"Security and Privacy Engineering Principles","family":"SA","emphasis":"important"},{"id":"SA-17","name":"Developer Security and Privacy Architecture and Design","family":"SA","emphasis":"important"},{"id":"SA-04","name":"Acquisition Process","family":"SA","emphasis":"important"},{"id":"SR-03","name":"Supply Chain Controls and Processes","family":"SR","emphasis":"important"},{"id":"SR-04","name":"Provenance","family":"SR","emphasis":"important"},{"id":"SR-05","name":"Acquisition Strategies, Tools, and Methods","family":"SR","emphasis":"important"},{"id":"IA-05","name":"Authenticator Management","family":"IA","emphasis":"important"},{"id":"SC-28","name":"Protection of Information at Rest","family":"SC","emphasis":"important"},{"id":"CM-14","name":"Signed Components","family":"CM","emphasis":"important"},{"id":"PL-02","name":"System Security and Privacy Plans","family":"PL","emphasis":"important"},{"id":"CP-02","name":"Contingency Plan","family":"CP","emphasis":"important"},{"id":"CA-07","name":"Continuous Monitoring","family":"CA","emphasis":"important"},{"id":"PM-05","name":"System Inventory","family":"PM","emphasis":"important"},{"id":"PM-01","name":"Information Security Program Plan","family":"PM","emphasis":"standard"},{"id":"PM-14","name":"Testing, Training, and Monitoring","family":"PM","emphasis":"standard"},{"id":"AU-06","name":"Audit Record Review, Analysis, and Reporting","family":"AU","emphasis":"standard"},{"id":"AC-03","name":"Access Enforcement","family":"AC","emphasis":"standard"},{"id":"AC-06","name":"Least Privilege","family":"AC","emphasis":"standard"},{"id":"SC-07","name":"Boundary Protection","family":"SC","emphasis":"standard"},{"id":"SC-23","name":"Session Authenticity","family":"SC","emphasis":"standard"}],"controlFamilySummary":{"SC":7,"CM":2,"SA":3,"SR":3,"SI":1,"IA":1,"PL":1,"CP":1,"CA":1,"PM":3,"AU":1,"AC":2}}}