Architecting the CNSA 2.0 Transition Strategies

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.

Post-quantum code signing, defined: signing software and firmware with an algorithm resistant to attack by a quantum computer, currently ML-DSA (FIPS 204) or the stateful hash-based LMS/XMSS (NIST SP 800-208), typically run alongside a classical algorithm during the transition so both current and not-yet-upgraded verifiers can still validate the artifact.

Key Takeaways

ML-KEM (FIPS 203) and ML-DSA (FIPS 204) are not interchangeable: ML-KEM is a key encapsulation mechanism for establishing shared secrets, ML-DSA is a signature algorithm. Code signing uses ML-DSA or LMS/XMSS, never ML-KEM.
FIPS 203, 204, and 205 have been final NIST standards since August 2024; NIST SP 800-208 (LMS/XMSS) has been final since 2020. What’s still uneven is ecosystem support, HSM firmware, certificate authorities, and signature verifiers.
A single, combined “composite” post-quantum/classical signature format for X.509 is still an IETF Internet-Draft (draft-ietf-lamps-pq-composite-sigs, not yet an RFC as of 2026); today’s practical hybrid pattern for code signing is dual, parallel detached signatures, not a composite signature.
Verifier compatibility, not signer capability, is usually the real bottleneck: an artifact can be signed with ML-DSA today, but only verified by platforms that have added support for it.
Software and firmware signing carries CNSA 2.0’s earliest deadline (support and prefer: 2025, already passed); see the dated transition timeline below for every other system category.

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

Standards Status: What’s Final vs. What’s Still Emerging

Not everything labeled “post-quantum” is at the same stage of maturity, and conflating a finalized algorithm standard with an in-progress ecosystem feature is one of the most common planning mistakes. It helps to separate the algorithm standard itself from the surrounding infrastructure that has to catch up to it.

Item	Status	Since / Notes
FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)	Final NIST standards	Published August 13, 2024
NIST SP 800-208 (LMS, XMSS)	Final NIST recommendation	Published October 2020
Composite (single, combined) post-quantum/classical signatures for X.509	IETF Internet-Draft, not yet an RFC	draft-ietf-lamps-pq-composite-sigs, actively revised through 2026; do not build production systems assuming a stable wire format yet
HSM firmware support for FIPS 203/204/205 and SP 800-208	Uneven, vendor- and model-specific	Major vendors shipped initial support in 2025 to 2026 firmware releases; confirm per model, do not assume
Public code-signing CA support for ML-DSA/LMS certificate profiles	Limited and still developing	Verify with your CA before assuming a publicly trusted PQC code-signing certificate is available today
OS and platform signature verifiers (e.g., Authenticode-style verification)	Largely does not yet recognize PQC signatures	This is why dual, parallel signing is the practical pattern today, not a replacement of the classical signature

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. For the specific formats a signing platform needs to cover across that device fleet, see We Counted Every Format CodeSign Secure Can Sign; for how algorithm choice connects to build provenance, see Strengthening Supply Chain Security with SLSA Level 3 and Code Signing.

Hybrid and Parallel Signing Patterns

“Hybrid signing” gets used loosely, and the distinction between its two actual meanings matters for what you can deploy today.

Dual, parallel detached signatures are the practical pattern available now: the artifact is signed twice, once with a classical algorithm (RSA or ECDSA) and once with a post-quantum algorithm (ML-DSA or LMS), and both signatures travel with the artifact as separate, independent signature blocks. A verifier that only understands the classical algorithm checks that signature and ignores the one it doesn’t recognize; a verifier that has been updated to understand the post-quantum signature can check both. Neither signature depends on the other, which is exactly why this pattern works with today’s mixed, partially-upgraded verifier landscape.

Composite signatures, a single cryptographic signature that mathematically binds a classical and a post-quantum algorithm together into one value, are a different and more tightly integrated approach, and they are not yet a finalized standard for X.509 use. The relevant specification, draft-ietf-lamps-pq-composite-sigs, remains an IETF Internet-Draft as of 2026, still being revised, not yet an RFC. Building production tooling against an unfinished wire format risks needing to re-sign or re-issue certificates once the format stabilizes. For code signing specifically, dual parallel signatures are the lower-risk choice today; composite signatures are worth tracking, not yet worth depending on.

Migration Dependencies

A CNSA 2.0 signing migration has a real dependency order, and starting out of sequence is a common way to burn a pilot on a problem that was never about signing at all.

HSM firmware or hardware support for the target algorithm (ML-DSA, LMS, or XMSS) has to be confirmed and, if needed, updated first; you cannot generate or use keys the HSM doesn’t support.
Certificate authority and certificate profile support comes next, if the use case requires a certificate at all (LMS/XMSS firmware signing often uses embedded public keys instead). Confirm your CA can issue a certificate encoding the algorithm you intend to use before assuming it can.
Signing toolchain and CI/CD integration support has to exist, the pipeline needs to be able to invoke the new algorithm through your signing platform or HSM API.
Verifier and platform support is checked last but should be evaluated first conceptually: if the systems that will check the signature can’t recognize the new algorithm, dual signing is not optional, it’s the only way the artifact stays usable.
Only once all four are confirmed does a pilot deployment make sense; see the Transition Architecture phases below.

Verification Compatibility

This is the limitation most transition plans underweight. An artifact can be correctly signed with ML-DSA or LMS today, but that signature is only useful if something on the other end can verify it. Mainstream OS-level Authenticode-style verification does not, as of this writing, natively recognize post-quantum signatures; the classical signature on a dual-signed artifact is what most deployed verifiers will actually check for the foreseeable near term. Internal or custom verification tooling you control can be updated to check the post-quantum signature explicitly, which is why dual signing today serves two different audiences at once: external, unmodified verifiers get the classical signature they already understand, and internal or forward-looking verification systems can additionally validate the post-quantum signature for genuine quantum-resistant assurance. Confirm, rather than assume, which category each of your actual verifiers falls into before treating a pilot as representative of production.

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.

HSM Readiness Checklist

Confirmed, per model, whether current firmware supports ML-DSA and/or LMS/XMSS key generation and signing, not just a vendor’s general roadmap statement.
Identified whether a firmware update adds support or whether hardware replacement is required, and gotten a specific target date from the vendor.
Verified the HSM’s performance under the new algorithms; larger keys and signatures can change throughput in ways worth measuring before committing to a rollout timeline.
Confirmed crash-consistent state management for LMS/XMSS specifically, since a lost or rewound signing state can compromise the key entirely.
Checked that the signing platform or CI/CD plugin sitting in front of the HSM has actually been updated to call the new algorithm, not just that the HSM itself supports it.

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.

Testing and Validation

Beyond the pilot described in Phase 4, a few specific checks deserve explicit test coverage before any dual-signed artifact ships broadly:

Verify against every verifier the artifact will actually encounter in production, not just the one used during development, since verifier behavior on an unrecognized additional signature is not guaranteed to be identical across platforms.
Measure the size impact of larger post-quantum keys and signatures on artifact size, download time, and any size-constrained distribution channel (embedded update mechanisms in particular).
Confirm timestamp compatibility; a trusted timestamp needs to remain valid and verifiable regardless of which signature algorithm it’s attached to.
Load-test signing throughput under the new algorithm if release volume is high, since ML-DSA and LMS/XMSS have different performance characteristics than RSA or ECDSA.

Rollback

Because dual, parallel signing adds a second, independent signature rather than replacing the first, rollback during the pilot and early rollout stages is comparatively low-risk: if the added post-quantum signature causes an unexpected verification failure somewhere in the field, the classical signature is still present and valid, and the fix is to stop attaching the second signature for that artifact stream while the incompatibility is resolved, not to re-issue or revoke anything. The situation is different once an environment reaches its “exclusively use” date and the classical signature has actually been dropped; at that point, rollback means re-enabling dual signing temporarily while the underlying verifier gap is fixed, which is one more reason not to fully retire the classical signature until verifier coverage has been confirmed across every consumer of the artifact, not assumed.

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.

Frequently Asked Questions

Is ML-KEM the same as ML-DSA?

No. ML-KEM (FIPS 203) is a key encapsulation mechanism used to establish a shared secret for encryption; ML-DSA (FIPS 204) is a digital signature algorithm. They solve different problems and are not interchangeable. Code signing uses ML-DSA or the stateful hash-based LMS/XMSS, never ML-KEM.

What’s the difference between hybrid and composite post-quantum signatures?

Hybrid, as practiced today, means dual, independent, parallel signatures, one classical and one post-quantum, attached to the same artifact. Composite means a single signature value that mathematically combines both algorithms; the relevant IETF specification for composite ML-DSA signatures is still an Internet-Draft, not a finalized RFC, as of 2026.

Can current signature verifiers check an ML-DSA or LMS signature today?

It depends entirely on the specific verifier. Mainstream OS-level Authenticode-style verification largely does not yet recognize post-quantum signatures, which is why dual signing, keeping the classical signature alongside the new one, is the practical approach rather than replacing it outright.

Which HSMs support CNSA 2.0 algorithms today?

Major vendors including Thales Luna, Entrust nShield, and Utimaco have shipped CNSA 2.0 support in 2025 and 2026 firmware releases, but support varies by specific model. Confirm current firmware capability directly with the vendor for your exact HSM model rather than assuming suite-wide support.

What happens if a dual-signed artifact fails verification somewhere in the field?

Because the classical signature is still present and independent, the artifact typically remains valid to verifiers that only check the classical signature. The response is to pause adding the post-quantum signature for that artifact stream while the specific incompatibility is diagnosed, not to revoke or re-issue anything.

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.