Sign in Subscribe
compliance

What Quantum-Safe Security Actually Requires: A Compliance and Architecture Framework for CISOs

Federal agencies operating under National Security Memorandum 10 are already required to inventory cryptographic usage and prioritize harvest-vulnerable systems for migration. For regulated private-sector organisations - financial services, healthcare, critical infrastructure - the window between current state and credible compliance against emerging mandates is narrowing. NIST finalised FIPS 203, FIPS 204, and FIPS 205 in August 2024.[NIST CSRC] Organisations that have not begun structured migration planning are not early - they are behind the pace that 2028 compliance expectations require.

The Regulatory Baseline Has Been Set - Here Is What It Covers

NIST's post-quantum cryptography standardisation programme produced four algorithms across three finalised Federal Information Processing Standards. ML-KEM (FIPS 203) covers key encapsulation; ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) cover digital signatures.[NIST Post-Quantum Cryptography] FN-DSA (Falcon), the fourth selected algorithm, is proceeding through standardisation as FIPS 206. These are not guidance documents - they are the standards against which FIPS-compliant products will be validated.

Supporting technical guidance is maturing in parallel. NIST SP 800-227, currently in draft, provides recommendations for key-establishment schemes using the finalised standards.[NIST SP 800-227 draft] SP 800-208 addresses stateful hash-based signature schemes. At the international level, ETSI's Quantum Safe Cryptography work programme has produced technical specifications including ETSI TS 103 744, and ISO/IEC 23837-1 addresses security requirements for quantum-safe key establishment.[ETSI Quantum Safe Cryptography] RFC 9794 documents hybrid key exchange combining classical and post-quantum mechanisms.[RFC 9794]

CISA has published quantum readiness guidance establishing baseline expectations for critical infrastructure operators, and is required to publish a qualified PQC-capable product inventory from which federal agencies must procure.[CISA Quantum Readiness] For CISOs outside the federal perimeter, that list also functions as a de facto approved-vendor reference when building procurement criteria. Security architects evaluating FIPS 140-3 validation status for PQC modules should note that no validated modules for the new standards existed as of early 2026 - a procurement constraint with direct compliance implications.

Harvest-Now-Decrypt-Later Reframes Migration as a Present-Tense Data Protection Problem

The adversarial threat model relevant to PQC planning does not require a cryptographically relevant quantum computer to be operational today. Adversaries collecting ciphertext now and decrypting it once capable hardware exists represent a risk that begins at the moment of data capture, not at the moment of decryption. Any organisation holding data with 10-, 20-, or 30-year confidentiality requirements - classified government data, patient health records, financial transaction histories, intellectual property with long commercial windows - carries exposure that begins now.[CISA Quantum Readiness]

This reframes the migration timeline question. The question is not when a capable quantum computer will exist. The question is how long your most sensitive data must remain confidential and whether that window extends beyond the point at which classical asymmetric cryptography may no longer provide adequate protection. For detailed analysis of which data classifications carry the highest immediate exposure, the harvest-now threat model and its sector implications warrant direct review.

What PQC Migration Actually Requires - Four Operational Pillars

PQC migration is not a configuration change or a library update applied uniformly. It requires sustained operational work across four distinct areas.

1. Cryptographic Asset Inventory

Before any migration decision can be made, every system, protocol, certificate, and data store relying on RSA, ECC, or Diffie-Hellman key exchange must be identified and catalogued. Federal agency CIOs and CISOs are mandated under NSM-10 to complete this inventory and prioritise harvest-vulnerable systems.[NSM-10] Private-sector organisations have no equivalent binding directive in most jurisdictions, but absent this inventory, no risk-based migration prioritisation is possible. A structured cryptographic bill of materials (CBOM) provides the persistent asset register that supports both initial migration planning and ongoing crypto agility.

2. Prioritisation by Exposure Window

Once inventoried, assets should be triaged by data sensitivity and confidentiality window. Systems protecting data that must remain confidential beyond 2030 should be flagged as harvest-vulnerable and elevated to the highest-priority migration queue. This triage is not a one-time exercise - it must be maintained as the asset landscape evolves.

3. Crypto-Agility Architecture

Crypto agility - the architectural capability to swap cryptographic algorithms without operational outages or full system re-engineering - is a prerequisite for sustainable PQC migration rather than a one-time transition. NIST's NCCoE PQC migration project explicitly identifies crypto agility as a design principle for migration architecture.[NIST Post-Quantum Cryptography] Organisations that have not built agility into their cryptographic layer will face repeated re-engineering costs as standards evolve and additional algorithms are validated.

4. Hybrid Classical/PQC Deployment

RFC 9794 documents hybrid key exchange as a transitional mechanism, combining classical and post-quantum algorithms so that security degrades to classical strength if either component fails - rather than to zero.[RFC 9794] AWS supports hybrid post-quantum TLS in production, providing a real-world deployment reference for hybrid architecture at scale.[AWS Post-Quantum Cryptography] For constrained environments - IoT devices, legacy embedded systems - hybrid deployment may be the only viable path given compute and bandwidth limitations.

Performance and Interoperability Constraints Security Architects Must Account For

ML-KEM, ML-DSA, SLH-DSA, and FN-DSA all carry larger key and signature sizes than their classical counterparts. ML-KEM-768 public keys are approximately 1,184 bytes; ML-DSA-65 signatures exceed 3,000 bytes.[FIPS 203] These sizes affect TLS handshake overhead, certificate chain validation time, and bandwidth budgets - particularly in high-throughput environments and constrained network paths.

SLH-DSA (SPHINCS+) offers conservative security assumptions based on hash functions, but its signature sizes are substantially larger than lattice-based alternatives and verification is slower - a relevant trade-off in time-sensitive authentication flows.[FIPS 205] FN-DSA (Falcon) offers smaller signatures than ML-DSA but carries implementation complexity and floating-point arithmetic requirements that introduce side-channel risk if not correctly implemented. Architects should benchmark against their specific workloads - published NIST performance data provides reference figures but does not substitute for environment-specific testing.

Interoperability testing across vendor implementations has not yet reached the maturity of classical algorithm ecosystems. Protocol-level support for the new standards is progressing - TLS 1.3 hybrid extensions are documented - but organisations integrating across heterogeneous vendor environments should build explicit interoperability validation into migration planning.

Elevating PQC Risk Into Enterprise Risk Language

For CISOs presenting PQC to boards and executive teams, the framing that lands is enterprise risk, not cryptographic engineering. Specific vectors to address:

M&A due diligence: Acquiring an organisation with unmigrated cryptographic infrastructure means inheriting both the migration liability and the harvest exposure on any data that organisation has been protecting with classical asymmetric cryptography. Acquirers should now include cryptographic posture assessment in technical due diligence checklists.

Supply chain and vendor assessment: CISA's qualified PQC-capable product inventory, once published, will provide a federal procurement reference. Private-sector procurement teams can use it as a baseline filter when evaluating cryptographic product and service vendors. Vendors unable to demonstrate a credible PQC migration roadmap for their products represent a forward liability in any multi-year technology relationship.

Insurance and liability: Cyber insurance underwriters are beginning to ask about quantum readiness posture in renewal questionnaires. The framing is currently immature, but organisations without documented migration plans carry a position of greater exposure if insurers treat PQC readiness as a coverage factor in future policy years.

ERM integration: PQC migration should be entered into enterprise risk registers with a defined owner, documented risk appetite position, and milestone-based tracking. A risk register entry with no migration milestones attached is a documentation exercise, not a risk management activity. Security architects building the compliance case will find the sequenced PQC compliance roadmap mapped to CMVP cutoffs and CNSA 2.0 mandates a useful reference for milestone alignment.

Migration Sequencing: Where to Start and How to Prioritise the 2025-2028 Window

The 2025-2028 period represents the orderly migration window before regulated sector compliance expectations crystallise. Organisations starting now have sufficient time to execute a structured programme. Those still in contemplation mode are compressing the available runway for a process - cryptographic discovery, algorithm replacement, performance validation, supply chain coordination - that NIST's NCCoE project characterises as taking years, not months.[NIST Post-Quantum Cryptography]

Sequencing priorities, based on practitioner consensus and NIST NCCoE migration guidance:

  • Inventory first. No prioritisation is possible without a complete cryptographic asset map. Automated discovery tooling accelerates this for large environments.
  • Triage by confidentiality window. Systems protecting long-lived sensitive data migrate first, regardless of business unit or system age.
  • Pilot hybrid deployment. Validate ML-KEM and ML-DSA in hybrid mode on non-critical systems before production rollout. This surfaces interoperability and performance issues at manageable cost.
  • Build internal capability. PQC-competent cryptographic engineering is a scarce skill. Organisations depending entirely on external expertise face vendor availability constraints as demand increases across the sector.
  • Align vendor roadmaps. Any technology vendor whose roadmap does not include PQC migration milestones represents a dependency risk. Contractual migration commitments should be sought at renewal.

The concrete next action: within the next 90 days, conduct a cryptographic asset inventory using automated discovery tooling or a structured manual audit. Tag every identified asset by data sensitivity level and confidentiality window. Any system protecting data that must remain confidential beyond 2030 should be flagged as harvest-vulnerable and elevated to the highest-priority PQC migration queue. Cross-reference your inventory output against the CISA quantum readiness guidance at cisa.gov/quantum to validate prioritisation criteria against the federal baseline.

Key Takeaways

  • NIST FIPS 203, 204, and 205 are finalised. These are the standards against which compliant products will be validated - not draft guidance.
  • Federal agency CIOs and CISOs are mandated under NSM-10 to inventory cryptographic usage and prioritise harvest-vulnerable systems. Private-sector regulated organisations face analogous expectations without a binding directive equivalent.
  • CISA is required to publish a qualified PQC-capable product inventory; federal agencies must procure from that list. Private-sector procurement teams should treat it as a de facto approved-vendor reference.
  • Harvest-now-decrypt-later risk begins at data capture. Organisations holding data with confidentiality requirements extending beyond 2030 carry present-tense exposure, not future-state risk.
  • PQC migration requires four operational pillars: cryptographic asset inventory, prioritisation by exposure window, crypto-agility architecture, and hybrid classical/PQC deployment for constrained environments.
  • Larger key and signature sizes in ML-KEM, ML-DSA, SLH-DSA, and FN-DSA carry measurable overhead in TLS handshakes, certificate validation, and bandwidth - performance testing against specific workloads is not optional.
  • The 2025-2028 window is the orderly migration corridor. Organisations compressing this window are accumulating structural risk that does not resolve through later acceleration.

On this site:

Primary sources:

This article draws on primary documentation from NIST CSRC (FIPS 203, 204, 205; SP 800-227 draft), CISA quantum readiness guidance, NSM-10, RFC 9794, ETSI quantum safe cryptography technical specifications, and AWS post-quantum cryptography deployment documentation. All claims verified against official sources as of April 2026.

Disclaimer: This content is for informational purposes only and does not constitute legal, regulatory, or compliance advice. Consult a qualified professional before making compliance decisions. pqcinformation.com is independent and not affiliated with any vendor or standards body.

Read next