What Is Post-Quantum Cryptography? The Practitioner's Guide for CISOs and Security Architects

Your organization's encrypted data is being stolen right now — not to be read today, but to be decrypted the moment a cryptographically relevant quantum computer (CRQC) comes online. Nation-state adversaries running "harvest now, decrypt later" (HNDL) operations do not need a quantum computer to collect your ciphertext; they only need one when it suits them. Meanwhile, NIST finalized its first three post-quantum cryptography standards in August 2024, and federal agencies are already under mandate to adopt them. ^[NIST] The question is no longer whether to migrate — it is whether your organization will migrate on its own terms or under crisis conditions.

Why Classical Encryption Is No Longer Enough: The Quantum Threat Explained

RSA, Elliptic Curve Cryptography (ECC), and Diffie-Hellman key exchange underpin virtually every secure digital interaction your organization conducts: SSL/TLS certificates, VPN tunnels, code-signing infrastructure, PKI hierarchies, and SSH sessions. These algorithms derive their security from mathematical problems — integer factorization and discrete logarithm — that classical computers cannot solve at scale within any practical timeframe. A sufficiently powerful quantum computer running Shor's algorithm, however, would solve both problems in polynomial time, rendering these primitives cryptographically obsolete. ^{[NIST IR 8105]}

Security architects must make a critical distinction here. Symmetric encryption — AES-256, for example — is not primarily threatened by Shor's algorithm. Grover's algorithm can theoretically halve the effective key length of a symmetric cipher, reducing AES-256 to roughly 128-bit equivalent security on a quantum computer. That remains acceptable for most use cases, and doubling key length fully compensates. ^{[NIST IR 8105]} Public-key cryptography — every asymmetric algorithm your organization uses for key exchange and digital signatures — is the existential target.

The operative word for practitioners is today. The intelligence community has formally assessed that adversaries are exfiltrating encrypted traffic with the explicit intent to decrypt it once a CRQC exists. The NSA has stated that the risk posed by quantum computing to national security systems is serious enough to require migration now, not when quantum computers arrive. ^[NSA] Any data your organization transmits or stores that must remain confidential for a decade or more is already exposed to this risk. Debating CRQC timelines is a distraction; the harvest is happening regardless of when decryption becomes possible.

What Post-Quantum Cryptography Actually Is — And What It Is Not

Three terms appear repeatedly in executive briefings and vendor materials, and conflating them is one of the most common and consequential mistakes security leaders make:

• Post-Quantum Cryptography (PQC): Classical cryptographic algorithms — running on conventional computers — built on mathematical problems believed to be resistant to both classical and quantum attacks. No quantum hardware required. This is a software and protocol upgrade path.
• Quantum Key Distribution (QKD): A physics-based key exchange mechanism that uses quantum properties of photons to detect eavesdropping. Requires specialized hardware and dedicated fiber links. QKD is not standardized for enterprise use, is operationally immature at scale, and does not replace the need for PQC. NIST explicitly notes that QKD is not a substitute for PQC. ^{[NIST CSRC]}
• Quantum Computing: The threat model. Quantum computers are not PQC; they are the reason PQC is necessary. Your organization does not need to build or operate a quantum computer to implement PQC.

PQC algorithms are grounded in mathematical hardness problems that resist known quantum attacks. The three primary families selected by NIST draw on distinct problem classes. Structured lattice problems — specifically Learning With Errors (LWE) and its variants — underpin ML-KEM (key encapsulation) and ML-DSA (digital signatures). Lattice problems are believed hard for both classical and quantum computers, and they offer excellent performance characteristics. Hash-based cryptography underpins SLH-DSA (formerly SPHINCS+), deriving security from the collision resistance of cryptographic hash functions — a well-understood and conservative assumption. Code-based problems — specifically the hardness of decoding random linear codes — underpin backup candidates currently under NIST evaluation, providing mathematical diversity against the risk of a lattice-specific breakthrough. ^{[NIST CSRC PQC Project]}

Four algorithms have been standardized or finalized by NIST: ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) for key encapsulation; ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) for digital signatures; SLH-DSA (FIPS 205, formerly SPHINCS+) for hash-based signatures; and FN-DSA (FIPS 206, formerly FALCON) for digital signatures. ^[NIST] For security architects evaluating algorithm selection, understanding the technical distinctions between ML-KEM, ML-DSA, and emerging backup standards like HQC is essential before committing to implementation choices.

The NIST Standardization Timeline: Where We Are and What Comes Next

NIST launched its Post-Quantum Cryptography Standardization Project in 2016, issuing a formal call for candidate algorithms. ^{[NIST CSRC PQC Project]} The timeline is worth understanding in detail because it represents one of the most rigorous public cryptographic evaluation processes ever conducted, and its outputs carry a level of institutional credibility that security architects can rely on when briefing boards or procurement committees.

The Standardization Timeline at a Glance

• 2016: NIST issues call for PQC algorithm submissions.
• Late 2017: 69 candidate algorithms submitted from global cryptographic research community. ^{[NIST CSRC]}
• 2019: Round 2 — field narrowed to 26 candidates.
• 2020: Round 3 — 7 finalists and alternates identified.
• 2022: Four algorithms selected: CRYSTALS-Kyber, CRYSTALS-Dilithium, SPHINCS+, and FALCON. ^[NIST]
• August 2024: FIPS 203, 204, and 205 published as finalized federal standards. FIPS 206 finalized shortly thereafter. ^[NIST]
• 2025–2026: NIST evaluating additional backup candidates, including HQC (code-based) and others, to provide mathematical diversity and reduce monoculture risk.

The monoculture concern deserves explicit attention. Three of the four finalized standards — ML-KEM, ML-DSA, and FN-DSA — rely on lattice-based mathematics. While confidence in lattice hardness is high, a fundamental breakthrough against structured lattices would be catastrophic if no alternative exists in the deployed infrastructure. NIST's evaluation of non-lattice backup candidates is a direct response to this risk. ^{[NIST CSRC Round 4]} Organizations with long-horizon security requirements — classified data, critical infrastructure, financial custody — should track backup algorithm progress actively and plan for cryptographic agility from the outset.

The Enterprise Migration Challenge: Why This Is Harder Than a Certificate Rotation

Security architects who have managed large-scale certificate migrations — SHA-1 deprecation, for instance, or TLS 1.0/1.1 sunset — will recognize the operational contours of PQC migration but should not underestimate its additional complexity. Four distinct challenges compound each other in ways that make a phased, deliberate approach essential.

Challenge 1: Cryptographic Inventory at Enterprise Scale

Most enterprise organizations cannot enumerate their cryptographic dependencies with confidence. Cryptographic primitives are embedded in TLS stacks, PKI chains, HSMs, code-signing pipelines, IoT firmware, mobile device management agents, third-party APIs, database encryption modules, and operational technology (OT) control systems — often without documentation. The concept of a Cryptographic Bill of Materials (CBOM) — a structured inventory of every cryptographic asset, algorithm, key length, and dependency — is the necessary foundation for any migration program. CISA and NIST have both recommended a CBOM-first approach as the starting point for PQC readiness. ^[CISA] Without it, organizations are migrating blind.

Challenge 2: Algorithm Performance Trade-offs

PQC algorithms carry materially larger key sizes and ciphertext sizes than their classical counterparts. ML-KEM-768 produces a public key of approximately 1,184 bytes and a ciphertext of 1,088 bytes — compared to RSA-2048's 256-byte public key. ^{[NIST FIPS 203]} ML-DSA signatures are substantially larger than ECDSA signatures. SLH-DSA signatures are dramatically larger — a trade-off for conservative security assumptions. These size increases have downstream implications for TLS handshake latency, certificate chain transmission, HSM storage capacity, bandwidth-constrained environments, and IoT devices with limited memory. Security architects must model these performance impacts before committing to algorithm choices, particularly in latency-sensitive environments such as high-frequency trading, industrial control systems, or real-time authentication pipelines.

Challenge 3: Hybrid Classical/PQC Transition Schemes

During the migration period, organizations cannot simultaneously cut over all systems to PQC. Hybrid schemes — running a PQC algorithm alongside a classical algorithm in parallel — maintain backward compatibility while providing quantum resistance for systems that support it. For example, hybrid TLS key exchange combines ML-KEM with ECDH; the session key is derived from both, so security holds as long as either algorithm remains unbroken. NIST, IETF, and major cloud providers have endorsed hybrid approaches for the transition period. ^{[NIST CSRC]} The overhead is real — doubled key exchange operations, larger handshake payloads — but for systems handling long-lived sensitive data, the HNDL exposure of deferring PQC outweighs the performance cost.

Challenge 4: Vendor Readiness Gaps

Validated PQC support across the vendor ecosystem is uneven and, in many cases, absent. As of early 2026, no FIPS 140-3 validated cryptographic module incorporating PQC algorithms has been issued by NIST's CMVP — a significant compliance gap for regulated industries. HSM vendors, cloud KMS providers, PKI certificate authorities, and enterprise VPN vendors are at varying stages of PQC roadmap development. Security architects should be formally querying vendors for PQC roadmap commitments, expected FIPS validation timelines, and hybrid scheme support during procurement and renewal cycles. OT and ICS environments present a particular edge case: many embedded controllers have decade-long replacement cycles and cannot be updated with new cryptographic primitives through a software patch. These systems require architectural planning, not just protocol configuration.

The Harvest Now, Decrypt Later Risk: How to Prioritize What to Protect First

Not all cryptographic dependencies are equally exposed. A practical risk-prioritization framework helps security leaders triage migration investment before the full CBOM is complete. The most useful model uses two dimensions: Data Sensitivity (how damaging is exposure?) and Data Longevity Requirement (how long must this data remain confidential?). Assets in the high-sensitivity, long-longevity quadrant are HNDL-exposed today and warrant immediate migration priority.

High-Priority HNDL Exposure by Sector

• Healthcare: Patient records, genomic data, longitudinal clinical trial data — often subject to decades-long retention requirements and high regulatory penalties for exposure.
• Financial Services: Transaction logs, proprietary trading algorithms, custody records, and long-duration contractual agreements — highly sensitive and subject to regulatory record-keeping mandates.
• Technology / Manufacturing: R&D data, patent filings, source code, and product design specifications — competitive IP with multi-decade value horizons.
• Government and Defense Contractors: Sensitive but unclassified (SBU) and controlled unclassified information (CUI) transmitted under government contracts — directly in scope for federal PQC mandates and adversary collection priorities. ^[NSA]

CISA, NIST, and NSA jointly published guidance in 2023 identifying the immediate preparation steps organizations should take, regardless of sector: identify all systems using RSA, ECC, DH, and ECDH; flag all data with confidentiality requirements exceeding five to ten years as HNDL-exposed; and engage vendors on PQC roadmap timelines and FIPS validation commitments. ^[CISA] For organizations operating under federal acquisition requirements, understanding the specific PQC migration obligations facing U.S. agencies in 2026 and beyond provides a useful compliance pressure benchmark even for private-sector security programs.

One additional consideration that practitioners sometimes overlook: key management infrastructure itself. The HSMs, KMS systems, and certificate authorities that protect encryption keys are often more valuable targets than the data they protect. If your key management infrastructure uses RSA or ECC for its own internal authentication — key wrapping, attestation, administrator authentication — that infrastructure must be in your HNDL exposure analysis.

Starting Your PQC Migration: A Practical First-90-Days Roadmap

The gap between PQC awareness and PQC action is where most organizations currently reside. The following roadmap gives security architects a sequenced, defensible action plan they can take into the next planning cycle. It is structured around three thirty-day phases because that cadence maps to typical sprint and budget cycles — but it is designed to generate concrete outputs, not just process activity.

Days 1–30: Cryptographic Asset Inventory

• Deploy cryptographic discovery tooling across your environment — network scanning tools capable of identifying TLS cipher suites, certificate algorithms, and key sizes in use. Commercial CBOM platforms and open-source options (e.g., CISA's SCuBA tooling for Microsoft 365 environments) exist; choose based on estate complexity.
• Enumerate all certificate authorities, PKI hierarchies, and certificate issuance pipelines. Identify root and intermediate CA key types and sizes.
• Inventory HSMs, KMS instances, and secrets management platforms. Request vendor documentation on PQC algorithm support and FIPS 140-3 roadmap commitments.
• Begin building an initial CBOM — even an incomplete version is more defensible than no inventory. Prioritize systems with external-facing TLS, code-signing infrastructure, and any system handling data in the high-sensitivity, long-longevity quadrant.

Days 31–60: Risk Tiering and Vendor Engagement

• Apply the Data Sensitivity × Data Longevity matrix to your initial CBOM. Produce a tiered risk register with explicit HNDL exposure assessments for top-tier assets.
• Identify your top ten highest-risk cryptographic dependencies — systems or data stores where HNDL exposure is highest and migration complexity is most significant.
• Issue formal vendor inquiries to all critical cryptographic infrastructure vendors: What is the PQC algorithm support roadmap? When is FIPS 140-3 validation for PQC modules expected? Is hybrid scheme support (e.g., hybrid TLS 1.3 with ML-KEM) on the product roadmap?
• Review applicable regulatory and contractual obligations. Defense contractors should assess CNSA 2.0 obligations specifically — CNSA 2.0 compliance deadlines vary materially by system type, with hard cutoffs beginning in 2027. ^[NSA]

Days 61–90: Pilot Implementation and Board Briefing

• Select one low-risk, high-visibility system for a hybrid PQC pilot — internal TLS for a developer portal, an internal API gateway, or an internal certificate issuance workflow. The goal is operational learning, not production exposure.
• Implement hybrid key exchange (classical + ML-KEM) and measure performance impact: handshake latency, packet size increases, HSM throughput changes. Document the findings quantitatively.
• Produce a board-level briefing package with three components: (1) current HNDL exposure summary from your risk register; (2) pilot findings and projected enterprise migration complexity; (3) a draft multi-year migration roadmap with resource and budget implications. NSA and CISA guidance documents provide authoritative external anchors for board presentations. ^{[CISA] [NSA]}

Federal agencies operate under mandated migration timelines with specific reporting obligations. Private-sector organizations are not legally required to match federal deadlines — yet — but those deadlines represent the most authoritative public benchmark for what "responsible migration pace" looks like. Regulated industries including financial services, healthcare, and critical infrastructure should treat federal agency timelines as a leading indicator of their own coming compliance horizon.

Key Takeaways

• The threat is present-tense. Harvest now, decrypt later attacks are active. Any data requiring long-term confidentiality is already at risk, regardless of when a CRQC becomes operational.
• PQC is not quantum computing or QKD. It is classical cryptography built on quantum-resistant mathematical problems — a software and protocol upgrade, not a hardware rip-and-replace.
• NIST has finalized four standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and FN-DSA (FIPS 206). Backup non-lattice candidates are under active evaluation to address mathematical monoculture risk.
• Cryptographic inventory is the critical first step. Without a CBOM, migration planning is speculative. Deploy discovery tooling and begin inventory immediately.
• Performance trade-offs are real and measurable. ML-KEM and ML-DSA carry larger key and ciphertext sizes than RSA and ECDSA. Pilot implementations in your specific environment before committing to enterprise-wide algorithm choices.
• Vendor readiness gaps are significant. No FIPS 140-3 validated PQC module exists as of early 2026. Query all critical vendors for roadmap commitments during procurement and renewal cycles.
• Hybrid schemes are the transition path. Running PQC alongside classical algorithms maintains compatibility while eliminating HNDL exposure for upgraded systems.
• Cryptographic agility is the long-term architecture goal. Design systems to swap cryptographic primitives without full re-architecture — this protects against future algorithm compromises, not just the current quantum threat.

This article draws on primary documentation from NIST (FIPS 203, FIPS 204, FIPS 205, FIPS 206, NIST IR 8105, and the NIST CSRC PQC Project), NSA Post-Quantum Cybersecurity Resources and CNSA 2.0 advisory, CISA Quantum Cybersecurity guidance, and the EU PQC Roadmap (June 2025). All claims verified against official sources as of March 2026.

Related Reading

• Harvest Now, Decrypt Later: Why Every Month of Delay Is an Irreversible Security Decision — Deep-dive analysis of the HNDL threat model and why adversaries are collecting your encrypted traffic today.
• FIPS 203, 204, and HQC Explained: What Security Architects Need to Know — Technical breakdown of ML-KEM, ML-DSA, and the HQC backup standard for architects making algorithm selection decisions.
• Lattice-Based Cryptography for Security Architects: Standards, Performance, and Migration Architecture — Practitioner-focused guide to the mathematical foundations of FIPS 203 and 204, including performance benchmarks and migration architecture patterns.
• FIPS 140-3 and PQC: Why No Validated Module Exists Yet and What Compliance Teams Must Do Now — Analysis of the CMVP validation gap and actionable steps for compliance teams operating in the interim period.
• CNSA 2.0 Compliance Deadlines by System Type: The Complete Deadline Matrix — System-specific hard cutoffs for government and defense contractors, from 2027 through 2033.
• Federal PQC Migration Deadlines: What Agencies Actually Face in 2026 and Beyond — Authoritative breakdown of real federal agency PQC obligations, including CMVP cutoffs and NSS requirements.

IMPORTANT: Every Related Reading title is a working hyperlink using the actual article URL from the published articles list.