Quantum-Proof with CNSA 2.0

It’s no secret that a cryptographically relevant quantum computer (CRQC) would have the power to break widely used public-key cryptographic systems which are currently used for asymmetric key exchanges and digital signatures with potentially devastating impact to systems. National security systems (NSS) use public key cryptography as a critical component to protect the confidentiality, integrity, and authenticity of national security information. 

Anne Neuberger, the White House’s top cyber advisor, recently spoke about this at the Royal United Services Institute (RUSI) in London. She said that releasing these new algorithms was “a momentous moment” because it shows real progress in moving toward the next generation of cryptography. 

She explained that the reason for this shift is the concern over CRQCs, which, as she put it, could break the encryption “that’s at the root of protecting both corporate and national security secrets.” 

Let’s understand what is Commercial National Security Algorithm Suite 2.0 (CNSA 2.0).

CNSA 2.0

The CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is the next-generation encryption standard developed by the NSA to protect the nation’s most sensitive systems, especially as quantum computing becomes a real threat. These algorithms are specially designed to be quantum-resistant, ensuring long-term security even in a future where traditional encryption could be broken.  

CNSA 2.0 will be mandatory for all National Security Systems (NSS) that use public-standard algorithms, whether they are newly designed or already deployed. Older encryption sets like Suite B or CNSA 1.0 will no longer be enough, all must transition to CNSA 2.0. As the NSA puts it, this move ensures systems are “secure today and resilient tomorrow.” 

What policies should be followed to meet NSS algorithm requirements?

The algorithms included in CNSA 2.0 were chosen from those standardized by NIST, the U.S. government’s official authority for commercial encryption. NSA selected the best-performing options for national security needs, not just strong, but optimized for mission-critical operations. The NSA has tested and analyzed these algorithms and believes they are strong enough to protect U.S. national security for the long haul.

The agency considers CNSA 2.0 fit to guard everything from battlefield comms to diplomatic cables. They are not leaving users in the dark. The NSA is working with the IETF to publish RFCs (Requests for Comments), technical guides that will help integrate these algorithms securely into real-world systems. The guiding principle here is, that it’s not just about what algorithms you use, it’s how you use them. 

Even systems that are already up and running aren’t spared. Unless they receive a formal waiver, all fielded equipment must be upgraded in a timely manner. This rule is backed by key security memos like NSM-8, NSM-10, and policies such as CNSSP 11 and CNSSP 15. 

Different types of systems will follow different transition paths. Military-grade or “high-grade” devices will shift according to CJCSN 6510 and CNSSAM 01-07-NSM, while commercial equipment will stay on CNSA 1.0 for now but must switch over between 2025 and 2030, depending on the system. All QR implementations will have to go through NIAP certification and NIST validation, no shortcuts allowed. 

This guidance is not only for government insiders. The NSA is making the CNSA 2.0 plan public so that vendors, industry partners, and anyone looking to interact with NSS can start preparing. That includes updating devices, software, and secure communication platforms.  

As the NSA moves forward with CNSA 2.0, there’s also a cleanup of technical terms. Algorithms like ML-KEM and ML-DSA are now the only approved names under the standard, replacing their pre-standard labels CRYSTALS-Kyber and CRYSTALS-Dilithium. Only the finalized versions, published as FIPS 203 and 204 are allowed. Any older or tweaked versions, even if labeled similarly, do not meet CNSA 2.0 compliance. 

The following table lists the algorithms and their functions, specifications, and parameters. 

Algorithm	Function	Specification	Parameters
General Purpose Algorithms
Advanced Encryption Standard (AES)	Symmetric block cipher for information protection	FIPS PUB 197	Use 256-bit keys for all classification levels.
ML-KEM (previously CRYSTALS Kyber)	Asymmetric algorithm for key establishment	FIPS PUB 203	ML-KEM-1024 for all classification levels.
ML-DSA (previously CRYSTALS Dilithium)	Asymmetric algorithm for digital signatures in any use case, including signing firmware and software	FIPS PUB 204	ML-DSA-87 for all classification levels.
Secure Hash Algorithm (SHA)	Algorithm for computing a condensed representation of information	FIPS PUB 180-4	Use SHA-384 or SHA-512 for all classification levels.
Algorithms Allowed in Specific Applications
Leighton-Micali Signature (LMS)	Asymmetric algorithm for digitally signing firmware and software	FIPS PUB 800-208	All parameters approved for all classification levels. LMS SHA 256/192 is recommended.
Xtended Merkle Signature Scheme (XMSS)	Asymmetric algorithm for digitally signing firmware and software	FIPS PUB 800-208	All parameters approved for all classification levels.
Secure Hash Algorithm 3 (SHA3)	Algorithm used for computing a condensed representation of information as part of hardware integrity	FIPS PUB 202	SHA3-384 or SHA3-512 allowed for internal hardware functionality only (e.g., boot-up integrity checks)

CNSA 2.0 Transition Timeframe and Deployment Milestones

The NSA aims to make all National Security Systems (NSS) quantum-resistant by 2035, aligning with the goals set out in National Security Memorandum-10 (NSM-10). While 2035 is the end goal, the transition begins much sooner, with key milestones outlined in the updated CNSSP 15 policy. 

For existing systems, any NSS that is already validated under a NIAP or CSfC profile will remain approved until the end of its validation period. No mandatory transition to CNSA 2.0 will be enforced before December 31, 2025. However, any NSS not already compliant with CNSA 1.0 has just six months from the release of the updated CNSSP 15 to become CNSA 2.0 compliant or must submit a waiver request within 90 days. 

From January 1, 2027, all new acquisitions for NSS will need to support CNSA 2.0 algorithms, unless an exception is clearly noted. By December 31, 2030, all equipment and services that cannot support CNSA 2.0 must be phased out. And by December 31, 2031, the use of CNSA 2.0 algorithms becomes mandatory across the board, unless explicitly exempted. 

The transition won’t happen within a day. NSA expects a hybrid period where systems may be using both CNSA 1.0 and CNSA 2.0, depending on the maturity of their respective components. New systems and upgrades should be designed to prefer CNSA 2.0, and as standards become finalized, these systems should eventually only accept CNSA 2.0 algorithms. 

Standard Development Organizations (SDOs) like IETF will continue to publish supporting material such as RFCs. NSA is actively collaborating with them to ensure these documents are available to guide protocol configurations and help vendors adopt quantum-resistant solutions effectively. 

NSA expects all equipment transitions to be completed by December 31, 2030, well ahead of the 2035 deadline, allowing secure systems to be future-ready in time for full-scale quantum threats. 

General Method for Transitioning to CNSA 2.0 Algorithms

Here are some points to consider when transitioning to CNSA 2.0 algorithms: 

• Protection profiles will be updated by NIAP to clearly state that products must support CNSA 2.0 algorithms, based on NIST and other international standards. 
• Any new hardware or software must comply with the new profiles. Older systems must also comply when they undergo their next update in order to remain NIAP certified. 
• As soon as tested and validated CNSA 2.0 solutions are ready, they should become the default configuration in all eligible systems. 
• The timeline for removing old, vulnerable algorithms will be guided by NIAP’s protection profiles and NSM-10 tech refresh cycles. 
• If legacy systems can’t be updated regularly, they’ll need an official waiver and a clear plan for future compliance to continue operating. 

Other CNSA 2.0 Requirements for NSS

Following timeline is part of NSA’s broader effort to future-proof national security systems in anticipation of powerful quantum computers. The staged rollout gives industry and agencies time to adapt. 

• Software and firmware signing must begin transitioning immediately, with CNSA 2.0 preferred by 2025 and exclusively used by 2030. 
• Web browsers, servers, and cloud services must support and prefer CNSA 2.0 by 2025 and move to exclusive use by 2033. 
• Traditional networking equipment like VPNs and routers should support and prefer CNSA 2.0 by 2026 and use it exclusively by 2030. 
• Operating systems are expected to support and prefer CNSA 2.0 by 2027 and adopt it exclusively by 2033. 
• Niche equipment, such as constrained devices and large PKI systems, should support and prefer CNSA 2.0 by 2030 and use it exclusively by 2033. 
• Custom applications and legacy systems must be updated or replaced entirely to meet CNSA 2.0 standards by 2033. 

Let’s dive into the technical details of hash-based signature algorithms and explore their significance in post-quantum cryptography (PQC). 

Understanding Hash-based Signature in CNSA 2.0

Hash-based signature schemes are a key part of CNSA 2.0’s quantum-resilient strategy, for protecting long-lived software and firmware. These algorithms are suited for tasks where a signature must remain trusted for years, such as firmware signing.  

The two main hash-based algorithms approved by the NSA for National Security Systems (NSS) are: 

• LMS (Leighton-Micali Signature Scheme) 
• XMSS (eXtended Merkle Signature Scheme) 

Both of these are standardized by NIST in SP 800-208 and have been validated under Federal Information Processing Standards (FIPS). NSA recommends using them particularly in systems that require stateful signature mechanisms, where each signature must be tracked to ensure a key isn’t reused which is a critical requirement for maintaining security over time. 

NSA prefers LMS with SHA-256 as defined in Section 4.2 of the NIST standard. This specific configuration offers a good balance of performance and security and is highly suitable for embedded devices or hardware systems that may not receive frequent updates. 

On the other hand, HSS (Hierarchical Signature Scheme) and XMSSMT (multi-tree XMSS) though related to LMS/XMSS, are not allowed in CNSA 2.0. The NSA has explicitly stated that these multi-tree variants do not meet the required standards for NSS use. 

Another algorithm, SLH-DSA (also known as SPHINCS+), is not approved at all for use in NSS under CNSA 2.0, even though it is also hash-based. This ensures that only the most thoroughly assessed and implementation-ready algorithms are trusted for national security purposes. 

Use of SHA-3 and Hash Function Policy Under CNSA 2.0

In CNSA 2.0, the use of SHA-3 is allowed only under very limited circumstances. Specifically, vendors may use SHA3-384 or SHA3-512 within internal hardware components that do not interface with external systems. This includes use cases like secure boot or system integrity checks, where the cryptographic process stays entirely within a vendor-controlled environment. NSA has made this exception to help speed up the transition to post-quantum cryptography without disrupting established internal processes. 

However, SHA-3 is not approved as a general-purpose hash function in CNSA 2.0. Its use is only permitted when clearly defined by an approved cryptographic standard, such as within LMS as specified by NIST SP 800-208, or for very specific internal applications. Similarly, SHAKE, another variant from the SHA-3 family, is also not allowed for broad cryptographic use. NSA’s position is clear that relying on SHA-3 outside its approved use cases creates unnecessary complexity, increases the burden of interoperability testing, and may undermine the reliability of systems meant to follow strict national security standards.

The SHA-2 family, especially SHA-384 and SHA-512, continues to be the backbone of CNSA 2.0’s hash function policy. SHA-384 remains the standard, while SHA-512 is permitted where performance considerations justify it, though systems using SHA-512 must carefully evaluate potential interoperability impacts.  

If a cryptographic system incorporates SHA-3 or other hash variants as part of a defined function inside an NSA-approved algorithm, such as LMS or XMSS, this is permitted, but only within the boundaries of that algorithm’s design. General or external application of SHA-3 outside these definitions remain non-compliant with CNSA 2.0. 

NSA has left the door open for the future inclusion of other NIST-approved algorithms, but only under very specific conditions: the algorithm must become widely adopted, meet NSA’s independent security assessments, and maintain compatibility with other systems. For now, the focus remains firmly on using the current suite of well-vetted algorithms to avoid fragmentation across systems that secure national security data.

Validation Requirements

When using LMS or XMSS, there are different validation steps depending on what the system does: 

• If a system only verifies signatures, it must pass CAVP (Cryptographic Algorithm Validation Program) testing. 

• If it also generates signatures (i.e., acts as the signer), it must be validated under CMVP (Cryptographic Module Validation Program). 

Signature generation is more sensitive because it involves managing the cryptographic state, which, if misused (like reusing keys), can expose the system to attacks. That’s why no waivers are allowed here, validation is mandatory. 

NSA emphasizes that signing and state management should ideally be implemented in hardware, such as an HSM (Hardware Security Module), to minimize human or software error. Even during backup operations, key states must be preserved to avoid any possibility of state reuse. 

Vendors who aren’t part of NSS but are providing code or products that will interact with NSS are still expected to meet the same cryptographic quality. That means any code involved in signature verification must be capable of passing CAVP validation, even if the signer itself isn’t part of NSS. 

For commercial product evaluations, the NSA does not expect signature generation to happen within the “Target of Evaluation” (TOE) — only signature verification. So, CAVP testing is enough to demonstrate CNSA 2.0 compliance in most vendor scenarios. 

Firmware often cannot be updated once deployed. So, choosing a quantum-resistant signature algorithm now, like LMS or XMSS, for firmware is crucial. NSA stresses starting the transition early, rather than waiting for other algorithms (like ML-DSA) to become validated. This ensures a long-term cryptographic root of trust is in place before the rest of the system even begins upgrading to post-quantum standards. 

Quantum Alternatives for NSS

To prepare National Security Systems (NSS) for the quantum era, the NSA has addressed alternative cryptographic options, such as: 

• Pre-shared keys (PSKs) may help reduce quantum threats, but their effectiveness can vary; organizations should consult NSA or CSfC guidance before relying on them. 
• Quantum computers pose a far greater risk to public-key cryptography than to symmetric cryptography; symmetric algorithms with large key sizes (like those in CNSA 2.0) are still considered secure. 
• NSA is acting now on quantum threats because National Security Systems (NSS) have long lifespans, systems built today may be in use for decades and need future-proof protection. 
• Quantum Key Distribution (QKD) uses quantum physics to securely share encryption keys but does not offer complete cryptographic protection and is not considered a practical solution for NSS. 
• NSA does not recommend using QKD for NSS and advises agencies not to invest in or deploy QKD systems without direct consultation. 
• Quantum Random Number Generators (RNGs) use quantum effects to generate randomness, any RNG certified by appropriate standards is acceptable if implemented correctly. 

Adapting Hybrid Cryptography

The focus is on balancing strong protection with practical, standards-based implementation, with backward compatibility in mind. The following points outline the necessary considerations and NSA’s guidance. 

• A hybrid solution combines multiple cryptographic algorithms (classical + quantum-resistant) to strengthen key exchange or authentication. 
• NSA trusts CNSA 2.0 algorithms alone and does not require hybrid solutions for NSS security — though hybrid setups may be used for interoperability or technical limitations. 
• Using hybrid cryptography can add complexity to implementation and testing, increasing the risk of bugs and configuration errors. 
• Hybrid solutions may also slow down standardization efforts, since protocols must agree on how to combine and manage multiple algorithms. 
• In cases like IKEv2 (a VPN protocol), NSA supports a hybrid solution due to technical constraints with public key size limits — a smaller key is used first, then a larger encrypted one. 
• NSA does not support using hybrid or non-standard quantum-resistant solutions in mission systems unless specifically advised; such solutions may lead to incompatibility or inefficiency. 
• Hybrid solutions with symmetric key overlays (like RFC 8773 or 8784) may be used in special cases, but these are exceptions, not the norm. 

How can Encryption Consulting help?

If you are wondering where and how to begin your post-quantum journey, Encryption Consulting is here to support you. You can count on us as your trusted partner, and we will guide you through every step with clarity, confidence, and real-world expertise.  

• Cryptographic Discovery and Inventory

  This is the foundational phase where we build visibility into your existing cryptographic infrastructure. We identify which systems are at risk from quantum threats and assess how ready your current setup is, including your PKI, HSMs, and applications. The goal is to identify what cryptographic assets exist, where they are used, and how critical they are. Comprehensive scanning of certificates, cryptographic keys, algorithms, libraries, and protocols across your IT environment, including endpoints, applications, APIs, network devices, databases, and embedded systems.

  Identification of all systems (on-prem, cloud, hybrid) utilizing cryptography, such as authentication servers, HSMs, load balancers, VPNs, and more. Gathering key metadata like algorithm types, key sizes, expiration dates, issuance sources, and certificate chains. Building a detailed inventory database of all cryptographic components to serve as the baseline for risk assessment and planning.

• PQC Assessment

  Once visibility is established, we conduct interviews with key stakeholders to assess the cryptographic landscape for quantum vulnerability and evaluate how prepared your environment is for PQC transition. Analyzing cryptographic elements for exposure to quantum threats, particularly those relying on RSA, ECC, and other soon-to-be-broken algorithms. Reviewing how Public Key Infrastructure and Hardware Security Modules are configured, and whether they support post-quantum algorithm integration. Analyzing applications for hardcoded cryptographic dependencies and identifying those requiring refactoring. Delivering a detailed report with an inventory of vulnerable cryptographic assets, risk severity ratings, and prioritization for migration.

• PQC Strategy & Roadmap

  With risks identified, we work with you to develop a custom, phased migration strategy that aligns with your business, technical, and regulatory requirements. Creating a tailored PQC adoption strategy that reflects your risk appetite, industry best practices, and future-proofing needs. Designing systems and workflows to support easy switching of cryptographic algorithms as standards evolve. Updating security policies, key management procedures, and internal compliance rules to align with NIST and NSA (CNSA 2.0) recommendations. Crafting a step-by-step migration roadmap with short-, medium-, and long-term goals, broken down into manageable phases such as pilot, hybrid deployment, and full implementation.

• Vendor Evaluation & Proof of Concept

  At this stage, we help you identify and test the right tools, technologies, and partners that can support your post-quantum goals. Helping you define technical and business requirements for RFIs/RFPs, including algorithm support, integration compatibility, performance, and vendor maturity. Identifying top vendors offering PQC-capable PKI, key management, and cryptographic solutions. Running PoC tests in isolated environments to evaluate performance, ease of integration, and overall fit for your use cases. Delivering a vendor comparison matrix and recommendation report based on real-world PoC findings.

• Pilot Testing & Scaling

  Before full implementation, we validate everything through controlled pilots to ensure real-world viability and minimize business disruption. Testing the new cryptographic models in a sandbox or non-production environment, typically for one or two applications. Validating interoperability with existing systems, third-party dependencies, and legacy components. Gathering feedback from IT teams, security architects, and business units to fine-tune the plan. Once everything is tested successfully, we support a smooth, scalable rollout, replacing legacy cryptographic algorithms step by step, minimizing disruption, and ensuring systems remain secure and compliant. We continue to monitor performance and provide ongoing optimization to keep your quantum defense strong, efficient, and future-ready.

• PQC Implementation

  Once the plan is in place, it is time to put it into action. This is the final stage where we execute the full-scale migration, integrating PQC into your live environment while ensuring compliance and continuity. Implementing hybrid models that combine classical and quantum-safe algorithms to maintain backward compatibility during transition. Rolling out PQC support across your PKI, applications, infrastructure, cloud services, and APIs. Providing hands-on training for your teams along with detailed technical documentation for ongoing maintenance. Setting up monitoring systems and lifecycle management processes to track cryptographic health, detect anomalies, and support future upgrades.

Transitioning to quantum-safe cryptography is a big step, but you do not have to take it alone. With Encryption Consulting by your side, you will have the right guidance and expertise needed to build resilient, future-ready security posture. 

Reach out to us at [email protected] and let us build a customized roadmap that aligns with your organization’s specific needs.  

Conclusion

In conclusion, the transition to CNSA 2.0 marks a critical step in securing National Security Systems against emerging quantum threats. With clear timelines, trusted algorithms, and structured guidance, NSA is laying the foundation for a future-ready cryptographic environment. Early adoption, cryptographic agility, and adherence to standards will be essential to ensure secure, interoperable, and resilient systems in adopting post-quantum cryptographic capabilities.

Source: 

• CSI_CNSA_2.0_FAQ_.PDF 
• https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF