TL;DR
CNSA 2.0 is the NSA’s mandated suite of quantum-resistant algorithms for National Security Systems, and it carries category-specific deadlines running from 2025 through 2033. Every one of those deadlines assumes an organisation already knows which algorithms it uses and where. Most do not, because cryptography is typically inferred from configuration files and dependency manifests rather than from the code that actually implements it. Building a genuine cryptographic inventory means detecting algorithm use at the source level, mapping it to CNSA 2.0 categories, and keeping the record current as code changes.
Why does CNSA 2.0 change the calculus now?
CNSA 2.0 was published by the NSA in September 2022 as an advisory notifying operators, owners, and vendors of upcoming requirements for quantum-resistant algorithms across National Security Systems. For several years it sat in the category of “eventual compliance work.” That has changed. NIAP began releasing updated Protection Profiles incorporating CNSA 2.0 algorithms in 2026, and products that have not been validated against these updated profiles will not be eligible for new deployments into National Security Systems. CNSSP 15, the policy that governs which algorithms NSS must use, was updated in 2025 to formally incorporate CNSA 2.0 and deprecate CNSA 1.0.
The deadlines are staggered by product category rather than uniform. Software and firmware signing was expected to support and prefer CNSA 2.0 by 2025, with exclusive use by 2030. Web browsers, servers, and cloud services must support and prefer it by 2025 and use it exclusively by 2033. Traditional networking equipment, including VPNs and routers, must support it by 2026 and use it exclusively by 2030. Operating systems follow a 2027 support date and a 2033 exclusivity date, and niche or constrained equipment follows a 2030 support date with 2033 exclusivity. Custom applications and legacy equipment fall under a 2033 update-or-replace requirement. The pressure this creates is not abstract. Vendors selling into defence, government, and critical infrastructure supply chains are already being asked by procurement teams to demonstrate a transition plan, and a transition plan is only credible if it starts from an accurate inventory of current cryptographic use.
What does CNSA 2.0 actually require, and by when?
The approved algorithm set includes AES-256 for symmetric encryption, SHA-384 or SHA-512 for hashing, and two asymmetric algorithms originally named CRYSTALS-Kyber for key establishment and CRYSTALS-Dilithium for digital signatures, since finalised by NIST as ML-KEM (FIPS 203) and ML-DSA (FIPS 204). NSA specifies ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures at the highest security level. For software and firmware signing specifically, NSA selected LMS and XMSS, both specified in NIST SP 800-208, because these algorithms already had standardised, validated implementations available when the advisory was published, unlike the general-purpose public-key algorithms.
This effectively deprecates RSA, Diffie-Hellman, and elliptic curve cryptography once the relevant deadline is reached, which is precisely the category of algorithm most commonly embedded in legacy code, third-party libraries, and vendor components that organisations did not write themselves. CNSA 2.0 builds on NIST’s FIPS 140 validation programme, and it includes two of the three PQC algorithms NIST has standardised, ML-KEM and ML-DSA, but not SLH-DSA. The distinction matters for compliance mapping: an organisation cannot simply claim “we use NIST post-quantum algorithms” and assume CNSA 2.0 alignment, because CNSA 2.0 is narrower and more prescriptive than the underlying NIST standard.
Why do most organisations fail at the inventory stage?
The transition timelines above all assume a starting inventory of where classical algorithms are currently used. This is where most organisations stall, and the reason is structural rather than a lack of effort. Cryptography is rarely declared. It is called through library functions, inherited from dependencies several layers deep, hardcoded in configuration, or embedded in vendor-supplied binary components with no visible source. A dependency manifest will tell a team which packages are declared, but it will not tell them whether a package actually invokes RSA key generation, whether a deprecated hashing function is called in an obscure utility module, or whether a certificate library defaults to an algorithm nobody selected deliberately.
This is the same failure mode that undermines manifest-only software composition analysis more broadly: the bottleneck is knowing what cryptography is in use in the first place. Most tools analyse manifests. Very few analyse the code itself, and manifest-only visibility produces an inventory that is technically complete on paper and materially incomplete in practice.
What does a working cryptographic inventory look like?
A cryptographic inventory that supports CNSA 2.0 compliance needs to answer three questions for every algorithm found: what it is, where it is implemented, and which system or product it ships in. That requires detection at the source level rather than the manifest level, because algorithm calls, hardcoded key material, and certificate handling logic exist in code that a manifest never surfaces. Snippet-level detection, the same approach used for open source component identification, applies equally well here: it identifies the specific function or file where an algorithm is invoked, not just the package that happens to contain it somewhere.
The output of this discovery process should be structured, not narrative. A Cryptography Bill of Materials in the CycloneDX format, as outlined in What is a CBOM?, gives each finding a consistent schema covering algorithm family, specification, and location, which makes it possible to filter directly for CNSA 1.0 algorithms still in use, flag them against the relevant deadline, and hand the result to engineering teams as a prioritised worklist rather than a spreadsheet of ambiguous line items. Where a codebase spans multiple languages, the inventory needs to hold up consistently across Java, Python, Go, and C, since a partial inventory that only covers one language creates the same false confidence as a manifest-only scan.
How should organisations sequence the work?
Given the staggered deadlines, the discovery work should follow the same order as the compliance calendar rather than treating every system as equally urgent. Software and firmware signing carries the earliest exclusivity deadlines, so codebases producing signed artefacts warrant the first inventory pass. Networking equipment and anything touching TLS, SSH, or IPsec configurations should follow, since these sit on a 2026 support date. Operating systems and custom applications carry longer runways but represent larger, more entangled codebases, so starting discovery early reduces the risk of a compressed migration window later.
None of this needs to be a one-off audit. Codebases change continuously, dependencies get upgraded or swapped, and a cryptographic inventory produced once and left static will drift out of accuracy within a release cycle or two. The organisations that manage this transition without last-minute scrambling are the ones treating cryptographic discovery as a continuous process integrated into their existing build and release pipeline, not as a periodic compliance exercise run before an audit.
For business owners and decision-makers, the practical question raised by CNSA 2.0 is whether the organisation can currently produce an accurate answer to “which of our products use RSA, ECDH, or ECDSA, and where.” Source-level cryptographic detection, mapped into a structured CBOM, is what makes that answer possible ahead of the deadline rather than in response to it.
Talk to SCANOSS about turning your cryptographic inventory into something regulators and auditors can actually rely on.
