Securing the Future of Code Signing with CNSA 2.0 Compliance and PQC

Introduction

The speedy advancements of quantum computing are no longer a theoretical concern, rather, it is an impending threat to classical cryptography. Algorithms such as Shor’s, which can factor large integers and compute discrete logarithms exponentially faster than any classical algorithm, threaten to break algorithms such as RSA and ECC. Likewise, usage of Grover’s algorithm leads to the weakening of symmetric encryption by effectively halving key strength, causing a threat to the integrity of cryptographic systems using shorter key lengths. The implications of these are significant to foundational security protocols such as TLS, VPNs, digital signatures, and particularly code signing.

Recognizing this, the U.S. National Security Agency (NSA) has introduced and published the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0). This cryptographic effort mandates the use of post-quantum cryptographic (PQC) algorithms for securing national security systems (NSS) and classified communications. CNSA 2.0 is not merely a recommendation, but a strategic shift, backed by government policy, aimed at hardening systems against both current and future cryptanalytic capabilities.

CNSA 2.0 explicitly names ML-KEM (for key encapsulation) and ML-DSA (for digital signatures) as required PQC algorithms, both of which were selected by NIST in its PQC standardization process for their strong security and performance characteristics. These algorithms are lattice-based, relying on mathematical problems believed to be resistant to quantum attacks, unlike RSA and ECC. In this blog, we’ll examine the details of CNSA 2.0 and explore its algorithmic foundations. We’ll also showcase how Encryption Consulting’s Code Signing Solution, CodeSign Secure, empowers organizations to maintain trust, integrity, and compliance in software distribution as they transition into the post-quantum era.

What Is CNSA 2.0?

CNSA 2.0, or the Commercial National Security Algorithm Suite 2.0, is the latest suite of cryptographic algorithms mandated by the U.S. National Security Agency (NSA) for securing National Security Systems (NSS) in the post-quantum era. Released in September 2022, CNSA 2.0 represents a significant shift in cryptographic strategy, explicitly designed to prevent risks posed by both classical and quantum adversaries. It supersedes the older CNSA 1.0 and Suite B protocols, aligning national security cryptographic standards with modern quantum-resilient initiatives.

Unlike NIST’s Post-Quantum Cryptography (PQC) standardization, which aims to provide algorithms for general-purpose commercial use, the NSA has set clear and urgent expectations for the transition to PQC through CNSA 2.0, particularly in high-trust environments like code signing. The suite compels the use of quantum-resistant algorithms as they offer strong security even against quantum computing capabilities, and simultaneously phases out legacy algorithms such as RSA, DSA, and finite-field DH. Whether you’re leading product security, managing DevOps pipelines, architecting cryptographic systems, or ensuring regulatory compliance, this shift impacts you.

Explore our in-depth blog post to know more about CNSA 2.0 in detail.

CNSA 2.0 Cryptographic Algorithms

To address the dual challenges of advanced classical threats and future quantum adversaries, the CNSA 2.0 suite introduces a set of cryptographic algorithms according to the different use cases within National Security Systems (NSS). These algorithms are categorized based on their application, from software and firmware signing to general-purpose public-key cryptography.

1. Algorithms for Software and Firmware Signing

One of the most important use cases covered under CNSA 2.0 is code signing. Code signing is the process of digitally signing software, firmware, or updates to prove they are authentic and have not been modified.

As PQC gains urgency, hash-based signature algorithms stand out for their maturity, security guarantees, and NSA endorsement under the CNSA 2.0 suite. Two primary algorithms, Leighton-Micali Signature (LMS) and eXtended Merkle Signature Scheme (XMSS), form the backbone of trusted code signing to protect National Security Systems (NSS) in a post-quantum world.

These algorithms differ fundamentally from traditional RSA and ECDSA schemes. While the latter relies on number-theoretic assumptions (e.g., discrete logarithm or integer factorization problems), LMS and XMSS rely on the security properties of cryptographic hash functions, such as preimage resistance, collision resistance, and second preimage resistance. These properties remain quantum-attack resilient even under Grover’s algorithm, which only offers a quadratic speedup, therefore, providing the highest level of security.

Both LMS and XMSS are stateful signature schemes. This means that each signature requires unique internal state information that must be managed securely and updated atomically after every signature operation. Unlike RSA or ECDSA, where the same private key can be used to generate multiple signatures, LMS/XMSS keys are tied to a fixed number of valid signatures. This is because reusing a key state or signing two different messages with the same state can compromise security, allowing attackers to forge additional signatures.

In practice, this introduces strict requirements for:

State persistence and rollback protection: Especially in embedded or firmware environments, systems must prevent rollback to a previous signing state (e.g., due to power loss or system crashes).
Atomic signing operations: This refers to the detection of any interruption during signing and the ability to recover to avoid reuse.
Audit logging and key usage tracking: A signature counter must be maintained and protected to ensure integrity across reboots or system migrations.

LMS

LMS, originally developed by Leighton and Micali, is optimized for constrained environments such as bootloaders, smart cards, and hardware security modules (HSMs). It uses a hierarchical structure of Merkle trees where each leaf is associated with a one-time signature (OTS). The scheme supports parameter sets that allow tuning trade-offs between performance, size, and security.

Aspect	Details
Signature Size	1.2 KB – 3 KB
Performance	LMS is computationally faster than XMSS, making it attractive for real-time signing operations on devices with limited CPU or memory.
Use Case	Ideal for environments where secure and efficient firmware signing is critical (e.g., IoT, BIOS/UEFI).

One of LMS’s advantages is its stateless verifier model. This means verification routines do not require maintaining any state, making LMS signatures easy to validate even in minimal environments such as ROM-based bootloaders or air-gapped devices.

XMSS

XMSS, specified in RFC 8391, offers more features over LMS and introduces forward-security with pseudorandom key generation and optional key randomization. It is suitable for use cases that demand longer-term cryptographic assurance and more sophisticated key management mechanisms.

Aspect	Details
Signature Size	Typically, 2 KB to 5 KB, depending on parameter sets and security levels.
Security Property	Provides forward security as it uses a binary Merkle tree with hash chains to derive one-time keys, ensuring each signature remains unforgeable even if some internal state is leaked.
Use Case	Suitable for high-assurance environments requiring strong key protection.

XMSS’s computational overhead is higher than LMS, which makes it more appropriate for higher-assurance systems with strong processing capabilities, such as firmware signing servers, secure code distribution services, or enterprise PKI infrastructures transitioning to PQC.

Here’s a quick comparison for LMS and XMSS, two NIST SP 800-208 standardized, hash-based digital signature schemes designed for secure firmware and software signing:

Algorithm	Function	Specification	Parameters
Leighton-Micai Signature (LMS)	Asymmetric algorithm for digitally signing firmware and software	NIST SP 800-208	All parameters approved for all classification levels. SHA-256/192 recommended.
eXtended Merkle Signature Scheme (XMSS)	Asymmetric algorithm for digitally signing firmware and software	NIST SP 800-208	All parameters approved for all classification levels.

2. Quantum-Resistant Public-Key Algorithms

With the rise of quantum computing, traditional public-key schemes such as RSA, DH, ECDSA, and ECDH are no longer considered future-proof. As part of the CNSA 2.0 roadmap, NSA has defined a suite of quantum-resistant public-key algorithms to guide future NSS deployments. While NIST’s final FIPS standardization for these algorithms is pending, NSA’s early announcement enables developers, vendors, and NSS operators to begin planning and building accordingly.

Since public-key algorithms are the core of code signing, digital signatures generated with these algorithms guarantee the authenticity and integrity of software and firmware. Therefore, CNSA 2.0 specifically advises the immediate adoption of hash-based signature schemes, such as Leighton-Micali Signature (LMS) and eXtended Merkle Signature Scheme (XMSS), for code signing. These are already standardized and approved for use in National Security Systems (NSS).

Algorithm	Function	Specification	Parameters
ML-KEM	Asymmetric algorithm for key establishment	FIPS 203	Use Level V parameters for all classification levels
ML-DSA	Asymmetric algorithm for digital signatures	FIPS 204	Use Level V parameters for all classification levels

Adapting CNSA 2.0 in Code Signing practices

As quantum computing progresses toward practical possibilities, traditional cryptographic mechanisms, especially those relying on RSA and ECC, face existential risk due to their vulnerabilities. Code signing, a foundational element of software supply chain security, is particularly sensitive to these changes. It ensures that software, firmware, and configuration updates originate from a trusted source, are not tampered with in transit, and cannot be repudiated by the signer.

Therefore, under CNSA 2.0, firmware signing is identified as the ‘highest-priority signature use case’ in the post-quantum transition. The urgency originates from the fact that in many systems, the firmware validation algorithm is fixed at deployment, often residing in immutable hardware or boot-level firmware. The selected algorithms: LMS and XMSS, are already standardized by NIST in Special Publication 800-208, unlike some other post-quantum signatures that are still under evaluation and NSA explicitly mentions the need for immediate implementation of these post-quantum signature schemes. Furthermore, CNSA 2.0 also highlights the importance of NIST’s newly-approved algorithms, ML-KEM for key exchange and ML-DSA for signatures, once they’re fully standardized and supported in hardware and software.

Navigating CNSA 2.0 Policy and Algorithmic Compliance for Code Signing

As the NSA recommends its quantum-resistant cryptography (QRC) transition roadmap through the CNSA 2.0, organizations building or supporting National Security Systems (NSS) must now align their code signing implementations with a precise set of algorithms and follow operational constraints.

While CNSA 2.0 provides cryptographic direction, understanding how to meet policy mandates, especially those laid out in CNSSP 15, NSM-10, and associated CNSS/NIAP documentation, is critical for commercial vendors. Therefore, if your organization develops software or firmware for NSS, you’re not only required to use the right cryptographic algorithms suite (CNSA 2.0), but also to follow multiple policy rules issued by various security authorities.

The cryptographic posture required for any product, especially one performing sensitive code signing or signature validation, depends on its classification and use case.

For Type 1 equipment (typically used in classified or tactical systems), cryptographic implementations are governed by a trio of foundational documents: CJCSN 6510.04, CNSSAM 01-07 and NSM-5 guides cryptographic modernization for tactical and classified systems, explicitly requiring cryptographic algorithms suitable for code signing operations that ensure secure firmware authentication and integrity.

Additionally, these documents together require the use of CNSA 2.0-approved cryptographic tools and give clear guidance on when and how to use them, especially in cases where firmware must stay secure and is hard to update once deployed.

On the commercial side, particularly for vendors aiming to serve NSS or NIAP (National Information Assurance Partnership)-validated environments, compliance must align with the policy directives mentioned:

CNSSP 15: lists the approved CNSA 2.0 algorithms that must be followed by code signing keys and processes. This ensures that all digital signatures on software used in National Security Systems (NSS) are strong enough to resist future quantum attacks.
CNSSP 11 and NSM-10: These policies require the use of quantum-safe algorithms like LMS and XMSS in your systems and tell you exactly when and where to use them (e.g., for signing firmware).
CNSSP 156: This policy defines the official migration period (2025–2030) to switch from old cryptography (CNSA 1.0) to the more secure CNSA 2.0 standard, including cryptographic algorithms used specifically for code signing, while allowing flexibility for systems that are expensive or difficult to upgrade.

A critical takeaway is that if your system is expected to be used after 2030, you must use CNSA 2.0-approved algorithms from the start. CNSA 1.0 remains acceptable for certain legacy systems, but only where short-term cryptographic validity or operational feasibility justifies its continued use.

Algorithm Selection for Software vs. Firmware Signing

NSA handles software and firmware signing as distinct use cases, which originate from three technical considerations:

1. Standards Maturity

Hash-based signature algorithms, LMS and XMSS, were standardized earlier by NIST via SP 800-208, and have CAVP validation available, making them the current approved options for software and firmware signing under CNSA 2.0, while other quantum-resistant signatures may not be as easily available for integration.

These algorithms are “stateful,” which means they require careful management of one-time-use keys. They are especially suitable for long-term systems like firmware in embedded or constrained devices, where updating the signature process later might not be practical. Because LMS and XMSS are already commercially available and validated, the NSA recommends using them now rather than waiting for newer algorithms to become available.

ML-DSA, a stateless and lattice-based signature algorithm, is also approved under CNSA 2.0, but it may not be as easily available for integration. While it can be used for all signing use cases, including software and firmware, it is expected to be more useful in scenarios where a large number of signatures are needed or where signing happens in a distributed environment. Once validated, ML-DSA becomes widely available, it may be the preferred choice for many organizations. However, any implementation of ML-DSA or ML-KEM must strictly follow FIPS 203 and 204 to be considered CNSA 2.0 compliant.

2. Urgency

NSA has prioritized firmware signing due to the deeply embedded nature of its cryptographic roots, such as root certificates, public keys, or secure boot keys, which are often hardcoded into hardware and cannot be easily updated once deployed. Therefore, securing embedded firmware with quantum-safe signatures is an urgent and critical priority.

3. Performance Alignment

LMS/XMSS impose higher performance costs (e.g., larger signature sizes, slower operations), but firmware signing is infrequent and localized, therefore making them ideal choices. High-throughput software environments may later adopt ML-DSA once validated.

Therefore, NSA currently approves only LMS and XMSS for signing use in NSS environments. Multi-tree variants such as HSS (Hierarchical Signature Scheme) and XMSSMT (XMSS Multi-Tree), which are already included in NIST SP 800-208, are not yet permitted for NSS, likely due to complexity in their multi-tree state management.

As part of the CNSA 2.0 transition, vendors are expected to begin integrating LMS and XMSS signature verification into BIOS, UEFI, and embedded bootloaders. These hash-based signature schemes offer quantum-resilient protection and are currently the only PQC algorithms approved by the NSA for use in NSS.

Note: Validated ML-DSA will eventually become the preferred solution for high-throughput and distributed signing environments due to its statelessness, efficiency, and strong mathematical foundation in structured lattices.

However, NSA’s position is clear: the LMS/XMSS transition must begin now, especially for firmware use cases, given:

The expected delay in ML-DSA validation and tooling availability,
The long hardware lifecycles in critical NSS systems,
The opportunity cost of waiting may result in post-quantum insecure deployments that cannot be upgraded.

Once validated, ML-DSA will offer operational advantages, including:

Better scalability across CI/CD pipelines,
Simplified key management without state tracking,
Reduced signature size overhead compared to LMS/XMSS in some configurations.

More about Hash-Based Algorithms

SHA-384 and SHA-512 in CNSA 2.0

CNSA 2.0 states that SHA-2 (SHA-384 and SHA-512) selections are sufficient for security, and their widespread adoption in the commercial world ensuring seamless interoperability across systems. It mentions SHA-384 as a core approved hash function for securing, based on its demonstrated strength and NSA’s internal analysis and SHA-512 has been explicitly added to CNSA 2.0 for scenarios where performance optimizations are critical. This is because its 64-bit word structure is particularly advantageous on 4 modern 64-bit processors, often delivering faster throughput with comparable security guarantees.

However, deploying SHA-512 introduces an important consideration, i.e., interoperability. When integrating third-party or legacy systems that default to SHA-384, developers must ensure alignment across components to prevent failures in signature verification, HMAC generation, or message digest compatibility.

Use of Other Hash Functions

There are special conditions under which other hash functions are permissible:

Truncated SHA-2 Variants (e.g., SHA-256/192): When a cryptographic algorithm (approved by NSA or NIST) explicitly defines use of such truncated variants within its construction. For example, in LMS, they are allowed.
SHA-3 Family (SHA3-384, SHA3-512): While not generally approved for general-purpose NSS use, these are acceptable in internal hardware processes, such as random number generation or key derivation within chips.

For instance, if a hardware-isolated, secure execution environment performs Key Derivation Function (KDF) operations internally using SHA3-512 without exposing the hash externally, this falls within acceptable practice boundaries.

Key Considerations for Integrating LMS and XMSS into Code Signing Workflows

As organizations transition to quantum-safe code signing using hash-based signature schemes like LMS (Leighton-Micali Signature) and XMSS (eXtended Merkle Signature Scheme), several unique operational challenges must be addressed to ensure security and workflow continuity.

1. HSM compatibility

Most commercial HSMs are optimized for RSA or ECDSA, which don’t need to keep track of anything between signatures. But LMS and XMSS are different, as they require maintaining signature state (such as counters or tree indices) securely within the module. Because of this, many HSMs need firmware updates or special add-ons to properly support these new types of signatures. Therefore, support for LMS/XMSS is emerging and often requires firmware upgrades or specialized modules. Without this, keys might be handled outside the HSM, making them less secure.

2. State synchronization in distributed environments

In modern DevOps and CI/CD pipelines, code signing is often distributed across multiple nodes or servers. LMS and XMSS’s stateful nature means that each signature consumes a unique part of the private key’s signing capacity, and reuse of state parameters can compromise the entire key. This demands a carefully coordinated approach where the signing state is consistently synchronized across all signing nodes.

3. Secure state backups

Backing up LMS or XMSS private keys involves more complexity than traditional key backups because the current signing state (e.g., signature counters or Merkle tree indices) must be preserved accurately and securely. The backup process must be tamper-evident and resistant to rollback or replay attacks, as restoring an outdated state can lead to signature reuse and compromise security. Therefore, organizations often employ custom tools or secure enclaves to protect this sensitive state information and ensure that backups remain consistent with ongoing signing operations.

HSM Integration for Quantum-Safe Code Signing

As organizations begin utilizing quantum-resistant digital signatures such as LMS and XMSS, Hardware Security Modules (HSMs) play a crucial role in enforcing security, compliance, and operational continuity.

Unlike traditional cryptographic algorithms, LMS and XMSS use one-time signature keys derived from a master private key (seed). Each signature must use a unique derived key, tracked using a secure counter. The HSM ensures that:

A finite number of signatures is generated per key pair
The one-time-use rule is enforced via internal state management
Derived keys are not reused or exported inappropriately

Each private key derivation is deterministic and based on a counter, meaning each derived private key can only produce one signature. This unique requirement places operational demands on the cryptographic system. HSMs enforce this state internally and prevent unauthorized resets or duplication of the signing environment, which would otherwise compromise the integrity of LMS/XMSS.

The Role of Hybrid Cryptography

As the cybersecurity industry gets ready for the post-quantum era, hybrid cryptographic solutions, those that combine classical algorithms like RSA or ECC with post-quantum cryptographic (PQC) algorithms, have become a popular transition strategy. These solutions aim to protect data in both the current and future threat landscape.

This dual-layer approach ensures that if a powerful quantum computer breaks a classical algorithm, the PQC layer still keeps the data secure. On the other hand, if the new PQC algorithms show unexpected weaknesses, the classical layer continues to offer a level of protection. Hybrid cryptography helps balance risk and security while PQC standards are still being tested and adopted.

However, the NSA, through its CNSA 2.0 guidance, does not require hybrid solutions for National Security Systems (NSS). The agency has confidence in the strength of the approved PQC algorithms and encourages a direct move to these quantum-safe standards.

That said, the NSA acknowledges that some industry standards may temporarily require hybrid implementations, especially due to the larger key and signature sizes of PQC algorithms. Still, it warns that hybrid systems can introduce added complexity and compatibility issues. As a result, hybrid cryptography is considered a temporary measure, not a long-term solution.

How Encryption Consulting Can Help?

Encryption Consulting helps enterprises and governments implement CNSA 2.0-aligned signing infrastructures with full PQC and hybrid crypto support.

CodeSign Secure v3.02 supports PQC out of the box, giving organizations a head start in adapting to the next era of cryptography without sacrificing usability or performance. It’s a smart move now and a necessary one for the future.

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. 

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.