CNSA 2.0 deadlines are staggered by system category

The Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) was published by the NSA in September 2022 to notify owners, operators and vendors of National Security Systems (NSS) of upcoming quantum-resistant algorithm requirements. For a while it sat in the "eventual compliance work" pile. That's over. CNSSP 15, the policy governing which algorithms NSS must use, was updated in 2025 to formally incorporate CNSA 2.0 and deprecate CNSA 1.0. From 1 January 2027, new equipment acquired for NSS must support CNSA 2.0 algorithms unless an exception applies, and NIAP is updating its Protection Profiles so products can be validated against them.

CNSA 2.0 sets two dates for each system category: when CNSA 2.0 algorithms must be supported and preferred, and when they must be used exclusively.

Procurement teams selling into defence, government and critical infrastructure are already asking vendors for a transition plan, and a transition plan only holds up if it starts from an accurate inventory.

CNSA 2.0 approves AES-256, SHA-384/512, ML-KEM and ML-DSA

CNSA 2.0 approves AES-256 for symmetric encryption, SHA-384 or SHA-512 for hashing, and two asymmetric algorithms originally named CRYSTALS-Kyber and CRYSTALS-Dilithium, now finalised by NIST as ML-KEM (FIPS 203) and ML-DSA (FIPS 204). NSA specifies ML-KEM-1024 and ML-DSA-87, the highest security levels. For software and firmware signing specifically, NSA selected LMS and XMSS (NIST SP 800-208), since these had standardised, validated implementations available when the advisory was published.

CNSA 2.0 effectively deprecates RSA, Diffie-Hellman and elliptic curve cryptography once each deadline lands. That's the algorithm category most often buried in legacy code, third-party libraries and vendor components nobody wrote in-house. CNSA 2.0 is also narrower than the NIST post-quantum standards: it includes ML-KEM and ML-DSA but not SLH-DSA, so "we use NIST post-quantum algorithms" doesn't automatically mean CNSA 2.0 alignment.

Most cryptography never appears in a dependency manifest

Most organisations stall on CNSA 2.0 because cryptography is rarely declared. It's called through library functions, inherited from dependencies several layers deep, hardcoded in configuration, or embedded in vendor-supplied binaries with no visible source. A dependency manifest tells you which packages are declared. It doesn't tell you whether a package invokes RSA key generation, whether a deprecated hashing function gets called in some obscure utility module, or whether a certificate library defaults to an algorithm nobody chose on purpose.

Manifest-only software composition analysis has the same weakness: the hard part is knowing what's actually in use. A manifest-only cryptographic inventory looks complete on paper and is materially incomplete in practice.

A CNSA 2.0 inventory needs source-level detection

A cryptographic inventory that supports CNSA 2.0 compliance has to answer three questions for every algorithm found: what it is, where it's implemented, and which system or product it ships in. Answering them needs source-level detection, because algorithm calls, hardcoded key material and certificate logic live in code a manifest never surfaces. Snippet-level detection, the same approach used to identify open source components, pinpoints the specific function or file where an algorithm is invoked, not just the package that contains it.

The inventory should also be structured rather than narrative. A CBOM in CycloneDX format gives every finding a consistent schema (algorithm family, specification, location), so teams can filter directly for CNSA 1.0 algorithms still in use, flag them against the relevant deadline, and hand engineering a prioritised worklist instead of an ambiguous spreadsheet. Where a codebase spans multiple languages, the inventory has to hold up across all of them: a partial inventory covering one language creates the same false confidence as a manifest-only scan.

Sequence cryptographic discovery by CNSA 2.0 deadline

Cryptographic discovery should follow the CNSA 2.0 calendar rather than treat every system as equally urgent. Software and firmware signing has the earliest support date (2025) and shares the earliest exclusive-use date (2030) with networking equipment, so start there. Networking equipment and anything touching TLS, SSH or IPsec comes next, with a 2026 support date. Operating systems and custom applications have longer runways but larger, more entangled codebases, so starting early avoids a compressed migration window later.

A CNSA 2.0 inventory has to stay continuous

A cryptographic inventory for CNSA 2.0 isn't a one-off audit. Codebases change continuously, dependencies get upgraded or swapped, and an inventory produced once and left static drifts out of accuracy within a release cycle or two. The organisations managing the transition without a last-minute scramble treat cryptographic discovery as continuous, built into the release pipeline rather than run before an audit.

The practical test CNSA 2.0 sets for any organisation is whether it can say, accurately and today, which of its products use RSA, ECDH or ECDSA, and where. Source-level detection mapped into a structured CBOM is what makes that answer possible ahead of the deadline, instead of in response to it.