Standards baseline. Hybrid posture. Structural pitfalls.

NIST's August 2024 finalization of FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) closes the period of algorithm uncertainty and opens the period of migration engineering. The three standards divide cleanly by function and by conservative-design posture.

FIPS 203 standardizes ML-KEM in three parameter sets (ML-KEM-512, -768, -1024) mapping to NIST security levels 1, 3, and 5. CNSA 2.0 mandates ML-KEM-1024 for National Security Systems. FIPS 204 standardizes ML-DSA in three parameter sets (ML-DSA-44, -65, -87); CNSA 2.0 mandates ML-DSA-87 for NSS. FIPS 205 standardizes SLH-DSA — stateless and hash-based — whose security depends entirely on hash function security, making it the preferred conservative alternative for root CA signing and long-lived trust anchors where algorithm diversity matters.

Key operational fact: ML-DSA-87 signatures reach 4,595 bytes — approximately 18× the size of an RSA-2048 signature — and this size delta is the root cause of the MTU, PKI chain, and firewall compatibility problems that dominate early deployment experience. SLH-DSA signatures are larger still (7,856+ bytes at the small parameter set), which is the cost paid for the conservative-design assumption.

Hybrid key exchange — combining a classical KEM (typically X25519 or P-256) with ML-KEM in a parallel construction — is the correct initial deployment posture for two independent reasons. First, it provides a security floor: an attacker must break both the classical and the post-quantum components independently to compromise the session key, which means a hybrid scheme is at least as secure as its stronger component regardless of whether a CRQC materializes on the expected timeline. Second, it maintains interoperability with endpoints and intermediaries that do not yet support the NIST algorithms. The IETF draft for ML-KEM in TLS 1.3 formalizes this hybrid group construct for the most widely deployed transport protocol.

The critical architectural discipline is to treat hybrid as a time-bounded transitional state, not a permanent posture. Define an explicit sunset condition for the classical component — tied either to vendor support milestones or to confirmed interoperability of PQC-native deployments across all controlled endpoints. Failure to plan the hybrid-to-native transition produces permanent doubled overhead, continued classical exposure on every session, and a perverse incentive for the operations team to skip the second migration.

For signatures, the hybrid model is messier. Dual-cert approaches (parallel classical and PQC certificates issued by independent CAs) and composite-cert approaches (single certificate containing both signatures) are both under active IETF discussion, with neither yet the unambiguous standard. Architect for the certificate lifecycle — issuance, revocation, OCSP — not just the verification step.

Sunset conditions to define explicitly

• Vendor milestone trigger. Specific product family X reaches PQC-native default — sunset begins on the next quarterly review cycle.
• Endpoint coverage trigger. N% of controlled endpoints (clients, intermediaries, CA infrastructure) confirm PQC-native support — sunset begins on a defined date.
• Standards trigger. IETF moves the relevant draft to standards track and one major vendor implementation lands.
• Operational regression trigger. Hybrid overhead exceeds defined latency or throughput budget on a measured workload — sunset becomes mandatory.

Four problems require explicit design attention in any PQC migration architecture. Each is documented in IETF working-group output, NIST CSWP 39, or both. Each maps to a design rule that should appear in your architecture review checklist.

Pitfall 01 — Algorithm negotiation downgrade

If cipher-suite negotiation is not integrity-protected before it influences key establishment, an active man-in-the-middle can force classical-only selection, stripping the hybrid's PQC protection entirely. This is not theoretical — the IETF's TLS hybrid design documents identify it as a known design constraint. Design rule: require cipher-suite negotiation logging in production, and confirm that integrity protection covers the negotiation step before the key share is computed.

Pitfall 02 — KDF composition correctness

Hybrid schemes must combine the outputs of both KEMs through a cryptographically sound combiner function. A naive concatenation without proper domain separation may allow the composite key to inherit the weakness of either component under adversarial conditions. Design rule: use standardized combiners from IETF drafts and reviewed library implementations. Do not roll your own combiner. Confirm the combiner has been reviewed against the active-adversary threat model, not just the passive one.

Pitfall 03 — Crypto-agility scope collapse

NIST CSWP 39 defines six agility dimensions — algorithm selection, key management, hardware capability, certificate lifecycle, protocol negotiation, and vendor contracts. Reducing agility to algorithm choice while leaving key management and hardware capability unaddressed creates a migration that appears complete but fails during enforcement: the new algorithm runs, but the HSM cannot rotate keys, or the CA cannot issue the new certificate type, or the procurement contract does not require the vendor to ship a future algorithm update. Design rule: the migration plan addresses all six dimensions, not just the cipher-suite list.

Pitfall 04 — The CBOM is not a living artifact

The Cryptographic Bill of Materials (CBOM) must be a living artifact, not a one-time inventory snapshot. Libraries, firmware, and managed services update independently, and PQC support at the TLS termination layer does not imply PQC support in the HSM, the CI/CD signing pipeline, or the identity federation layer. Each layer requires independent verification and a distinct migration path aligned to the phased CNSA 2.0 timeline. Design rule: the CBOM is under change control with a quarterly review cycle, and the review cycle is enforced by a calendar item with a named owner, not by intention.