The National Security Agency published the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) in September 2022, then issued the formal CNSA 2.0 Cybersecurity Advisory and accompanying FAQ that lay out a multi year migration. CNSA 2.0 governs how National Security Systems (NSS), and the contractors that build them, encrypt classified and controlled data. If you sell software, hardware, or services into the Department of Defense, the Intelligence Community, or any agency that processes NSS information, the CNSA 2.0 deadlines decide when your product becomes ineligible.
This article walks through every milestone in the published NSA timeline, explains what each one means in practice, and shows how vendors and integrators should sequence work to avoid being caught short. Dates and algorithms come directly from the NSA Cybersecurity Advisory CNSA 2.0 Timing and Transition Guidance and the NSA CNSA 2.0 FAQ.
What CNSA 2.0 Is and Why the Calendar Matters
CNSA 2.0 is the NSA approved cryptography catalog for protecting NSS, which the Committee on National Security Systems Policy 15 defines as systems handling classified, intelligence, or military command and control information. CNSA 2.0 superseded the earlier CNSA 1.0 (sometimes still called Suite B in casual conversation, though Suite B was retired earlier).
Two things make the timeline unusually firm. First, CNSA is not a recommendation. Once a deadline passes, an NSS that still uses a deprecated algorithm is non compliant by definition, and the contracting officer will say so. Second, the algorithms named are very specific. CNSA 2.0 does not say "use a post quantum algorithm". It says use ML-KEM-1024, ML-DSA-87, AES-256, and SHA-384 or SHA-512. Anything else is out of scope.
The 2035 endpoint is the headline date, but procurement officers care more about the earlier gates. By 2027, certain new acquisitions must already ship with the new algorithms, so the contract you sign in 2026 needs to commit to that.
Software and Firmware Signing: 2025
The earliest deadline applies to software signing and firmware signing. NSA stated that CNSA 2.0 algorithms must be supported and preferred for signing software and firmware delivered to NSS by 2025, with full transition by 2030.
Software signing was placed first because the threat model is different from confidentiality. A signed binary delivered today is verified for years. If an adversary harvests a signing public key now and later forges signatures with a quantum computer, the entire fleet that trusts that key has to be re imaged. That makes signing a bigger crypto agility problem than confidentiality, because rotating roots of trust across embedded devices is painful.
The recommended algorithms for signing are ML-DSA-87 and, where stateful hash based signatures are acceptable, LMS or XMSS at SHA-256 with at least 192 bit security. SLH-DSA is also approved as an alternative.
New NSS Acquisitions: 2027
CNSA 2.0 sets 2027 as the year by which new acquisitions of NSS networking equipment, web browsers, and servers must support and prefer CNSA 2.0 algorithms. This is the first horizontal deadline that touches the entire NSS supply chain, not just signing pipelines.
In practice, a contracting officer in 2027 cannot accept a delivery of a virtual private network appliance, a Transport Layer Security terminating load balancer, or an enterprise web browser configured for NSS users that lacks ML-KEM-1024 and ML-DSA-87 support. Vendors that miss this window will lose their place on approved product lists.
Browsers are called out explicitly because key encapsulation runs through TLS, and TLS termination at the browser is the largest population of cryptographic endpoints inside any agency. If a browser cannot speak hybrid X25519 plus ML-KEM, every site reachable from that browser quietly downgrades to classical only crypto.
Networking Equipment Full Use: 2030
By 2030 NSA requires full use of CNSA 2.0 algorithms for networking equipment. "Full use" means production traffic, not just optional support. Existing fielded gear must be either replaced or firmware updated to put CNSA 2.0 algorithms on the wire. Hybrid configurations that combine ML-KEM with X25519 or P-384 are explicitly permitted as transitional, which we have written about in our hybrid encryption guide.
The 2030 networking gate is the deadline that drives VPN, Internet Protocol Security, Media Access Control Security, and TLS 1.3 vendor roadmaps. All four protocols require either an Internet Engineering Task Force draft or a finalized Request for Comments specifying how ML-KEM is encapsulated. That work began in 2023 and continues through ETSI and the IETF Crypto Forum Research Group.
Operating Systems and Custom Software: 2030 to 2033
Operating systems used in NSS environments must support and prefer CNSA 2.0 algorithms by 2030, with full transition by 2033. This affects kernel cryptography (Linux Kernel Crypto API, Microsoft Cryptography Next Generation), filesystem encryption (BitLocker, dm-crypt, Apple FileVault), boot integrity (Secure Boot, Trusted Platform Module attestation), and system signing for kernel modules.
Custom application software follows the same 2033 deadline. Every internal Department of Defense web service, every desktop tool a system administrator wrote in Python, every batch job processing classified telemetry must either be retired or migrated by then.
Niche Equipment: 2033 to 2035
Equipment categories that are slow to refresh, including industrial control systems, certain weapons platforms, and embedded modules with field service lives measured in decades, get until 2033 to support and prefer CNSA 2.0, and until 2035 for full use. This is the longest runway and is also the deadline most often quoted in industry. The NSA FAQ is explicit that 2035 is the endpoint, not a soft target.
The reason for the longer tail is replacement economics. A satellite cryptographic module designed in 2018 cannot be reflashed remotely. A naval system may go years between dry dock periods. Allowing until 2035 acknowledges these realities while still creating an ironclad cutoff.
Required Algorithms in CNSA 2.0
CNSA 2.0 names a tight set of algorithms. The advisory and FAQ call out the following as required:
- Symmetric encryption: AES-256 only, in CTR, GCM, or other approved modes (per CNSSP-15)
- Hashing: SHA-384 or SHA-512 (SHA-256 is permitted only inside LMS or XMSS)
- Key encapsulation: ML-KEM-1024, formally specified in NIST FIPS 203
- Digital signatures: ML-DSA-87, formally specified in NIST FIPS 204
- Software and firmware signing alternatives: LMS or XMSS with SHA-256 at 192 bit security, or SLH-DSA per NIST FIPS 205
The advisory deliberately drops RSA at any size, all elliptic curve cryptography including P-256 and P-384, and all classical Diffie-Hellman variants. We covered the consequences of that choice in why RSA-2048 will break.
What "Support and Prefer" Actually Means
The phrase "support and prefer" appears at every milestone before "full use". It has an operational meaning. A product that supports the algorithm has it available and turned on by default for new sessions. A product that prefers the algorithm offers it first in a negotiation, falls back to legacy only if the peer cannot handle it, and logs the fallback. By contrast, "full use" means there is no fallback. Legacy is rejected.
Contracting officers will demand evidence at audit time. That evidence usually takes the form of FIPS 140-3 validation certificates listing the new algorithms, vendor configuration documentation, and packet captures showing ML-KEM in actual TLS or IPsec handshakes. We discuss the validation pipeline in our CMVP and FIPS 140-3 article.
Hybrid Mode Is Allowed
NSA explicitly permits hybrid implementations during the transition. A hybrid handshake combines a classical algorithm such as X25519 or P-384 with ML-KEM. The shared secret is derived from both, so an attacker has to break both to recover plaintext. This is the architectural pattern that QNSQY uses, because it preserves classical security guarantees while adding NIST post quantum protection.
The FAQ clarifies that hybrid is allowed but not required, and that pure ML-KEM is also acceptable. The agency's preference is for vendors to ship hybrid as a default during the 2027 to 2033 window, then transition to pure post quantum as confidence grows.
What This Means for Vendors Selling Into NSS
Three points matter for vendor planning. First, the FIPS 140-3 validation queue is finite and slow. Modules that need to ship in 2027 must be in the Cryptographic Module Validation Program queue by 2025 or early 2026 at the latest, because the average validation time exceeds eighteen months. Second, key management infrastructure (Hardware Security Modules, certificate authorities, key escrow systems) takes longer than application code to migrate, and most NSS programs will not let you ship application support without a validated key management story. Third, training and documentation lag behind code. Plan for a six month soak after engineering finishes before contracting officers will actually buy the product.
For the rest of the federal civilian sector, see our 2035 NSA CNSA deadline plan, which covers the parallel migration mandates issued by the Office of Management and Budget and CISA.
What This Means for Customers Buying NSS Equipment
Customers should write contract language that requires CNSA 2.0 algorithm support today, prefers it by the relevant procurement gate, and locks in firmware update commitments through 2035. Avoid signing multi year deals that lock you into pre CNSA 2.0 cryptography without a migration clause, because the cost of swapping a non compliant box mid contract falls on the buyer.
Federal civilian agencies should track parallel mandates from the Office of Management and Budget memo M-23-02 (PQC Inventory) and the National Security Memorandum 10. The deadlines differ slightly from CNSA 2.0 but the algorithm choices are aligned.
Watch Items Each Year
A program manager tracking CNSA 2.0 readiness should monitor a small set of indicators each year. In 2025, watch for the first FIPS 140-3 module validations including ML-KEM and ML-DSA. In 2026, watch for IETF RFC publication of TLS hybrid key exchange and IKEv2 ML-KEM support. In 2027, watch for vendor product announcements aligned with the procurement gate. In 2028 and beyond, watch for CNSS Policy 15 updates that may further refine implementation guidance.
Programs that depend on third party cryptographic modules should also track CMVP queue announcements, because the validation pipeline is the bottleneck for ratification of vendor PQC support. A vendor that submits in 2025 may not get a certificate until 2026 or 2027, and that window matters for procurement officers planning 2027 deliveries.
FAQ
Q: Is CNSA 2.0 mandatory or recommended? A: For National Security Systems and for contractors building or operating them, CNSA 2.0 is mandatory once each deadline passes. For non NSS federal systems, the mandate flows through OMB and CISA guidance and references CNSA 2.0 algorithms.
Q: Can I keep using RSA 2048 or RSA 4096 inside NSS? A: No. CNSA 2.0 drops RSA at every key size for confidentiality and signing. The only RSA usage that may persist is verification of legacy archived signatures, and even that has a 2035 endpoint.
Q: What if my product needs FIPS 140-3 validation? A: ML-KEM, ML-DSA, and SLH-DSA are eligible for FIPS 140-3 validation under the Cryptographic Module Validation Program. The submission queue is significant. Plan eighteen months minimum from submission to certificate issuance.
Q: Does CNSA 2.0 require pure post quantum or is hybrid acceptable? A: Hybrid is acceptable and encouraged during the transition. The FAQ permits hybrid combining ML-KEM with X25519 or P-384, and pure ML-KEM is also allowed.
Q: How does CNSA 2.0 differ from NIST FIPS 203 and 204? A: NIST FIPS 203, 204, and 205 are the algorithm specifications. CNSA 2.0 selects which of those algorithms apply at which security level for NSS. CNSA 2.0 also names AES and SHA parameter choices that NIST does not mandate.
Sources
- NSA Cybersecurity Advisory, Commercial National Security Algorithm Suite 2.0 (September 2022). https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
- NSA, Announcing the Commercial National Security Algorithm Suite 2.0 FAQ. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
- NIST, FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024). https://csrc.nist.gov/pubs/fips/203/final
- NIST, FIPS 204, Module-Lattice-Based Digital Signature Standard (August 2024). https://csrc.nist.gov/pubs/fips/204/final
- NIST, FIPS 205, Stateless Hash-Based Digital Signature Standard (August 2024). https://csrc.nist.gov/pubs/fips/205/final
- CNSS Policy 15, National Information Assurance Policy on the Use of Public Standards. https://www.cnss.gov
Related Articles
- Why RSA-2048 Will Break
- Hybrid Encryption: Why You Need Both Classical and PQC
- NIST FIPS Guide to Post Quantum Standards
- 2035 NSA CNSA Deadline Migration Plan
- PQC for Government and Defense
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.