Preparing for CNSA 2.0: What It Means for Your Code Signing Strategy 

The U.S. National Security Agency (NSA) has officially released the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0). This isn’t just another policy update; it’s a serious shift in how we protect software, firmware, and systems against the coming wave of quantum computing threats. 

If you’re in charge of software development, IT security, or compliance in a government, defense, or commercial environment, CNSA 2.0 should be on your radar. Let’s break down what it means, what’s changing, and how you can get ahead of it, without getting overwhelmed. 

CNSA 2.0 and code signing, in short: software and firmware signing has the earliest deadline in the entire CNSA 2.0 suite, prefer LMS/XMSS or ML-DSA (FIPS 204) by 2025, mandatory by 2030, well ahead of the 2035 deadline for the rest of National Security Systems, because firmware signing keys are the hardest component to update once a device ships.

Key Takeaways

• ML-KEM (FIPS 203) and ML-DSA (FIPS 204) are finalized NIST standards as of August 2024, not pending candidates; the names Kyber and Dilithium refer to the same algorithms pre-standardization.
• ML-KEM handles key establishment; it has no role in code signing. Software and firmware signing uses LMS, XMSS, or ML-DSA.
• This page focuses on the code signing-specific readiness actions. For the full dated migration architecture and hybrid signing patterns, see Architecting the CNSA 2.0 Transition Strategies and Hybrid Cryptography for the CNSA 2.0 Transition.

Why Is CNSA 2.0 So Important?

Quantum computing is advancing fast, and once it reaches a certain threshold, it could crack widely used encryption methods like RSA and ECC. That’s why the NSA has laid out a clear path to transition national security systems and their supporting technologies to quantum-resistant algorithms. 

CNSA 2.0 introduces new cryptographic standards designed to withstand both classical and quantum attacks. The goal? Help organizations start the shift now, so they’re ready well before the deadline. 

What’s in CNSA 2.0?

Here’s a quick overview of what’s changing: 

1. Software and Firmware Signing

For the first time, CNSA 2.0 recommends specific quantum-safe algorithms just for signing software and firmware updates. These are already standardized, so you can begin using them today: 

Algorithm	What It’s For	Specification	Details
LMS (Leighton-Micali Signature)	Signing software and firmware	NIST SP 800-208	SHA-256/192 preferred
XMSS (Xtended Merkle Signature Scheme)	Signing software and firmware	NIST SP 800-208	All parameters approved

These algorithms are stateful, meaning they require careful key tracking, but they’re great options for securing long-term software updates. 

2. Symmetric-Key Cryptography

Not many changes here. The NSA just added SHA-512 to the approved list, giving a bit more flexibility: 

Algorithm	Use Case	Specification	Recommendation
AES	Data Encryption	FIPS PUB 197	Use 256-bit keys
SHA	Hashing	FIPS PUB 180-4	Use SHA-384 or SHA-512

3. Quantum-Resistant Public-Key Algorithms

These are finalized, published NIST standards, not pending candidates. Kyber and Dilithium were the pre-standardization names; as of August 2024, NIST finalized them as FIPS 203 and FIPS 204 respectively, and those are the names to use going forward: 

Algorithm	Use Case	Specification	Details
ML-KEM (formerly CRYSTALS-Kyber)	Key establishment (not signing)	FIPS 203	Use ML-KEM-1024 (Level V/Category 5 parameters)
ML-DSA (formerly CRYSTALS-Dilithium)	Digital signatures	FIPS 204	Use ML-DSA-87 (Level V/Category 5 parameters)

It’s worth being precise about the distinction between these two: ML-KEM establishes a shared secret between two parties and has no role in signing anything. ML-DSA is what produces a signature. Software and firmware signing specifically uses LMS, XMSS, or ML-DSA, never ML-KEM. 

If you’re planning ahead, ML-DSA (or LMS/XMSS for signing specifically) are the algorithms to build into your systems. 

CNSA 2.0 Timeline: When Do You Need to Act?

The full transition is expected to wrap up by 2035, but there are milestones along the way depending on what you’re managing: 

1. Software & Firmware Signing
   • Start now
   • Use CNSA 2.0 by 2025
   • Mandatory by 2030
2. Web Browsers, Cloud Services
   • Begin supporting CNSA 2.0 by 2025
   • Mandatory by 2033
3. Networking Equipment (VPNs, Routers)
   • Support by 2026
   • Mandatory by 2030
4. Operating Systems
   • Support by 2027
   • Mandatory by 2033
5. Niche Devices & Legacy Systems
   • Update or replace by 2033

The sooner you start testing, the smoother your rollout will be. 

Compliance & Enforcement: What to Expect

If you work with National Security Systems, you’ll need to show progress as part of your Risk Management Framework (RMF) assessments. The NSA will no longer accept just “FIPS validated” crypto for these environments; you need to use NSA-approved algorithms and configurations. 

Audits will include: 

• NIAP validations against protection profiles 
• Reporting on signing algorithms and key management 
• Verification of state tracking for LMS/XMSS 

How CodeSign Secure Can Help?

Moving to CNSA 2.0 isn’t just about selecting the right algorithm. It’s about building an end-to-end code signing strategy that protects keys, automates workflows, enforces policy, and ensures compliance. That’s exactly what CodeSign Secure was built for. 

Here’s how CodeSign Secure supports CNSA 2.0: 

• LMS & XMSS-Ready: Already supports the post-quantum signature schemes required for software and firmware signing. 
• HSM-Backed Key Protection: Your private keys stay protected inside FIPS 140-2 Level 3 HSMs, ensuring no exposure. 
• State Tracking Built-In: Automatically manages state for LMS and XMSS to ensure every signature is compliant. 
• DevOps Friendly: Integrates natively with Jenkins, GitHub Actions, Azure DevOps, and more. 
• Policy-Driven Security: Use RBAC, multi-approver (M of N) sign-offs, and custom security policies to control every aspect of your code signing. 
• Audit-Ready Logging: Get full visibility into every signing operation for easy reporting and compliance. 

Whether you’re signing software for Windows, Linux, macOS, Docker, IoT devices, or cloud platforms, CodeSign Secure is ready to help you transition safely and efficiently. 

Frequently Asked Questions

Are ML-KEM and ML-DSA still draft standards?

No. NIST finalized both in August 2024, as FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA). They are published, final standards, not candidates awaiting selection.

Can I use ML-KEM to sign firmware?

No. ML-KEM is a key encapsulation mechanism for key exchange, not a signature algorithm. Firmware and software signing under CNSA 2.0 uses LMS, XMSS, or ML-DSA.

Conclusion

CNSA 2.0 is here, and it’s more than a recommendation; it’s a roadmap to enhance your security measures. If you’re involved in software development, infrastructure, or compliance, now’s the time to start planning. 

With CodeSign Secure, you get the tools and automation you need to: 

• Start signing with CNSA 2.0-compliant algorithms 
• Protect your keys and enforce strict policies 
• Stay ahead of deadlines without slowing down development 

Want to see how it works?

Reach out to us at [email protected] to schedule a demo or learn more about how CodeSign Secure can help you stay compliant and secure.