The National Security Agency’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) is the most operationally specific roadmap any government has published for navigating this transition. While National Security Memorandum 10 (NSM-10) sets the aspirational goal of making National Security Systems quantum-resistant by 2035, CNSA 2.0 translates that goal into concrete instructions: use ML-KEM-1024 for key establishment, ML-DSA-87 for signatures, support these algorithms in your products by specific dates, and stop using the old ones by others.
The deadlines are no longer comfortably distant. The earliest of them, covering software and firmware signing, called for organizations to prefer CNSA 2.0 algorithms by 2025, a milestone that has already passed. From January 1, 2027, all new acquisitions for National Security Systems must support CNSA 2.0 algorithms.
This blog breaks down the CNSA 2.0 algorithm suite, the full transition timeline, the enforcement mechanisms that make these deadlines binding, and a practical five-phase strategy for architecting the migration without disrupting your operations.
What CNSA 2.0 Is and Why It Exists
CNSA 2.0 is the NSA’s cryptographic algorithm guidance for protecting National Security Systems (NSS), which include classified and unclassified systems that handle national security information, military command and control, intelligence, and related functions. It was first announced on September 7, 2022, and updated to version 2.1 in December 2024 after NIST published the final post-quantum FIPS standards in August 2024.
The reason CNSA 2.0 exists comes down to a single, well-understood threat. The public-key algorithms in use across nearly all systems today, RSA and elliptic-curve cryptography (ECC), rely on mathematical problems that classical computers cannot solve in any practical timeframe. A sufficiently powerful quantum computer running Shor’s Algorithm can solve those same problems efficiently, rendering RSA and ECC signatures and key exchanges insecure.
This creates two distinct risks. The first is forward-looking: once a Cryptographically Relevant Quantum Computer (CRQC) exists, any system still relying on RSA or ECC is immediately vulnerable. The second is happening now: adversaries are capturing and archiving encrypted data and signed communications today, with the intent of decrypting or forging them once a CRQC becomes available. This is the “Harvest Now, Decrypt Later” threat, and it means that data with confidentiality requirements extending beyond the CRQC arrival window is already at risk, regardless of how strong today’s encryption appears.
CNSA 2.0 replaces the earlier CNSA 1.0 suite, which was built on RSA, ECDH, ECDSA, and AES. CNSA 2.0 retains the symmetric and hash primitives that remain quantum-resistant and replaces the quantum-vulnerable public-key algorithms with NIST-standardized post-quantum alternatives.
CNSA 2.0 Algorithm Suite
CNSA 2.0 specifies exact algorithms and, critically, exact parameter sets for each use case. One of the defining characteristics of the suite is that it mandates only the highest NIST security levels. Lower parameter sets, even though NIST standardized and approved them for general use, are not permitted for National Security Systems.
| Function | CNSA 2.0 Algorithm | Standard | Notes |
|---|---|---|---|
| Key Establishment | ML-KEM-1024 | FIPS 203 | Formerly CRYSTALS-Kyber; NIST Security Level 5 only. ML-KEM-512 and ML-KEM-768 are not approved for NSS |
| Digital Signatures (general) | ML-DSA-87 | FIPS 204 | Formerly CRYSTALS-Dilithium; highest parameter set only. ML-DSA-44 and ML-DSA-65 are not permitted for NSS. Used for all signing including software and firmware |
| Software and Firmware Signing | LMS or XMSS | NIST SP 800-208 | Stateful hash-based signatures. NSA recommends LMS with SHA-256/192. ML-DSA-87 is also approved for this use case |
| Symmetric Encryption | AES-256 | FIPS 197 | Retained from CNSA 1.0; quantum-resistant at 256-bit key length |
| Hashing | SHA-384 or SHA-512 | FIPS 180-4 | CNSA 2.0 added SHA-512 as an approved option alongside SHA-384 |
Transition Timeline
CNSA 2.0 defines two milestones for each category of system: a “support and prefer” date, by which systems must be capable of using CNSA 2.0 algorithms and should default to them, and an “exclusively use” date, after which CNSA 1.0 algorithms are no longer permitted. The schedule is deliberately staggered, front-loading the categories that are hardest to update after deployment.
| System Category | Support and Prefer | Exclusively Use |
|---|---|---|
| Software and Firmware Signing | 2025 (passed) | 2030 |
| Networking Equipment (VPNs, routers) | 2026 | 2030 |
| Operating Systems | 2027 | 2033 |
| Web Browsers, Servers, Cloud Services | 2025 (passed) | 2033 |
| Niche and Legacy Equipment | Update or replace by 2033 | 2033 |
| All NSS (full transition) | Ongoing | 2035 (per NSM-10) |
Why Software and Firmware Signing Carries the Earliest Deadline
It is not an accident that software and firmware signing has the earliest “support and prefer” deadline in the entire CNSA 2.0 schedule. There is a specific architectural reason: firmware roots of trust are the hardest components to update after a device is deployed.
When a device is manufactured, its firmware verification keys are often embedded in hardware, sometimes fused into the chipset itself in a way that cannot be changed later. If those keys are based on a quantum-vulnerable algorithm, the device carries that vulnerability for its entire operational life. For devices with service lives measured in decades, including military hardware, industrial controllers, and embedded systems, a signing key chosen today may still be in use well past the point where a CRQC is expected to exist.
This creates a compounding risk specific to firmware. An attacker who can recover the signing key, either from archived signing traffic or by breaking the algorithm directly with a CRQC, could sign malicious firmware that every deployed device would accept as legitimate. Because firmware sits below the operating system and below every software-level security control, a forged firmware signature is among the most dangerous attacks possible.
This is why the NSA has urged vendors to begin adopting LMS and XMSS immediately since the original 2022 advisory, well ahead of the broader transition. Stateful hash-based signatures like LMS and XMSS are well understood, conservative in their security assumptions, and quantum-resistant. They are particularly suited to the firmware use case where the signing operation is infrequent and controlled, which mitigates the operational complexity of managing stateful keys.
For organizations building products that include firmware, the practical implication is that signing infrastructure is the first thing to migrate. The device you ship today with classical signing is the device that will be carrying that vulnerability into the 2030s and beyond.
Transition Architecture
A CNSA 2.0 migration is not a single project with a defined end. It is a multi-year program that touches cryptographic inventory, infrastructure, signing operations, and governance. The following five-phase strategy provides a structured path that organizations can adapt to their own scale and timeline.
Phase 1: Cryptographic Discovery and Inventory
You cannot migrate cryptography you have not identified. The first and most foundational phase is building a complete inventory of every place classical cryptography is used across the organization: every certificate, every signing key, every TLS endpoint, and every embedded cryptographic dependency in software and hardware.
Encryption Consulting’s CBOM Secure which will help your organisation in making an inventory, for each cryptographic asset, the algorithm and parameter set in use, where it is deployed, what depends on it, who owns it, and what its replacement path looks like. Cryptographic dependencies are buried in places that are easy to miss: third-party libraries, hardware security module configurations, legacy applications, and vendor products whose internals are not visible.
Phase 2: Prioritization and Risk Assessment
With a complete inventory, the next phase is prioritizing what to migrate first based on risk and deadline. The CNSA 2.0 timeline provides the deadline structure, but organizations should layer their own risk assessment on top of it.
The highest-priority assets are those that combine an early CNSA 2.0 deadline with long-lived exposure. Firmware signing keys for devices with multi-decade service lives sit at the top of this list: they carry the earliest deadline and the longest exposure window. Data and signatures protecting information with long confidentiality or integrity requirements come next, because of the Harvest Now, Decrypt Later threat. Lower-priority assets are those with short lifecycles and later deadlines, where waiting for more mature tooling carries little risk.
Phase 3: Infrastructure and Tooling Readiness
Phase 3 prepares the infrastructure that will carry CNSA 2.0 operations. The central question for most organizations is HSM readiness. CNSA 2.0 requires that keys be protected in validated hardware, and most legacy HSMs need firmware updates to support ML-KEM, ML-DSA, LMS, and XMSS.
For each HSM in the environment, organizations should confirm with the vendor whether current firmware supports CNSA 2.0 key generation, storage, and signing operations; whether firmware can be updated to add support or whether hardware replacement is required; and what the target release date is for FIPS 203, 204, and 205 compliant firmware. Major vendors including Thales Luna, Entrust nShield, and Utimaco have been shipping CNSA 2.0 support in 2025 and 2026 firmware updates, but support varies by specific model and must be verified rather than assumed.
This phase also includes validating that signing toolchains, CI/CD pipelines, certificate authorities, and verification systems can produce and validate CNSA 2.0 signatures.
Phase 4: Hybrid Deployment and Pilot
The recommended approach during the transition is hybrid deployment rather than immediate wholesale replacement. Hybrid signing and hybrid key exchange apply both a classical algorithm and a CNSA 2.0 algorithm in parallel, so that systems capable of post-quantum verification get quantum-resistant protection while legacy systems that have not yet migrated continue to function.
Phase 4 puts this into practice through pilot deployments. Start with a controlled, lower-risk product line or system, deploy hybrid signing or hybrid key exchange, and validate that the artifacts and connections work correctly across the full range of verification infrastructure they will encounter. This is where the edge cases surface: verification tools that do not yet understand CNSA 2.0 signatures, performance impacts from larger key and signature sizes, and integration issues in the signing pipeline. Resolving these in a pilot is far less costly than discovering them in production.
Phase 5: Full Migration and Legacy Decommissioning
The final phase scales the validated approach across the full environment and progressively retires classical-only cryptography. As verification infrastructure matures and CNSA 2.0 support becomes universal across the organization’s systems, the classical component of hybrid deployments can be deprecated according to the “exclusively use” deadlines in the CNSA 2.0 schedule.
This phase also includes decommissioning or replacing the niche and legacy equipment that cannot be migrated in place, which CNSA 2.0 expects to be addressed by 2033. These are often the most resource-intensive changes and should be planned well in advance of the deadline.
How Encryption Consulting Can Help
The CNSA 2.0 transition spans cryptographic discovery, infrastructure readiness, signing operations, and long-term governance. Encryption Consulting’s product portfolio and advisory services are designed to support organizations across every phase of that journey.
PQC Advisory Services: Our Post-Quantum Cryptographic Advisory Services provide the strategic foundation for a CNSA 2.0 migration. We help organizations assess their current cryptographic posture, build the migration roadmap aligned to the CNSA 2.0 timeline, prioritize assets by risk and deadline, and design the crypto-agile architecture that makes both this transition and future ones manageable.
CBOM Secure: Phase 1 of any CNSA 2.0 migration is discovery, and you cannot migrate what you cannot see. CBOM Secure performs continuous cryptographic discovery across your entire environment, building the complete, current inventory of certificates, keys, and cryptographic dependencies that the migration depends on. It identifies exactly which assets use quantum-vulnerable algorithms and need to be brought under the CNSA 2.0 transition, turning the foundational discovery phase from a manual, error-prone exercise into an automated, repeatable one.
CodeSign Secure: Because software and firmware signing carries the earliest CNSA 2.0 deadline, signing infrastructure is where many organizations need to act first. CodeSign Secure supports the CNSA 2.0 signing algorithms in production: ML-DSA at the required parameter levels and LMS for firmware signing, all backed by FIPS-validated HSMs from Thales, Entrust, Utimaco, and Securosys. The platform also enforces the key protection, role-based access control, and audit logging that NSS signing governance requires.
Conclusion
CNSA 2.0 represents the most concrete, operationally specific post-quantum migration roadmap any government has published. It names exact algorithms, exact parameter sets, and exact dates, and it backs those dates with enforcement mechanisms that make compliance a condition of validation, certification, and procurement.
The organizations that will navigate this transition successfully are the ones treating it as a structured, multi-year program: discovering their cryptographic inventory, prioritizing by risk and deadline, preparing their infrastructure, deploying hybrid approaches during the transition, and building for crypto-agility so that the next cryptographic change is far less painful than this one. Signing infrastructure, with its early deadline and long exposure window, is the right place to start.
At Encryption Consulting, our advisory services and product portfolio, from CBOM Secure for discovery to CodeSign Secure for CNSA 2.0 signing, are built to support that journey from the first inventory to the final decommissioning. If your organization is assessing its CNSA 2.0 readiness, we would be glad to help you architect the path forward.
