CNSA 2.0 Compliance by January 2027
What Federal Contractors Need Now

What CNSA 2.0 Is

The Commercial National Security Algorithm Suite (CNSA) is the NSA's specification for which cryptographic algorithms are approved for protecting classified and sensitive National Security System (NSS) information. CNSA 1.0, released in 2016, mandated algorithms like AES-256, SHA-384, RSA-3072+, and ECDSA/ECDH with P-384 curves.

CNSA 2.0, announced in September 2022, replaces the public-key components of CNSA 1.0 with post-quantum algorithms. The symmetric components (AES-256, SHA-384/SHA-512) remain unchanged because symmetric algorithms are not meaningfully weakened by quantum computers—Grover's algorithm only halves the effective key length, meaning AES-256 still provides 128-bit security against quantum attacks.

The public-key algorithms in CNSA 1.0—RSA, ECDSA, ECDH—are entirely replaced. There is no "optional" or "recommended" language. CNSA 2.0 is a mandate for systems protecting national security information.

CNSA 2.0 Required Algorithms

CNSA 2.0 specifies exact algorithms and minimum parameter sets. There is no room for interpretation:

Notice the security level requirement: CNSA 2.0 mandates ML-KEM-1024 (NIST Level 5) and ML-DSA-87 (NIST Level 5), not the Level 3 variants. This is stricter than what most commercial implementations default to. If your PQC implementation uses ML-KEM-768 or ML-DSA-65, you are not CNSA 2.0 compliant. Level 5 is the floor, not the ceiling.

The CNSA 2.0 Timeline

The NSA published a phased transition schedule with specific milestones. Each phase has different requirements depending on the type of system:

What Changes from CNSA 1.0

The transition from CNSA 1.0 to 2.0 is not an incremental update. It is a fundamental change in the mathematical foundations of every public-key operation:

• Key exchange moves from elliptic curves to lattices. ECDH P-384 is replaced by ML-KEM-1024. The underlying hard problem changes from the Elliptic Curve Discrete Logarithm Problem (ECDLP) to Module Learning With Errors (MLWE). Key sizes increase from 96 bytes (P-384 public key) to 1,568 bytes (ML-KEM-1024 public key).
• Signatures move from elliptic curves to lattices. ECDSA P-384 is replaced by ML-DSA-87. Signature sizes increase from 96 bytes to 4,627 bytes. Public key sizes increase from 96 bytes to 2,592 bytes.
• Hash-based signatures become mandatory for firmware. CNSA 2.0 introduces LMS and XMSS (stateful hash-based signatures) specifically for firmware and software signing, as an alternative to ML-DSA in contexts where statefulness is manageable.
• RSA is completely eliminated. Not deprecated. Not optional. Eliminated. There is no RSA key size that is CNSA 2.0 compliant, because RSA at any key size falls to Shor's algorithm.

Impact on Federal Contractors

If your organization holds or pursues contracts with the Department of Defense, intelligence community agencies, or any entity that operates National Security Systems, CNSA 2.0 compliance is a contract requirement, not a best practice. The impact extends across regulated industries that handle sensitive data.

Defense Industrial Base (DIB)

Every CMMC-certified organization in the defense supply chain must ensure that cryptographic components used in CUI handling meet CNSA 2.0 standards for systems designated as NSS. This means your VPN solutions, encrypted communications tools, identity management platforms, and data-at-rest encryption must all support ML-KEM-1024 and ML-DSA-87.

Intelligence Community Vendors

IC-bound systems face the most aggressive timeline. ICD 503 and CNSSP 15 already require CNSA-approved algorithms. The transition to CNSA 2.0 means existing accreditations tied to CNSA 1.0 algorithms will need to be updated. Systems that cannot demonstrate PQ algorithm support will not receive or maintain Authority to Operate (ATO).

Cloud Service Providers

FedRAMP High authorized cloud services used by NSS must support CNSA 2.0 algorithms for data-in-transit protection. If you provide cloud infrastructure or SaaS to federal agencies, your TLS implementation must support ML-KEM-1024 key exchange by 2029 at the latest, and your API authentication must support ML-DSA-87 signatures.

How H33 Meets Every CNSA 2.0 Requirement

H33's post-quantum cryptographic infrastructure was built from the ground up to meet CNSA 2.0 requirements at the highest security levels:

• ML-KEM-1024 (FIPS 203, Level 5): Native Rust implementation of CRYSTALS-Kyber at the 1024 parameter set. Constant-time arithmetic, side-channel-resistant sampling, fully compliant encoding. This is the exact algorithm and parameter set mandated by CNSA 2.0 for key encapsulation.
• ML-DSA-87 (FIPS 204, Level 5): Native Rust implementation of CRYSTALS-Dilithium at the 87 parameter set. H33 processes Dilithium sign+verify operations in 291 microseconds per batch, enabling 2.17 million authentications per second on production hardware.
• AES-256-GCM: NIST-approved symmetric encryption for data at rest and in transit, used as the symmetric component in H33's hybrid encryption pipeline.
• SHA-384/SHA-512: All hash operations use SHA-3 family or SHA-2 at 384-bit or higher output, consistent with CNSA 2.0 requirements.
• Zero external dependencies: H33's entire cryptographic stack is pure Rust. No OpenSSL, no libsodium, no C bindings. This eliminates supply chain vulnerabilities and simplifies the accreditation evidence package.

Security Level Mapping

The Path from CNSA 2.0 to Full FIPS Compliance

CNSA 2.0 compliance and FIPS 203/204 compliance are related but not identical. CNSA 2.0 specifies which algorithms to use and at what minimum security level. FIPS 203 and FIPS 204 define the algorithms themselves—their mathematical specifications, encoding formats, and test vectors.

An implementation can be FIPS 203/204 compliant (correctly implementing the algorithm) without being CNSA 2.0 compliant (if it uses Level 3 instead of Level 5). Conversely, CNSA 2.0 compliance requires FIPS 203/204 compliant implementations at the Level 5 parameter sets specifically.

For organizations pursuing CMMC Level 3, FedRAMP High, or ICD 503 accreditation—including those in healthcare and other regulated sectors—the path is:

1. Implement FIPS 203/204 at Level 5 parameters (ML-KEM-1024, ML-DSA-87)
2. Ensure constant-time implementation to prevent side-channel attacks
3. Validate against NIST test vectors (ACVP testing when modules become available)
4. Document algorithm usage in your System Security Plan (SSP)
5. Include PQC in your Plan of Action and Milestones (POA&M) if not yet fully deployed

H33 handles steps 1-3 entirely. Your team handles steps 4-5 with documentation templates available in our documentation portal.

Nine Months Remain

January 2027 is not a soft target. It is a procurement gate. If your product or platform handles classified data and does not support CNSA 2.0 algorithms by that date, you will not be included in new acquisitions. The engineering work to migrate is finite and well-understood. The question is whether you start now, with time to test and validate, or start in Q4 2026 under emergency pressure.

H33 provides a free tier with access to ML-KEM-1024 and ML-DSA-87 operations. You can begin integration testing today. Visit the API documentation or contact our government solutions team for CNSA 2.0 compliance assistance.