CNSA 2.0 Compliance Guide: Complete Breakdown of NSA's Quantum-Safe Requirements for 2026

What Is CNSA 2.0?

The Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) is the NSA’s updated set of cryptographic algorithm requirements for National Security Systems (NSS). Published in September 2022 and subsequently detailed through implementation guidance, CNSA 2.0 replaces the original CNSA 1.0 suite with quantum-resistant algorithms designed to protect classified and sensitive information against the threat of cryptographically relevant quantum computers (CRQCs).

CNSA 2.0 represents the most significant mandated cryptographic transition in decades — moving an entire national security infrastructure from classical public-key algorithms (RSA, ECC, DH) to post-quantum algorithms standardized by NIST.

CNSA 1.0 vs CNSA 2.0

Function	CNSA 1.0 (Classical)	CNSA 2.0 (Quantum-Safe)
Key Encapsulation	ECDH P-384, DH 3072+	ML-KEM-1024 (FIPS 203)
Digital Signatures	ECDSA P-384, RSA 3072+	ML-DSA-87 (FIPS 204)
Firmware/Software Signing	ECDSA P-384, RSA 3072+	LMS / XMSS (SP 800-208)
Symmetric Encryption	AES-256	AES-256 (unchanged)
Hashing	SHA-384	SHA-384 or SHA-512

Key observation: Symmetric algorithms (AES-256) and hash functions (SHA-384+) remain unchanged because they already provide adequate post-quantum security at these key sizes. The transition focuses entirely on asymmetric/public-key cryptography.

Who Must Comply with CNSA 2.0?

Direct Applicability

CNSA 2.0 directly applies to:

• National Security Systems (NSS): Systems processing classified information or critical to military/intelligence operations
• Defense contractors: Organizations handling NSS data under DFARS/CMMC requirements
• Intelligence community: All IC systems and supporting infrastructure
• Federal systems with NSS designation: Specific civilian agency systems designated for national security

Extended Influence

While CNSA 2.0 technically applies only to NSS, its influence extends much broader:

• Defense Industrial Base (DIB): Contractors must align with CNSA 2.0 for systems processing controlled unclassified information (CUI) related to NSS
• Critical infrastructure: CISA guidance increasingly references CNSA 2.0 as a benchmark
• Financial services: Many large financial institutions voluntarily adopt CNSA 2.0 as their quantum readiness target
• Healthcare: Organizations with 25+ year data retention requirements use CNSA 2.0 as their PQC roadmap
• International allies: Five Eyes nations are aligning their own PQC mandates with CNSA 2.0 timelines

The Compliance Cascade

Even if your organization is not directly subject to CNSA 2.0, you likely face indirect pressure:

1. Your customers may require CNSA 2.0-aligned cryptography
2. Your supply chain partners in the DIB must comply, creating interoperability requirements
3. Insurance providers are beginning to reference quantum readiness in underwriting
4. Future regulations (EU Cyber Resilience Act updates, NIS2 technical guidance) will likely mirror CNSA 2.0 algorithm selections

Mandated Algorithms: Deep Dive

ML-KEM-1024 (Key Encapsulation)

Standard: NIST FIPS 203 Based on: Module Lattice-based Key Encapsulation Mechanism (formerly CRYSTALS-Kyber) CNSA 2.0 Requirement: ML-KEM-1024 parameter set (highest security level)

Parameter	Value
Security level	NIST Level 5 (equivalent to AES-256)
Public key size	1,568 bytes
Ciphertext size	1,568 bytes
Shared secret size	32 bytes
Encapsulation speed	~0.04 ms
Decapsulation speed	~0.05 ms

Why ML-KEM-1024 specifically: CNSA 2.0 mandates the highest parameter set to provide maximum security margin. While ML-KEM-512 and ML-KEM-768 are available, only ML-KEM-1024 satisfies CNSA 2.0 for NSS.

Usage: Replace ECDH/RSA-based key exchange in TLS, VPNs, S/MIME, and any key establishment protocol.

ML-DSA-87 (Digital Signatures)

Standard: NIST FIPS 204 Based on: Module Lattice-based Digital Signature Algorithm (formerly CRYSTALS-Dilithium) CNSA 2.0 Requirement: ML-DSA-87 parameter set

Parameter	Value
Security level	NIST Level 5
Public key size	2,592 bytes
Signature size	4,627 bytes
Signing speed	~0.3 ms
Verification speed	~0.1 ms

Why ML-DSA-87: Provides the highest security level within the ML-DSA family. Required for all general-purpose digital signatures in NSS.

Usage: Software authentication, document signing, protocol authentication, certificate signatures.

LMS and XMSS (Stateful Hash-Based Signatures)

Standard: NIST SP 800-208 CNSA 2.0 Requirement: LMS or XMSS for firmware and software signing

Aspect	LMS	XMSS
Type	Stateful hash-based	Stateful hash-based
Security basis	Hash function security only	Hash function security only
Key management	Requires state tracking	Requires state tracking
Best for	Firmware updates, secure boot	Similar use cases
Key exhaustion risk	Yes — limited signatures per key	Yes — limited signatures per key

Critical consideration: LMS/XMSS are stateful — each private key can only produce a fixed number of signatures, and state must be carefully managed to prevent key reuse. This makes them suitable for firmware signing (infrequent, controlled operations) but impractical for high-frequency signing.

Usage: Firmware/BIOS signing, secure boot chains, software distribution signing.

AES-256 (Symmetric Encryption)

Standard: NIST FIPS 197 CNSA 2.0 Requirement: AES-256 (unchanged from CNSA 1.0)

AES-256 already provides adequate post-quantum security. Grover’s algorithm reduces effective security to 128 bits, which remains computationally infeasible. No change is required for symmetric encryption, but organizations still using AES-128 should upgrade.

SHA-384 and SHA-512 (Hashing)

Standard: NIST FIPS 180-4 CNSA 2.0 Requirement: SHA-384 minimum, SHA-512 preferred

Like AES, SHA-384+ provides sufficient post-quantum security margins. Organizations using SHA-256 may continue for most purposes, but NSS must use SHA-384 or SHA-512.

CNSA 2.0 Deadlines

The January 2027 Acquisition Gate

The most immediate deadline:

By January 2027: All new system acquisitions for NSS must support CNSA 2.0 algorithms.

This means:

• New procurement contracts must specify CNSA 2.0-capable products
• Vendors selling to NSS must have quantum-safe implementations ready
• System integrators must architect new solutions using CNSA 2.0 algorithms
• Any system entering service after January 2027 must support quantum-safe cryptography

Implication for vendors: If your products or services are sold to U.S. national security customers, you must support ML-KEM-1024 and ML-DSA-87 by January 2027 or risk being excluded from new contracts.

The 2030 Preference Milestone

By 2030: CNSA 2.0 algorithms should be preferred (not just supported) for NSS.

This means:

• Quantum-safe algorithms are the default, with classical as fallback only
• Hybrid deployments should favor PQC over classical
• New protocol negotiations should prefer CNSA 2.0 cipher suites

The 2033 Full Compliance Deadline

By 2033: All NSS must exclusively use CNSA 2.0 algorithms. Classical-only cryptography must be completely removed.

This means:

• RSA, ECDSA, ECDH, and DH are no longer permitted for NSS
• All systems must have completed migration
• No classical fallback paths remain
• Full compliance verification and attestation required

Timeline Summary

2022 ─── CNSA 2.0 published
2024 ─── NIST FIPS 203/204/205 finalized
2025 ─── Implementation guidance detailed
2026 ─── YOU ARE HERE (preparation must be well underway)
2027 ─── New acquisition gate (must support CNSA 2.0)
2030 ─── CNSA 2.0 preferred for all NSS
2033 ─── Full compliance required (classical removed)
2035 ─── Estimated CRQC availability (various projections)

Assessing Your Current State

Step 1: Determine Applicability

Answer these questions to determine your CNSA 2.0 exposure:

1. Do you operate or support National Security Systems?
2. Do you hold classified information processing contracts?
3. Are you part of the Defense Industrial Base?
4. Do your customers require CNSA 2.0 alignment?
5. Do you handle data with 10+ year confidentiality requirements?
6. Are you in critical infrastructure sectors with PQC guidance?

If you answered yes to any of these, CNSA 2.0 applies directly or should be your target standard.

Step 2: Generate Your CBOM

You cannot assess compliance without knowing your current cryptographic state. Generate a comprehensive Cryptographic Bill of Materials covering:

• All public-key algorithms in use (RSA key sizes, EC curves, DH parameters)
• All symmetric algorithms and key sizes
• All hash functions and their usage contexts
• All cryptographic protocols and their configurations
• All certificates and their signing algorithms
• All key management systems and their capabilities

QCecuring CBOM automates this discovery process, generating CycloneDX-compliant inventories that map directly to CNSA 2.0 requirements. Organizations deploying QCecuring gain immediate visibility into their compliance gaps.

Step 3: Map Current State to CNSA 2.0

Create a gap analysis:

Function	Current Algorithm	CNSA 2.0 Required	Gap?	Systems Affected
Key Exchange	ECDH P-384	ML-KEM-1024	Yes	847 systems
TLS Signatures	ECDSA P-256	ML-DSA-87	Yes	1,203 systems
Code Signing	RSA-4096	LMS/XMSS	Yes	15 pipelines
Symmetric	AES-256	AES-256	No	-
Hashing	SHA-256	SHA-384+	Yes	2,100 systems

Step 4: Identify Compliance Blockers

Common blockers that prevent CNSA 2.0 readiness:

Technology blockers:

• Hardware that cannot support PQC (older HSMs, embedded devices)
• Software libraries without PQC support
• Protocols without PQC extensions (older TLS stacks)
• Systems with hardcoded algorithms (no crypto-agility)

Organizational blockers:

• No dedicated PQC migration team or budget
• Insufficient cryptographic expertise
• Vendor dependencies (waiting for vendor PQC support)
• Competing priorities delaying migration start

Process blockers:

• No cryptographic inventory (CBOM) exists
• Change management processes too slow for migration scale
• Testing and certification timelines exceed available window
• Inter-agency or cross-organization coordination requirements

Gap Analysis Framework

Risk-Based Gap Scoring

For each identified gap, score the risk of non-compliance:

Gap Risk Score = Timeline Urgency × System Criticality × Migration Complexity

Timeline Urgency:
  - 2027 gate applies: 10
  - 2030 preference applies: 7
  - 2033 deadline applies: 5
  
System Criticality:
  - Core NSS processing: 10
  - Supporting infrastructure: 7
  - Development/test environments: 3
  
Migration Complexity:
  - Config change only: 2
  - Code modification needed: 5
  - System replacement needed: 8
  - Multi-party coordination needed: 10

Prioritized Gap Resolution

Critical gaps (address immediately):

• Systems facing the January 2027 acquisition gate without PQC support
• Systems protecting data at highest HNDL risk (25+ year confidentiality)
• Certificate authorities without PQC signing capabilities
• Systems with no viable PQC migration path identified

High-priority gaps (address within 12 months):

• High-criticality NSS systems still on classical-only cryptography
• Key management infrastructure unable to handle PQC key sizes
• Network infrastructure without hybrid cipher suite support
• Vendor contracts without PQC capability requirements

Standard gaps (address within 24 months):

• Systems that can migrate via configuration once infrastructure is ready
• Hash function upgrades from SHA-256 to SHA-384
• Development and staging environments
• Documentation and training gaps

Implementation Approach

Quick Wins (Achievable in 2026)

1. Upgrade symmetric algorithms: Move remaining AES-128 usage to AES-256
2. Upgrade hash functions: Move SHA-256 to SHA-384 in CNSA 2.0-scoped systems
3. Enable hybrid TLS: Deploy ML-KEM hybrid key exchange where servers support it
4. Update procurement language: Add CNSA 2.0 requirements to new contracts
5. Generate initial CBOM: Deploy QCecuring CBOM for visibility into current state

Medium-Term Actions (2026-2028)

1. Migrate certificate infrastructure: Deploy PQC-capable intermediate CAs
2. Implement crypto-agility: Refactor applications for configurable algorithm selection
3. Deploy ML-KEM-1024: Replace ECDH/RSA key exchange in priority systems
4. Deploy ML-DSA-87: Migrate signature operations in priority systems
5. Test LMS/XMSS: Pilot stateful hash-based signatures for firmware signing

Long-Term Actions (2028-2033)

1. Complete full migration: All remaining systems transitioned to CNSA 2.0
2. Remove classical fallbacks: Eliminate RSA/ECC from operational configurations
3. Achieve compliance attestation: Document and verify full CNSA 2.0 compliance
4. Establish sustained operations: Continuous monitoring prevents regression

Hybrid Cryptography Under CNSA 2.0

NSA’s Hybrid Guidance

The NSA permits hybrid cryptographic deployment during the transition period, with important caveats:

• Hybrid is acceptable as a transition mechanism, not a permanent state
• The quantum-safe component must use CNSA 2.0-approved algorithms
• By 2033, systems must operate with CNSA 2.0 algorithms standalone
• Hybrid implementations must not weaken the quantum-safe component

Acceptable Hybrid Configurations

Protocol	Hybrid Approach	Standards
TLS 1.3 Key Exchange	X25519MLKEM768 or P384MLKEM1024	Draft IETF standards
Digital Signatures	Composite: ECDSA + ML-DSA	X.509 composite extensions
VPN (IPsec)	IKEv2 with PQC KEM	RFC 9370 framework
S/MIME	Hybrid key transport	Draft composite algorithms
SSH	Hybrid key exchange	OpenSSH 9.x support

Hybrid Transition Timeline

2026: Hybrid deployment recommended (classical + PQC)
2027: Hybrid required for new acquisitions (must include PQC)
2030: PQC preferred, classical component for compatibility only
2033: PQC-only required, hybrid no longer needed

CNSA 2.0 and Other Compliance Frameworks

Alignment with PCI DSS 4.0

PCI DSS 4.0 Requirement 12.3.3 mandates cryptographic inventory — directly supporting CNSA 2.0 readiness. Organizations meeting both standards should:

• Use a single CBOM to satisfy both requirements
• Apply CNSA 2.0 algorithm selections to payment systems where applicable
• Leverage PCI DSS cryptographic inventory for CNSA 2.0 gap analysis

Alignment with DORA

The EU’s Digital Operational Resilience Act requires cryptographic risk management for financial entities. CNSA 2.0 algorithm selections provide a clear target standard for DORA’s cryptographic requirements.

Alignment with Executive Order 14028

EO 14028’s software supply chain transparency requirements (including SBOM/CBOM) directly support CNSA 2.0 compliance — you need cryptographic visibility to demonstrate algorithm compliance.

Tools for CNSA 2.0 Compliance

Discovery and Assessment

• QCecuring CBOM: Automated cryptographic discovery with built-in CNSA 2.0 compliance mapping. Generates gap reports showing exactly which systems need migration to meet CNSA 2.0 requirements.
• NIST PQC Reference Implementations: For development and testing
• OpenSSL 3.x: PQC algorithm support via oqs-provider

Validation and Certification

• NIST CAVP: Algorithm validation testing
• CMVP: FIPS 140-3 module validation
• DoD Assessment Programs: For NSS-specific validation

Migration Support

• liboqs: Open-source PQC library for development
• Open Quantum Safe: PQC integration for various platforms
• Vendor PQC SDKs: Platform-specific implementations

Frequently Asked Questions

Does CNSA 2.0 apply to commercial organizations?

Directly, no — CNSA 2.0 applies to National Security Systems. However, any organization in the defense supply chain, handling NSS-related data, or selling products to NSS operators is effectively required to comply. Many non-defense organizations voluntarily adopt CNSA 2.0 as their PQC target standard because it represents well-researched, conservative algorithm selections.

Can we use ML-KEM-768 instead of ML-KEM-1024?

For CNSA 2.0 compliance: no. The mandate specifically requires ML-KEM-1024 (NIST Security Level 5). Organizations not subject to CNSA 2.0 may choose ML-KEM-768 (Level 3) for better performance, but NSS systems must use the 1024 parameter set.

What about SLH-DSA (SPHINCS+)?

NIST standardized SLH-DSA as FIPS 205, but CNSA 2.0 does not currently mandate it. ML-DSA-87 is the primary signature algorithm, with LMS/XMSS for stateful use cases. SLH-DSA remains available as a conservative backup option due to its purely hash-based security model.

What happens if we miss the 2027 deadline?

For organizations selling to NSS: contracts may require CNSA 2.0 support for new acquisitions starting January 2027. Systems without support risk being excluded from new procurements. For internal NSS operators: non-compliance must be documented with risk acceptance and remediation timeline.

Are there waivers for legacy systems?

The NSA has not publicly detailed waiver processes for CNSA 2.0. Legacy systems that genuinely cannot be migrated may require isolation, risk acceptance documentation, and accelerated replacement planning. Relying on waivers as a strategy is inadvisable.

Key Takeaways

• CNSA 2.0 mandates specific quantum-safe algorithms — ML-KEM-1024, ML-DSA-87, LMS/XMSS, AES-256, SHA-384+
• January 2027 is the first hard deadline — new NSS acquisitions must support CNSA 2.0 algorithms
• 2033 is full compliance — all NSS must exclusively use CNSA 2.0, with classical cryptography removed
• Applicability extends beyond NSS — defense contractors, supply chain partners, and critical infrastructure are all affected
• CBOM is a prerequisite — you cannot demonstrate compliance without knowing your cryptographic inventory
• QCecuring CBOM maps directly to CNSA 2.0 — automated discovery with compliance gap reporting accelerates readiness assessment
• Hybrid is a transition mechanism — acceptable now but must resolve to PQC-only by 2033
• Start with quick wins — AES-256, SHA-384 upgrades, and hybrid TLS are achievable in 2026
• Plan for the full timeline — large organizations need the entire 2026-2033 window for complete migration
• Align with other frameworks — PCI DSS 4.0, DORA, and EO 14028 complement CNSA 2.0 readiness