Post-Quantum Cryptography for Security Architects: Standards, Migration Paths, and Decision Points

Four NIST standards were finalised in August 2024. They do not tell you which one to deploy first, which protocol represents the fastest migration path in your environment, or whether hybrid schemes are a destination or a waypoint. Those are the actual decisions sitting on security architects' desks in 2026, and the FIPS documents are specifications, not migration plans.

This article works through the current state of PQC standardisation, the Harvest Now Decrypt Later risk arithmetic that makes this an immediate rather than a future concern, the hybrid versus pure PQC question, where each major protocol sits on the migration curve as of mid-2026, and the three misconceptions that consistently produce rework. For parameter set specifications and algorithm definitions, see the NIST FIPS 203, 204, and 205 reference article.

What Was Standardised and What Is Still Moving

NIST published four standards in August 2024: ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism, FIPS 203), ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204), SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205), and FN-DSA (FIPS 206). These are the implementation targets. They are not the final word on the PQC landscape.

NIST's Round 4 candidates, BIKE and HQC, both code-based KEMs, remain under evaluation and may yield additional KEM standards. A separate NIST project evaluating additional digital signature schemes is ongoing. Organisations building cryptographic architectures on the assumption that FIPS 203/204/205/206 represent the complete and final standard set are building architecture that will need revisiting. Build for cryptographic agility as the architectural property: the ability to swap algorithm implementations at configuration cost, not engineering cost.

One important note on terminology: use the FIPS designations throughout. ML-KEM replaces Kyber. ML-DSA replaces Dilithium. SLH-DSA replaces SPHINCS+. FN-DSA replaces FALCON. The pre-standardisation names still appear in library documentation and vendor materials; in your architecture documentation and procurement specifications, use the FIPS names exclusively.

HNDL and the Mosca Inequality: Why the Clock Is Running Now

Harvest Now Decrypt Later (HNDL) is the adversarial strategy of capturing encrypted traffic today and decrypting it once a CRQC becomes available. The data captured in 2024 and 2025 will be readable if a cryptographically relevant quantum computer (CRQC) arrives within its sensitivity window. The NSA and NCSC have both published explicit statements that HNDL represents a current threat justifying present-tense migration action (NSA CNSA 2.0, September 2022; UK NCSC, "Post-Quantum Cryptography: preparing your organisation").

The Mosca inequality gives this a formal structure. If t_m (your migration lead time) plus t_s (your data sensitivity horizon) exceeds t_q (time until a CRQC exists), your organisation is already exposed. The inequality is asymmetric in an important way: t_m is within your control; t_q is not.

Work the numbers concretely. A large enterprise PQC migration typically takes three to five years from cryptographic inventory completion through hybrid deployment to full algorithm cut-over, based on published programme durations and NCSC guidance. The Global Risk Institute's 2024 Quantum Threat Timeline Report puts non-negligible CRQC probability within 15 years (Mosca and Piani, Global Risk Institute, 2024). For an organisation holding data with a 15-year sensitivity horizon, such as long-term healthcare records, financial contracts, or classified material, t_m of four years plus t_s of fifteen years exceeds t_q of fifteen years. The inequality is already failing (Mosca, M., IEEE Security and Privacy, 2018).

The GRI timeline is a probability distribution, not a point estimate. The argument is not "a CRQC will exist by 2034." The argument is: if your data sensitivity horizon overlaps with any reasonable CRQC probability window, and your migration lead time is measured in years rather than months, the risk exposure is present now. For organisations with short-retention, low-sensitivity data, the calculation may look different. Do the arithmetic explicitly rather than defaulting to "it's theoretical."

Hybrid Versus Pure PQC: What the IETF Actually Specifies

A hybrid key exchange combines a classical algorithm with a post-quantum algorithm in a single handshake, deriving the session key from both shared secrets. The security rationale: an attacker must break both algorithms simultaneously to recover the session key. The classical component protects against current adversaries during the transition period; the post-quantum component protects against future CRQCs. If ML-KEM is later found to have a flaw, the classical component provides a backstop (Stebila and Sullivan, "Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange," IACR ePrint, 2018).

The IETF has specified hybrid schemes for the major protocols. For TLS 1.3, IETF draft-ietf-tls-ecdhe-mlkem-04 specifies ML-KEM hybrid key exchange using X25519MLKEM768 as the primary hybrid named group. For X.509 and PKI, IETF draft-ietf-lamps-pq-composite-sigs specifies composite post-quantum signatures for PKIX certificate profiles. Both Google and Cloudflare ran large-scale hybrid TLS deployments using pre-standard lattice algorithms before FIPS 203 was finalised. Cloudflare's production deployments of hybrid ML-KEM have shown sub-millisecond TLS handshake overhead in reported measurements. Tunnel throughput after the handshake was unaffected.

Hybrid is a transitional deployment pattern. The IETF specifications do not present hybrid as the end state. NSA CNSA 2.0 (applicable to US national security systems, widely adopted as a transition reference) targets pure ML-KEM-1024 and ML-DSA-87 for national security systems by 2030. Planning hybrid as a permanent architecture creates technical debt that will need unwinding when IR 8547 is finalised and the deprecated classical components face regulatory pressure. The clean architecture question is not "should we deploy hybrid?" but "what is our timeline for sunsetting the classical component?" (NSA CNSA 2.0, September 2022; NIST IR 8547 Initial Public Draft, November 2024).

Where Each Protocol Sits on the Migration Curve (Mid-2026)

For the use-case-to-standard decision matrix and CMVP gate details for each of these protocols, the FIPS 203/204/205 Implementation Decision Map covers algorithm sequencing by asset class. The table above covers state; that article covers sequencing. Note: IETF I-D version numbers (draft-ietf-tls-ecdhe-mlkem-04, draft-ietf-tls-mlkem-07, draft-ietf-lamps-pq-composite-sigs) should be verified against IETF Datatracker at publication date and updated if later revisions are available.

Architecture-First Versus Algorithm-First

Both arguments are correct for different contexts, and treating them as mutually exclusive is an error.

The architecture-first argument: build cryptographic agility into your protocol stacks now, so that as the PQC algorithm landscape expands through Round 4 and additional signature schemes, absorbing new standards is a configuration change rather than a re-engineering project. NIST CSWP 29 (Initial Public Draft, June 2024) provides the clearest published framing of cryptographic agility as an architectural property. For greenfield systems and systems undergoing significant refactoring, architecture-first is the durable approach.

The algorithm-first argument: HNDL risk is present now for long-retention data. Waiting for architectural completeness before starting migration means continuing to accumulate exposure. For systems with high HNDL exposure, key infrastructure, and long-retention data, starting the ML-KEM migration in parallel with architectural work is the right answer, not a precondition for it. The cryptographic inventory is the prerequisite for both tracks. An organisation that does not know which systems use RSA-2048 key exchange, where X.509 certificates are issued and consumed, or which protocols use ECDSA for signing cannot sequence either approach. Start there. The cryptographic inventory guide covers the methodology (NIST SP 1800-38D, NCCoE, 2024).

The ENISA Post-Quantum Cryptography Integration Study (2021) and NCSC guidance provide the most detailed non-US government analysis of integration paths across X.509, TLS, S/MIME, and SSH. Both are relevant for organisations operating under NIS2 or GDPR (ENISA, "Post-Quantum Cryptography: Integration Study," 2021; NCSC PQC guidance collection).

Three Misconceptions That Produce Rework

"Quantum is far off, so PQC migration is theoretical." This confuses CRQC availability with HNDL risk. HNDL risk is present now. Intelligence services and nation-state adversaries with collection capability and motivation are not waiting for a CRQC to exist before storing encrypted traffic. The data being captured today has a sensitivity window. If that window overlaps with any plausible CRQC timeline, migration is not theoretical. The NCSC and NSA have both stated this explicitly. The misconception costs organisations the lead time they need.

"ML-KEM is just bigger RSA." ML-KEM is a key encapsulation mechanism built on the Module Learning With Errors hardness assumption. RSA-OAEP is an asymmetric encryption scheme built on integer factorisation. The interfaces are structurally different. ML-KEM generates a shared secret and a ciphertext that the recipient decapsulates; RSA-OAEP directly encrypts data or a content encryption key. Code that calls RSA-OAEP cannot substitute ML-KEM without modifying the key management and CMS wrapping logic. The primitive class, the hardness assumption, the interface, and the implementation path are all different (NIST FIPS 203, Section 2, August 2024). "Bigger RSA" is not a useful mental model for any of these dimensions.

"Hybrid is forever." Hybrid schemes are specified as transitional. The additional key material, larger handshake size, and CPU overhead of hybrid are justified during the period when PQC implementations are new and interoperability gaps exist. They are not justified once classical algorithms are deprecated and implementations have matured. CNSA 2.0 targets pure ML-KEM-1024 and ML-DSA-87 for national security systems by 2030. Planning hybrid as a permanent architecture creates technical debt that will require engineering work to unwind once regulatory pressure to remove deprecated classical components arrives. Plan the sunset now, not as a future problem (NSA CNSA 2.0, September 2022).

The 2025 to 2030 Planning Window

Security architects making decisions now are working within a five-year window where the major events are: the progression of IETF I-Ds to RFCs for TLS and PKIX; the maturation of FIPS 140-3 validated modules for ML-KEM and ML-DSA; the finalisation of NIST IR 8547 (currently at Initial Public Draft stage); and the CNSA 2.0 operational transitions required from 2027 onwards for national security systems. Planning that treats any of these as fixed points rather than probability distributions is planning that will require adjustment. Build for adaptability alongside urgency.

To map the decision criteria in this article against your own environment, the PQC Readiness Checklist provides a structured self-assessment. QSECDEF members have access to practitioner-level implementation guides covering the full migration lifecycle, updated as the standards evolve.