CNSA 2.0 Suite Implementation: A Detailed Walkthrough

The CNSA 2.0 compliance guide for US defence contractors covers what contractors must do and by when. The preferred dates for software and firmware signing (2025) and network equipment (2026) have either passed or are current. This article covers the implementation problem: how to deploy ML-KEM-1024 and ML-DSA-87 correctly across the range of protocol contexts in an NSS-connected system, where FIPS 140-3 validation requirements gate deployment, and what sequencing gets organisations to compliance without rework.

One naming point before starting: the September 2022 CNSA 2.0 advisory used pre-standardisation names. CRYSTALS-Kyber1024 is now ML-KEM-1024 (FIPS 203, August 2024). CRYSTALS-Dilithium5 is now ML-DSA-87 (FIPS 204, August 2024). Any procurement specification, STIG compliance document, or System Security Plan that still references "Kyber" or "Dilithium" should be updated. References to Kyber1024 in existing contracts should be interpreted as ML-KEM-1024 and corrected when the contract is renewed or modified.

The Parameter Mandate: Why Category 5 and What It Means in Bytes

The general NIST PQC recommendation targets NIST security category 3: ML-KEM-768 and ML-DSA-65. CNSA 2.0 requires category 5 for NSS. These are not interchangeable. Category 3 targets security equivalent to 192-bit classical, which is NIST's general-enterprise recommendation. Category 5 targets security equivalent to AES-256 exhaustive search, which is NSA's requirement for systems handling classified information.

For key establishment, the mandate is ML-KEM-1024 (FIPS 203 parameter set III). Wire format: encapsulation key (public key) 1,568 bytes; decapsulation key (private key) 3,168 bytes; ciphertext 1,568 bytes; shared secret output 32 bytes. [VERIFIED from NIST FIPS 203, August 2024, Table 2]

For digital signatures, the mandate is ML-DSA-87 (FIPS 204 parameter set III). Wire format: verification key (public key) 2,592 bytes; signing key (private key) 4,896 bytes; signature 4,627 bytes. [VERIFIED from NIST FIPS 204, August 2024, Table 2]

For comparison: ML-DSA-65 (the general-enterprise parameter set) produces 3,309-byte signatures. The move from category 3 to category 5 adds approximately 40% to signature size. For code signing and firmware signing, that overhead is a one-time cost per artefact. For a 10 MB firmware image, a 4,627-byte ML-DSA-87 signature represents a 0.04% overhead. For systems signing thousands of small telemetry records per second, the overhead should be benchmarked against the CNSA 2.0 compliance requirement.

Hybrid Deployment: TLS and IKEv2/IPsec

The hybrid transition mechanism is the central practical implementation work. NSA acknowledges hybrid key establishment during the transition period: classical algorithms provide security while classical computers are the only attack platform; post-quantum algorithms provide security against a future CRQC. The hybrid combines both, and both must be unbroken for the session to be compromised.

The correct NSS hybrid is P-384 + ML-KEM-1024. The common internet hybrid (X25519 + ML-KEM-768) is wrong for NSS on two counts: X25519 is not in CNSA 1.0, and ML-KEM-768 is category 3, not category 5. The classical component of an NSS hybrid must come from CNSA 1.0, which means P-384. The PQC component must meet the category 5 requirement, which means ML-KEM-1024.

For IKEv2/IPsec: RFC 9370 (Multiple Key Exchanges in IKEv2, published May 2023) provides the chained key exchange mechanism. For NSS VPNs, the configuration is DH Group 20 (P-384) for the primary IKEv2 key exchange, plus ML-KEM-1024 as an additional key exchange (ADDKE) in the SA_INIT exchange. [VERIFIED from RFC 9370, IETF, May 2023, https://www.rfc-editor.org/rfc/rfc9370]

Software and Firmware Signing

Software and firmware signing carries the earliest CNSA 2.0 preference date: 2025. That date has passed. Contractors who have not begun the code signing migration are behind the NSA's stated preferred schedule.

The deployment approach during the transition is parallel signing: sign artefacts with both ECDSA P-384 (CNSA 1.0) and ML-DSA-87 (CNSA 2.0). Verification systems that have been updated to support ML-DSA-87 use the post-quantum signature. Legacy verification systems fall back to ECDSA P-384. This avoids a hard cut-over and allows incremental deployment of ML-DSA-87 verification capacity across the supply chain.

For embedded and firmware signing where signature size is a binding constraint, note that ML-DSA-87 (4,627 bytes) may exceed header space originally allocated for ECDSA P-384 (approximately 96 bytes). XMSS and LMS (stateful hash-based signatures, approved under NIST SP 800-208) produce smaller signatures (approximately 1,116 bytes for LMS H25) for bounded-signature-count firmware signing applications. [VERIFIED from NIST SP 800-208, October 2020; RFC 8554]

PKI Migration: The Long Lead-Time Item

PKI migration is the component with the longest lead time in any CNSA 2.0 implementation programme. Until the CA hierarchy supports ML-DSA-87 key generation and certificate issuance, end-entity certificates cannot be migrated. For contractor-operated certificate authorities, the CA's HSM must support ML-DSA-87 key generation with FIPS 140-3 validation. Not all current FIPS 140-3 validated HSMs support ML-DSA-87 key management operations. Verify vendor support timelines before committing to a CA platform. [ASSUMED — HSM vendor roadmap commitments as of July 2026; verify each vendor's current published position]

FIPS 140-3 Validation: The Gating Constraint

NSS deployment requires FIPS 140-3 validated cryptographic modules. This requirement gates migration: a non-validated ML-KEM-1024 implementation does not satisfy CNSA 2.0 for NSS regardless of the algorithm's correctness. The migration timeline for any given system component is not the algorithm availability date; it is the FIPS 140-3 validation availability date for that specific component's platform.

OpenSSL 3.x supports ML-KEM and ML-DSA via the Open Quantum Safe (OQS) provider. The OQS provider is not FIPS 140-3 validated. It is appropriate for development, testing, and interoperability testing only. [VERIFIED from Open Quantum Safe project at https://openquantumsafe.org/]

Key Management System and HSM Requirements

PKCS#11 v3.0 (OASIS standard, 2020) includes mechanism definitions for post-quantum algorithms. KMIP v2.1 extended PQC algorithm identifiers for ML-KEM and ML-DSA as defined in FIPS 203 and FIPS 204. Deployments requiring unambiguous algorithm identification for post-quantum key objects should target KMIP v2.1. [VERIFIED from PKCS#11 v3.0, OASIS, 2020, https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.0/pkcs11-spec-v3.0.html]

What CNSA 2.0 Does Not Require

Three items that are not CNSA 2.0 requirements: SLH-DSA (FIPS 205) and FN-DSA (FIPS 206) are not in CNSA 2.0 (the September 2022 advisory predated these standards). QKD does not satisfy CNSA 2.0 — NSA has explicitly stated that QKD does not meet NSS security requirements. [VERIFIED from NSA, "Quantum Key Distribution (QKD) and Quantum Cryptography (QC)"] AES-256, SHA-384, and SHA-512 are unchanged; no migration work is required for these components.

The Implementation Programme Sequence

Phase 1 (Discover): Cryptographic Bill of Materials. Enumerate all cryptographic dependencies across software, firmware, hardware, and configuration. Output: a CBOM identifying every algorithm in use and the CNSA 2.0 gap. [VERIFIED from NIST SP 1800-38A, NCCoE, 2024, https://csrc.nist.gov/pubs/sp/1800/38/ipd]

Phase 2 (Prioritise): Map against the CNSA 2.0 timeline. Software and firmware signing preference date 2025 is already past. Apply HNDL weighting to key exchange migration: data with long retention periods at high classification is the highest priority.

Phase 3 (Migrate): Deploy hybrid configurations. Hybrid key exchange (P-384 + ML-KEM-1024) for TLS 1.3 and IKEv2/IPsec. Parallel code signing (ECDSA P-384 + ML-DSA-87). PKI migration planning with the issuing CA.

Phase 4 (Validate): Track FIPS 140-3 validation per component. Update the RMF system security plan. Update DISA STIG compliance documentation.

For the complete CNSA 2.0 timeline and contractor obligations, see the CNSA 2.0 compliance guide for US defence contractors. For the full comparison of what CNSA 2.0 replaces, see CNSA 2.0 versus CNSA 1.0 for defence suppliers. QSECDEF professional membership includes access to technical implementation workshops for contractors working through CNSA 2.0 programme design.