CNSA 2.0 vs CNSA 1.0 for Quantum Key Management: What Is Changing in 2026 and 2027

The 2026 key management deadline in NSA's CNSA 2.0 roadmap is specific: all new key management and PKI systems must support CNSA 2.0 algorithms natively as of this year, not as an optional extension. Procurement cycles for KMS products run 12 to 18 months. An organisation reading this in mid-2026 that has not yet included ML-KEM-1024 and ML-DSA-87 native support as a contractual requirement is already late to that deadline.

Most technical teams working on CNSA 2.0 compliance understand that algorithms are changing. Fewer have worked through what that means at the infrastructure layer: the specific version requirements for key management protocols, the firmware certification timelines for HSMs, and the key hierarchy wrapping vulnerabilities that remain quantum-exposed even after the algorithm swap is made. This article addresses each of those three layers.

For the broader CNSA 2.0 supplier obligations context, see our companion piece at CNSA 2.0 vs CNSA 1.0: what changed and what defence suppliers must do differently. For the compliance programme framework, see the CNSA 2.0 compliance guide for US defence contractors. For the PKI migration layer that sits above the KMS, see PQC in PKI migration planning.

What CNSA 1.0 Permitted and Why It Cannot Continue

CNSA 1.0, published by NSA in August 2015, defined the approved cryptographic algorithms for National Security Systems. For key establishment, it permitted RSA (minimum 3072-bit), ECDH and ECDSA on the P-384 curve, and Diffie-Hellman (minimum 3072-bit). AES-256 and SHA-384 were retained for symmetric encryption and hashing respectively. The public-key component of that suite is fully broken by Shor's algorithm on a CRQC: RSA's security rests on the difficulty of integer factorisation; ECDH and ECDSA rest on the elliptic curve discrete logarithm problem. Shor's algorithm solves both in polynomial time.

CNSA 2.0, published September 2022, replaces the public-key component entirely. The approved algorithms for NSS under CNSA 2.0:

The point worth stating directly: CNSA 2.0 specifies ML-KEM-1024 (NIST security Level 5, equivalent to AES-256 security) for key encapsulation in NSS. This is not the ML-KEM-768 variant (Level 3) that appears in commercial TLS recommendations, including IETF RFC 9496. Enterprise KMS products deployed for commercial use that default to ML-KEM-768 require explicit configuration verification and possible reconfiguration before NSS deployment. The two parameter sets are not interchangeable for NSS purposes, and a system configured with ML-KEM-768 is not CNSA 2.0 compliant.

Key Management Protocol Support Requirements

Achieving CNSA 2.0 compliance in a key management system requires coherent updates across three layers: the HSM firmware, the PKCS#11 middleware interface, and the KMS application layer. An upgrade at any one layer without the other two does not achieve compliance. Each layer has its own standards dependency and its own lead time.

KMIP version. The Key Management Interoperability Protocol (KMIP) is the OASIS standard governing communication between key management systems and the clients that consume cryptographic keys. KMIP 2.2, published August 2023, adds explicit support for ML-KEM and ML-DSA key object types consistent with NIST PQC standardisation. A KMS that supports only KMIP 2.1 (March 2020) or earlier cannot natively manage ML-KEM-1024 keys. KMIP 2.2 is the minimum version for CNSA 2.0 KMS compliance.

HSM firmware and FIPS 140-3 certification. FIPS 140-3 (which superseded FIPS 140-2 for new certifications from September 2021, with legacy FIPS 140-2 certificates valid until 28 September 2026) defines the security requirements for cryptographic modules. HSM manufacturers are releasing firmware updates adding ML-KEM-1024 and ML-DSA-87 support. The FIPS 140-3 validation process for new algorithm implementations adds 18 to 36 months of certification lead time through the NIST Cryptographic Module Validation Programme. An HSM with ML-KEM-1024 firmware that has not yet completed FIPS 140-3 validation is not certifiable for NSS deployment. Verify validation status rather than firmware availability when planning procurement timelines. [ASSUMED: specific vendor firmware availability and certification status as of June 2026; verify with Thales, Entrust, and Utimaco directly before finalising procurement commitments.]

PKCS#11 middleware. OASIS PKCS#11 v3.1 (October 2023) defines the cryptographic token interface mechanisms for post-quantum algorithms, including CKM_ML_KEM and CKM_ML_KEM_KEY_PAIR_GEN for ML-KEM key operations, and CKM_ML_DSA and CKM_ML_DSA_KEY_PAIR_GEN for ML-DSA signature operations. Middleware and application layers that invoke HSMs via PKCS#11 must use v3.1 mechanisms to access ML-KEM and ML-DSA functionality. Legacy PKCS#11 v2.40 implementations will not expose these mechanisms regardless of HSM firmware capability. The v3.1 middleware update is a prerequisite for exercising new HSM capabilities.

Key Hierarchy Migration: What Wrapping Means under CNSA 2.0

One of the most commonly missed vulnerabilities in CNSA 2.0 migration planning is the key wrapping layer. Organisations focus on replacing RSA and ECC in their key exchange and signature implementations, but overlook that their key hierarchy wraps data encryption keys (DEKs) using RSA key encryption keys (KEKs). A DEK wrapped under an RSA-3072 KEK is quantum-vulnerable at the wrapping layer, even if the DEK itself is AES-256. Breaking the RSA KEK with a CRQC exposes every DEK it has ever wrapped.

CNSA 2.0 compliance requires that both the KEK and the wrapping mechanism be ML-KEM-based or hybrid. NIST SP 800-57 Part 1 Rev. 5 establishes key hierarchy principles; the PQC-specific guidance for key wrapping is in NIST NCCoE SP 1800-38B. The re-wrapping exercise is a separate migration workstream from the algorithm replacement in active key exchange. Both are required.

During the transition, NSA's CNSA 2.0 guidance permits dual-mode operation: CNSA 1.0 (RSA/ECC) and CNSA 2.0 (ML-KEM-1024) key types coexisting in the KMS to support interoperability with communicating parties that have not yet completed their own migration. The operative rule from NSA's CNSA 2.0 FAQ: new key generation for NSS should use CNSA 2.0 algorithms from the effective date. Existing CNSA 1.0 keys can coexist during the transition window (2025 to 2033), but no new RSA or ECC keys should be generated for NSS use after the effective date.

A further dependency specific to classified environments: asymmetric key distribution for the highest-classification material uses out-of-band key transport through physical key loaders and Type 1 devices, separate from KMS-managed keys. The CNSA 2.0 transition affects both paths. The Type 1 device transition depends on NSA's own product qualification schedule, which operates separately from FIPS 140-3 certification and for which NSA has not published a complete public timeline. Defence contractors with Type 1 requirements should treat this as a potentially longer-lead dependency than the commercial KMS migration.

The QSECDEF Cryptographic Inventory tool at /tools/cryptographic-inventory/ provides a structured approach to identifying all KEKs and DEKs in scope for the hierarchy migration.

Key Escrow and Archival: The Long-Tail HNDL Problem

Key escrow and key archival represent a specific subset of the key management migration that requires separate treatment.

Escrow. Key escrow stores decryption keys with a trusted third party for recovery purposes. The transport of escrowed keys to the escrow authority uses asymmetric mechanisms. If those transport mechanisms are RSA or ECDH, the escrow transport layer is CNSA 1.0-grade and must be migrated. For CNSA 2.0 compliance, escrow transport must use ML-KEM-1024 for key encapsulation and ML-DSA-87 for authentication of the escrow submission. Historical escrowed keys transported using CNSA 1.0 mechanisms cannot be retroactively remediated: the key material was transported, and the transport event is fixed. Only new escrow transactions from the effective date can be made CNSA 2.0 compliant.

Archival. Keys archived for audit, legal hold, or operational continuity carry a data lifetime problem analogous to the HNDL risk for communications data. An AES-256 DEK archived under an RSA-3072 key wrap in 2020, required to be accessible in 2035 to decrypt stored classified data, is at HNDL risk: a CRQC with Shor's algorithm can break the RSA wrap and recover the DEK. Applying Mosca's notation: the time to complete the re-wrapping programme (X) plus the remaining required access period for the archived key (Z) exceeds the time to CRQC capability (Y) for archives with multi-year access requirements, placing them in the immediate risk window. The correct response is re-wrapping archived keys under ML-KEM-1024 before the expected CRQC capability window. NIST SP 800-57 Part 1 Rev. 5 Section 5.3 addresses key archival periods; NIST IR 8547's deprecation timeline implies the re-wrapping requirement for archived key material.

The 2026 to 2027 Compliance Calendar

NSA's CNSA 2.0 roadmap specifies four milestone dates relevant to key management:

• End of 2025: All new software and firmware signed with CNSA 2.0 algorithms (ML-DSA-87, or XMSS/LMS for firmware).
• End of 2026: All new key management and PKI systems must support CNSA 2.0 algorithms natively. This is the current deadline. KMS procurement or renewal agreements executed from this date must contractually confirm ML-KEM-1024 and ML-DSA-87 native support.
• End of 2030: Deprecation of RSA and ECC for new key generation across NSS.
• End of 2033: Full retirement of RSA and ECC from all NSS.

The 2026 KMS requirement has procurement contract implications beyond the immediate system. For prime contractors and subcontractors delivering systems to NSS customers, the National Industrial Security Program Operating Manual (NISPOM, 32 CFR Part 117) and DFARS clause 252.204-7012 (Safeguarding Covered Defence Information) flow cybersecurity requirements down to subcontractors, including cryptographic posture obligations. A prime contractor cannot certify that a delivered system's KMS meets CNSA 2.0 requirements if the subcontractor-supplied KMS component only supports CNSA 1.0. Programme offices are working the CNSA 2.0 KMS compliance requirement into Contract Data Requirements List items [ASSUMED: specific CDRL inclusion by individual programme offices; verify with OUSD(AT&L) or DCSA guidance as of publication date]. The procurement implication: "native support" in a contract requirement means the capability is present without requiring a separately procured add-on module or a vendor roadmap commitment. It means the product supports it today.

Hybrid Key Establishment During Transition

NSA's CNSA 2.0 guidance permits hybrid key establishment during the transition window: combining ML-KEM-1024 with a classical algorithm such as ECDH P-384 in a hybrid KEM construction. The security property is important to understand: a properly constructed hybrid KEM requires breaking both components to recover the session key. If ML-KEM-1024 has an undiscovered flaw, the ECDH P-384 component still provides P-384-level classical protection. If ECDH P-384 is broken by a CRQC, the ML-KEM-1024 component maintains its post-quantum security. The hybrid construction provides hedged security during a period when ML-KEM-1024 is newly standardised and classical ECDH continues to have interoperability value.

Note the parameter set difference from commercial TLS practice. IETF RFC 9496 defines X-Wing: a hybrid key encapsulation mechanism combining X25519 and ML-KEM-768, specified for use in TLS 1.3 key exchange. NSS-compliant hybrid KEM uses ECDH P-384 combined with ML-KEM-1024, not the ML-KEM-768 variant. The two constructions are not interchangeable in NSS environments. Products that support RFC 9496 hybrid TLS but do not separately support ML-KEM-1024 do not satisfy the NSS hybrid requirement.

The IETF TLS Working Group is finalising hybrid key exchange drafts (draft-ietf-tls-hybrid-design) covering the construction principles applicable to TLS 1.3. NSS-specific implementations will require alignment with applicable System Security Plans. [Note: NIST SP 800-227 on hybrid key exchange guidance was in draft as of August 2025; verify publication status before finalising references to this document.]

What Does Not Change: AES-256 and SHA-384

Not every component of CNSA 1.0-era KMS infrastructure requires replacement. AES-256 is retained in CNSA 2.0 without modification requirements. Grover's algorithm provides a quadratic speedup for symmetric brute-force key search, halving effective key length to approximately 128 bits for AES-256. NSA judges 128-bit post-Grover symmetric security adequate for NSS. NIST IR 8547 (November 2024) does not deprecate AES-256. Key management systems using AES-256 for symmetric key wrapping operations do not need algorithm changes at that layer. The migration focus for KMS is the asymmetric components: RSA and ECC in key establishment and signatures.

SHA-384 and SHA-512 are retained under CNSA 2.0. Grover's algorithm provides a square-root speedup on collision finding, but SHA-384 retains 192-bit post-Grover collision resistance, above NSA's security margin threshold. Hash-based operations in KMS audit logs, key fingerprinting, and certificate transparency logs do not require algorithm changes. SHA-1, already classically deprecated and not relevant to modern KMS implementations, is not retained.

The practical summary for KMS planning: the asymmetric migration is the complete scope. AES-256, SHA-384, and SHA-512 are not in scope. Teams that have been resourcing symmetric algorithm replacement in their KMS migration plans can redirect that effort to the asymmetric layers where the actual work is required.