Dr. Sarah Chen
CNSA 2.0 is the NSA's mandated post-quantum algorithm suite for national security systems. It requires ML-KEM for key establishment, ML-DSA for digital signatures, XMSS or LMS for firmware/software signing, and SHA-384/512 for hashing. The transition deadline for most national security systems is 2033. For blockchain infrastructure handling classified or sensitive government data, CNSA 2.0 compliance is a procurement requirement, not a best-practice suggestion.
What Is CNSA 2.0? The NSA's Post-Quantum Algorithm Mandate
CNSA 2.0, the Commercial National Security Algorithm Suite 2.0, is a set of cryptographic algorithm requirements published by the NSA's National Security Agency in September 2022. It replaces CNSA 1.0 (also known as Suite B), which specified classical algorithms including ECDSA, ECDH, and AES. CNSA 2.0 mandates exclusively post-quantum algorithms for all National Security Systems (NSS), which includes any federal system handling classified information or critical infrastructure.
Unlike NIST's post-quantum standards (FIPS 203, 204, 205, 206), which provide optional guidance and define new standards, CNSA 2.0 is a mandate with explicit transition deadlines. Federal agencies and their contractors operating NSS are required to plan and execute migration to CNSA 2.0 algorithms. The NSA issued specific guidance documents for software applications, operating systems, networking equipment, and data-at-rest encryption, with deadlines ranging from 2025 to 2033.
CNSA 2.0 Algorithm Requirements: The Complete List
CNSA 2.0 specifies algorithms across four cryptographic functions. For each function, it names the approved algorithm, the approved parameter set, and the classical algorithm it replaces.
| Function | CNSA 2.0 Algorithm | CNSA 1.0 Predecessor | NIST Standard |
|---|---|---|---|
| Key establishment | ML-KEM-1024 | ECDH P-384 | FIPS 203 |
| Digital signatures | ML-DSA-87 | ECDSA P-384 | FIPS 204 |
| Firmware/software signing | XMSS / LMS | ECDSA P-384 | NIST SP 800-208 |
| Hashing | SHA-384 / SHA-512 | SHA-384 / SHA-512 | FIPS 180-4 |
| Symmetric encryption | AES-256 | AES-256 | FIPS 197 |
CNSA 2.0 specifies the highest parameter sets for signatures and key establishment (ML-DSA-87, ML-KEM-1024) for national security headroom. Commercial applications may use lower parameter sets where NIST guidelines permit.
The CNSA 2.0 Transition Timeline for Blockchain Infrastructure
The NSA published technology-specific transition guidance with different deadlines for different system types. The guidance relevant to blockchain and distributed ledger infrastructure falls primarily under software applications, networking, and data-at-rest encryption.
For software applications (which includes any blockchain node software, wallet software, or API layer handling classified data): the NSA guidance requires CNSA 2.0 algorithm support to be available in new systems by 2025, with full exclusivity (no classical algorithms permitted) by 2030. For networking equipment (relevant to node-to-node communication, RPC endpoints, and API gateways): support required by 2026, exclusivity by 2030. For data-at-rest encryption of classified data: support required by 2025, exclusivity by 2033.
These deadlines apply to National Security Systems specifically. Commercial blockchain infrastructure does not fall under NSA jurisdiction unless it is a contractor system handling classified data or is operating under a federal contract requiring CNSA 2.0 compliance. However, the CNSA 2.0 timeline functions as a leading indicator for the commercial sector: procurement requirements from government agencies flow to contractors, and contractor requirements flow to commercial software vendors.
If you are a federal contractor or subcontractor and your work involves blockchain, distributed ledger, or cryptographic infrastructure, check whether your prime contract specifies CNSA 2.0 or NIST FIPS 140-3 requirements. These flow down through the contracting chain and may already apply to your systems without explicit notification. Review NIST SP 800-131A (transition of cryptographic algorithms) and the NSA's CNSA 2.0 FAQ for the specific algorithms and key sizes required.
What CNSA 2.0 Compliance Means for Blockchain Transaction Signing
For a blockchain system to be CNSA 2.0 compliant at the transaction signing layer, it must use ML-DSA-87 (CRYSTALS-Dilithium at the highest security level, equivalent to AES-256 post-quantum security) for all digital signatures. ML-DSA-87 produces signatures of 4,595 bytes and has a public key of 2,592 bytes. This is the highest parameter set in the ML-DSA family and provides post-quantum security at NIST Level 5.
Most commercial blockchain applications do not need CNSA 2.0's Level 5 requirement. NIST's own guidance for non-NSS applications recommends ML-DSA-44 (Level 1) or ML-DSA-65 (Level 3) as appropriate defaults. The NSA specifies ML-DSA-87 specifically because national security data may have classification periods extending 20 to 50 years, requiring a security margin that accounts for algorithmic advances over that period.
For key establishment in blockchain node communication, CNSA 2.0 requires ML-KEM-1024 rather than the ML-KEM-768 that Cloudflare and Google have deployed commercially. ML-KEM-1024 adds approximately 432 bytes to the handshake compared to ML-KEM-768, a modest increase in the context of overall TLS handshake size.
NSA Quantum Resistant Algorithms: The Difference Between CNSA 2.0 and NIST FIPS
CNSA 2.0 and the NIST FIPS post-quantum standards are related but distinct. NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA/SPHINCS+), and FIPS 206 (FN-DSA/Falcon) define the algorithms and their approved parameter sets. CNSA 2.0 selects from those standards and specifies which parameter sets are required for NSS applications.
The relationship means that any CNSA 2.0 compliant system is automatically using NIST-standardised algorithms, but a system using NIST-standardised algorithms at lower parameter sets (ML-DSA-44 rather than ML-DSA-87) is FIPS-compliant but not CNSA 2.0 compliant. For commercial blockchain applications, FIPS compliance is the relevant standard. For government-adjacent or defence applications, CNSA 2.0 compliance is the requirement.
Practical Steps for Blockchain Systems Targeting CNSA 2.0 Compliance
For blockchain infrastructure teams building toward CNSA 2.0 compliance, the practical checklist has four layers. First, the signature layer: replace ECDSA/Schnorr transaction signing with ML-DSA-87 and update smart contract or script verification logic accordingly. Second, the key establishment layer: update all TLS connections between nodes to use ML-KEM-1024 (X25519MLKEM1024 hybrid during transition). Third, the hashing layer: SHA-256 is not CNSA 2.0 approved for new systems; upgrade to SHA-384 or SHA-512 where hashing is used for non-blockchain-consensus purposes. Fourth, the key management layer: ensure HSMs supporting ML-DSA-87 are in the signing path, replacing any ECDSA-only HSM infrastructure.
The blockchain consensus mechanism itself (Proof of Work, Proof of Stake) is separate from CNSA 2.0 considerations: the VRF or BLS signatures used in many PoS consensus protocols are also vulnerable to quantum attacks and need separate post-quantum replacements, which are an active area of research not yet covered by CNSA 2.0.
NIST FIPS 204 Signatures by Default
QuanChain uses ML-DSA (FIPS 204) for all transaction signing from genesis. For government and enterprise teams with CNSA 2.0 requirements, contact us to discuss deployment configurations.
Talk to the TeamFrequently Asked Questions
What is the difference between CNSA 1.0 and CNSA 2.0?
CNSA 1.0 (Suite B) specified classical elliptic curve algorithms: ECDH P-384 for key establishment and ECDSA P-384 for signatures. CNSA 2.0 replaces these entirely with post-quantum algorithms: ML-KEM-1024 for key establishment and ML-DSA-87 for signatures. CNSA 1.0 algorithms are no longer approved for NSS use under CNSA 2.0. The transition is not additive; CNSA 2.0 replaces CNSA 1.0, it does not supplement it.
Does CNSA 2.0 apply to commercial blockchain companies?
CNSA 2.0 directly mandates compliance only for National Security Systems and their operators. Commercial blockchain companies are not directly subject to CNSA 2.0 unless they operate under a federal contract requiring it. However, any blockchain infrastructure seeking to serve government agencies or defence contractors will encounter CNSA 2.0 as a procurement requirement. The practical effect is that the government market requires CNSA 2.0 compliance, while the commercial market is moving toward NIST FIPS compliance as a baseline.
Which ML-DSA parameter set does CNSA 2.0 require?
CNSA 2.0 requires ML-DSA-87, the highest parameter set in FIPS 204. This corresponds to NIST security level 5, equivalent to AES-256 post-quantum security. The signature size is 4,595 bytes and the public key is 2,592 bytes. Most commercial applications use ML-DSA-44 (level 1, 2,420-byte signature) or ML-DSA-65 (level 3, 3,309-byte signature), which are FIPS-compliant but not CNSA 2.0 compliant.
What is the NSA CNSA 2.0 deadline for software applications?
For software applications running on National Security Systems: CNSA 2.0 algorithm support must be available in new systems by 2025, and exclusive use of CNSA 2.0 algorithms (no classical algorithms) must be in place by 2030. Existing systems should have a documented transition plan. The 2033 deadline applies to encrypted data-at-rest where legacy interoperability requirements make earlier transition more difficult.
Is SHA-256 CNSA 2.0 compliant?
No. CNSA 2.0 approves SHA-384 and SHA-512 for hashing. SHA-256 is not in the CNSA 2.0 approved list. This has direct implications for blockchain systems where SHA-256 is embedded in the consensus protocol (Bitcoin, many EVM chains use keccak256 variants). For hash functions used in non-consensus contexts (TLS handshakes, API authentication, data integrity checks), upgrading to SHA-384 or SHA-512 is required for CNSA 2.0 compliance.
