Commercial National Security Algorithm Suite (CNSA) 2.0

Use SHA-384 (or SHA-512) per FIPS 180-4 for hashing; SHA-384 provides sufficient security for NSS in CNSA 2.0.

• Hash-algorithm configuration (SHA-384/512)

• Use of SHA-1/SHA-256 where SHA-384+ required

Use ML-KEM-1024 (FIPS 203, formerly CRYSTALS-Kyber) for quantum-resistant key establishment, replacing ECDH and RSA key transport.

• Configuration using ML-KEM-1024 for key establishment
• Migration plan from ECDH/RSA

• ECDH/RSA key establishment retained without migration plan

Use ML-DSA-87 (FIPS 204, formerly CRYSTALS-Dilithium) for quantum-resistant general-purpose digital signatures, replacing ECDSA and RSA signatures.

• Configuration using ML-DSA-87 for signatures
• Migration plan from ECDSA/RSA

• ECDSA/RSA signatures retained without migration plan

For software and firmware signing, use the stateful hash-based signature schemes LMS or XMSS (NIST SP 800-208) at the CNSA 2.0 parameter levels (or ML-DSA); these are approved first because signing is an early-priority use case.

• Code/firmware-signing configuration using LMS/XMSS (or ML-DSA)
• State management for stateful hash-based signatures

• Software/firmware signed with RSA/ECDSA past the transition window
• Stateful-signature state reuse

Use AES with 256-bit keys (FIPS 197) for symmetric encryption in National Security Systems.

• Configuration evidence that symmetric encryption uses AES-256
• Crypto-algorithm inventory entry

• Symmetric encryption below AES-256
• Legacy ciphers in use

Implement CNSA 2.0 algorithms using cryptographic modules validated under the NIST/CCCS Cryptographic Module Validation Program (FIPS 140-3).

• CMVP certificate references for deployed modules

• Unvalidated cryptographic modules

Follow NSA guidance on hybrid (classical + post-quantum) configurations: NSA does not require hybrid solutions for NSS and prefers validated CNSA 2.0 algorithms, while standards/products may use hybrids during transition.

• Decision record on hybrid vs pure CNSA 2.0 configuration aligned to NSA guidance

• Assuming hybrid is required/prohibited without reference to NSA guidance

Maintain an inventory of cryptographic algorithms, protocols, key sizes and their locations across systems as the prerequisite for prioritised CNSA 2.0 / post-quantum migration.

• Cryptographic inventory (algorithms, key sizes, locations, dependencies)
• Prioritised migration backlog derived from the inventory

• No cryptographic inventory
• Unknown crypto dependencies

Where applicable, use products validated against NIAP Protection Profiles that incorporate CNSA 2.0 / post-quantum requirements.

• NIAP validation references for procured products

• No NIAP validation for NSS products

Support and prefer CNSA 2.0 for traditional networking equipment (VPNs, routers) per the published schedule, with exclusive use by 2030.

• Migration roadmap for networking/VPN equipment

• No CNSA 2.0 roadmap for networking

All National Security Systems must complete migration to CNSA 2.0 by the published final deadline (full transition by 2035); CNSA 1.0 algorithms are accepted without waiver only until 31 December 2025.

• Programme-level CNSA 2.0 migration plan with the 2035 end-state
• Waiver tracking for CNSA 1.0 use after 2025

• No enterprise migration plan to meet the deadline

Support and prefer CNSA 2.0 in operating systems per the published schedule, with exclusive use by ~2033.

• OS cryptographic-migration plan to CNSA 2.0

• No OS CNSA 2.0 plan

Begin supporting and preferring CNSA 2.0 algorithms for software/firmware signing immediately, with exclusive use by 2030 (signing is the highest-priority early migration).

• Migration roadmap for code/firmware signing to CNSA 2.0

• No timeline for signing migration

Support and prefer CNSA 2.0 for web browsers/servers and cloud services beginning ~2025-2026, with exclusive use by 2030-2033 per the CNSA 2.0 timeline.

• Migration roadmap for TLS/web and cloud services

• No CNSA 2.0 roadmap for web/cloud