CNSA 2.0: The Complete Guide to NSA’s Post-Quantum Requirements

Introduction

Most post-quantum cryptography guidance reads like a suggestion box. NIST publishes standards and says organizations should start planning. CISA releases fact sheets encouraging awareness. OMB issues memos directing agencies to inventory their cryptographic assets. All useful, all important, all remarkably easy to defer.

CNSA 2.0 is different. The NSA’s Commercial National Security Algorithm Suite 2.0 names the exact algorithms. It specifies the exact parameter levels. It assigns deadlines by system category, with enforcement mechanisms that connect to procurement eligibility, NIAP validation, and the Risk Management Framework. Starting January 1, 2027, every new acquisition for a National Security System must support CNSA 2.0 algorithms or it cannot be deployed. That is eight months from now. For organizations selling into classified environments, the planning phase is already over.

This guide covers the complete CNSA 2.0 requirement set: what it mandates, what it excludes, when each requirement takes effect, how enforcement works, and what NSA’s algorithm choices reveal about how they assess the quantum threat. I will also address a question I hear constantly: does CNSA 2.0 matter if you don’t operate National Security Systems? The answer, as we will see, is increasingly yes.

Where CNSA 2.0 Fits in the Policy Stack

Understanding CNSA 2.0 requires understanding the regulatory architecture it sits within. Several overlapping directives govern how U.S. government systems handle cryptography, and CNSA 2.0 occupies a specific role in that structure.

The broadest mandate comes from National Security Memorandum 10 (NSM-10), signed in May 2022, which directs the entire federal government to migrate to quantum-resistant cryptography by 2035. NSM-10 sets the destination. It does not specify the route.

OMB Memorandum M-23-02, issued in November 2022, fills in some details for Federal Civilian Executive Branch (FCEB) agencies: inventory your cryptographic systems, identify vulnerable algorithms, assess migration complexity. But M-23-02 applies to civilian systems, not National Security Systems.

CNSA 2.0 governs the national security side. Published by NSA in September 2022, it defines which algorithms are approved for all National Security Systems — classified and unclassified — and sets a category-specific transition timeline. NSA acts here in its role as National Manager for NSS, with authority under NSD-42, NSM-8, and CNSSP 11 to dictate cryptographic requirements for these systems.

The operational anchor is CNSSP 15, the Committee on National Security Systems Policy that specifies which algorithms NSS must use. Originally built around NSA Suite B, then revised for CNSA 1.0, CNSSP 15 was updated in 2025 to formally incorporate CNSA 2.0 and deprecate CNSA 1.0. Protection Profiles began releasing in 2026, and the transition is now actively underway.

Executive Order 14144, signed in January 2025, reinforced the timeline and added a requirement for CISA and NSA to publish a list of quantum-safe product categories by December 2025. The Quantum Computing Cybersecurity Preparedness Act, signed in December 2022, further codified the migration requirement in federal law.

For security practitioners, the key takeaway is that CNSA 2.0 is the most operationally specific document in this stack. NSM-10 says “migrate by 2035.” CNSA 2.0 says “use ML-KEM-1024 for key establishment, ML-DSA-87 for signatures, support it in your VPN products by 2026, and use it exclusively by 2030.” The difference between aspiration and execution lives in that level of specificity.

The CNSA 2.0 FAQ: Three Versions, Increasing Clarity

The guidance has evolved through three FAQ revisions, each adding detail as NIST’s standardization process progressed:

Version 1.0 (September 2022) accompanied the original advisory. It referenced “CRYSTALS-Kyber” and “CRYSTALS-Dilithium” — the pre-standard names — with “TBD” listed as the specification. The timeline was published, but much of the implementation detail remained forward-looking.

Version 2.0 (April 2024) arrived 18 months later. This update added critical exclusions (SLH-DSA, HSS, XMSS^MT), restrictions on SHA-3 usage, and clarified the HSM and NIAP validation requirements. It also explicitly rejected quantum key distribution (QKD) for NSS, a position I analyzed in my earlier CNSA 2.0 coverage.

Version 2.1 (December 2024) followed NIST’s finalization of FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. This version replaced all pre-standard names with official NIST designations, added FIPS references to the algorithm table, prohibited HashML-DSA, expanded the enforcement timeline with specific dates, and made a forward-looking statement that NSA does not plan to add future NIST post-quantum standards to the suite. V2.1 is the current authoritative version.

One detail that matters more than it might appear: NSA clarified in V2.1 that implementations using the old CRYSTALS-Kyber or CRYSTALS-Dilithium specifications — including pre-standard draft versions — are not CNSA 2.0 compliant, even if they use the same underlying mathematical constructions. Only implementations conforming to the final FIPS 203 and FIPS 204 specifications qualify. Organizations that built early prototypes against draft standards will need to rebuild against the final specifications.

The Algorithm Suite

CNSA 2.0 specifies algorithms in two tiers: general-purpose algorithms that most applications will require, and algorithms approved only for specific use cases.

General-Purpose Algorithms

AES-256 (FIPS 197) remains the symmetric block cipher for information protection, unchanged from CNSA 1.0. AES with 256-bit keys provides 128 bits of security against Grover’s algorithm — sufficient for the foreseeable quantum future. No change needed here, which is one less migration headache for implementers.

ML-KEM-1024 (FIPS 203), formerly CRYSTALS-Kyber, handles key establishment. This is the lattice-based key encapsulation mechanism that replaces RSA key exchange, Diffie-Hellman, ECDH, and all other classical key establishment methods in NSS. CNSA 2.0 mandates the highest parameter set — ML-KEM-1024, corresponding to NIST Security Level 5. Lower parameter sets (ML-KEM-512 and ML-KEM-768) are not approved for NSS, even though NIST standardized them.

ML-DSA-87 (FIPS 204), formerly CRYSTALS-Dilithium, covers digital signatures. It replaces RSA signatures and ECDSA across all use cases, including software and firmware signing. Again, only the highest parameter set is approved. ML-DSA-44 and ML-DSA-65 are not permitted in NSS.

SHA-384 or SHA-512 (FIPS 180-4) for hashing. CNSA 2.0 added SHA-512 as an approved option alongside SHA-384, a minor but practical change from CNSA 1.0, which allowed only SHA-384. Many implementations prefer SHA-512 for performance reasons; this update removed an unnecessary constraint.

Algorithms for Specific Use Cases

LMS and XMSS (NIST SP 800-208) are stateful hash-based signature schemes approved exclusively for firmware and software signing. NSA recommends LMS with SHA-256/192 as the preferred parameter set, though all SP 800-208 parameters are approved. These algorithms have a crucial operational requirement: because they are stateful, each private key can only produce a finite number of signatures, and the signing state must never be reused. NIST SP 800-208 requires signature generation to be implemented in hardware (an HSM), with proper state management to prevent key reuse across backup or failover scenarios.

NSA prioritized LMS and XMSS for firmware signing because validated implementations were commercially available before ML-DSA, and because firmware roots of trust are difficult to update after deployment. A device shipped today with a classical firmware verification algorithm may be locked into that algorithm for its entire operational life. Getting a quantum-resistant signature into the firmware root of trust early avoids expensive retrofits later.

ML-DSA-87 is also approved for firmware and software signing (it is approved for “any use case”), but NSA’s preference for near-term firmware deployments remains LMS/XMSS because of their immediate availability and their well-understood security properties as hash-based schemes. For organizations whose signing workflows require more signatures than a single LMS or XMSS key tree can support, or that operate distributed signing environments, ML-DSA is the appropriate choice.

SHA3-384 or SHA3-512 (FIPS 202) may be used for internal hardware integrity functions, such as boot-up checks, at the vendor’s discretion. This narrow allowance was added in V2.1 as a concession to vendors whose internal processes benefit from SHA-3 properties. SHA-3 is strictly prohibited as a general-purpose hash in CNSA 2.0 — its use is limited to cases where it is completely self-contained within a hardware system’s internal processes or where it is called as a function within an approved algorithm (such as certain LMS parameter sets that reference SHA-3 internally).

What’s Missing: The Exclusions

The exclusions are at least as informative as the inclusions. NSA made deliberate choices to narrow the algorithm menu, and each exclusion reflects a policy judgment worth examining.

SLH-DSA (formerly SPHINCS+) is the most significant exclusion. NIST standardized SLH-DSA as FIPS 205 in August 2024 specifically to provide a conservative, hash-based signature option that does not rely on lattice hardness assumptions. If lattice cryptography were broken by a new mathematical attack, SLH-DSA would remain secure because its security rests on different foundations — the well-studied properties of hash functions. Despite this, NSA excluded it from all NSS use. I examine the implications of this decision in detail in a dedicated article in this series.

The stated reasoning points toward operational pragmatism: SLH-DSA signatures are large (the smallest “fast” variant produces signatures around 17 kilobytes), and adding another algorithm increases interoperability testing burden. But the decision carries a second, implicit signal: NSA is sufficiently confident in the long-term security of lattice-based constructions that they do not consider a non-lattice fallback necessary for national security applications. That confidence is notable, and not every national cryptographic authority shares it. Germany’s BSI recommends SLH-DSA explicitly as a hedge against potential lattice weaknesses.

FN-DSA (formerly Falcon) will not be added to CNSA 2.0 even after NIST finalizes it as FIPS 206 (expected late 2026 or early 2027). NSA agrees with NIST’s assessment that FN-DSA is more susceptible to implementation errors that could affect security. The FAQ goes further: NSA states it “does not currently plan to add future NIST post-quantum standards to CNSA.” This language suggests the algorithm suite is intended to remain stable throughout the transition period, avoiding the complexity of supporting additional options.

HashML-DSA, the pre-hash mode of ML-DSA defined in FIPS 204, is explicitly prohibited. This mode allows a message to be hashed before signing, breaking interoperability with standard ML-DSA to prevent vulnerabilities from key reuse. NSA’s position is that standard SHA-384 or SHA-512 combined with ML-DSA-87 in the normal way provides the same functionality, and supporting HashML-DSA would fragment the implementation ecosystem without adding security value.

HSS and XMSS^MT, the multi-tree variants of LMS and XMSS, are not approved. Only single-tree LMS and XMSS are allowed. Multi-tree variants extend the number of available signatures by building trees of trees, but they add complexity to state management. NSA’s constraint here is consistent with the broader pattern: minimize implementation complexity, reduce the surface area for errors.

SHA-3 and SHAKE as general-purpose hash algorithms are not approved. NSA’s reasoning is straightforward: SHA-2 (specifically SHA-384 and SHA-512) provides sufficient security, enjoys widespread deployment, and maximizes interoperability. Introducing SHA-3 as a general-purpose alternative would expand the testing and certification burden without a corresponding security benefit.

The Timeline

CNSA 2.0 defines two milestones for each system category: a “support and prefer” date (when systems must be capable of using CNSA 2.0 algorithms and should default to them) and an “exclusively use” date (when CNSA 1.0 algorithms are no longer permitted as the sole option). The overall transition is anchored to NSM-10’s 2035 endpoint, but the category-specific dates create a staggered schedule that front-loads the most urgent transitions.

Software and Firmware Signing

Support and prefer by 2025. Exclusively use by 2030.

This category carries the earliest deadline because firmware roots of trust are the hardest components to update after deployment. NSA has urged vendors to begin adopting LMS and XMSS immediately since the original 2022 advisory, and validated implementations from several HSM vendors have been commercially available for over a year. The 2025 “prefer” date means that new firmware and software releases for NSS should already be signed with CNSA 2.0 algorithms. By 2030, classical-only signatures will not be accepted.

Web Browsers, Servers, and Cloud Services

Support and prefer by 2025. Exclusively use by 2033.

The early “prefer” date for web and cloud services reflects the maturity of TLS implementations: hybrid key exchange using ML-KEM is already shipping in major browsers and cloud platforms. The extended “exclusive use” date of 2033 acknowledges the long tail of legacy server infrastructure. NSS web services should already be negotiating CNSA 2.0 algorithms when both endpoints support them.

Traditional Networking Equipment

Support and prefer by 2026. Exclusively use by 2030.

VPNs, routers, and similar infrastructure have an aggressive exclusive-use deadline of 2030. This reflects both the sensitivity of network traffic (which is especially vulnerable to Harvest Now, Decrypt Later (HNDL) collection) and the relatively constrained set of protocols involved (primarily IKEv2/IPsec). The 2026 prefer date is now imminent, meaning NSS network equipment should already be capable of negotiating ML-KEM-1024 key exchange.

A practical complication: IKEv2 cannot yet fully operate without CNSA 1.0 algorithms in all configurations. The FAQ acknowledges this, noting that hybrid approaches using both classical and quantum-resistant algorithms may continue during the transition for key establishment in certain protocols. But CNSA 2.0 algorithms must be present and preferred even in hybrid configurations.

Operating Systems

Support and prefer by 2027. Exclusively use by 2033.

The 2027 “prefer” date for operating systems aligns with the January 2027 acquisition gate. Any operating system deployed on a newly acquired NSS after January 1, 2027, must support CNSA 2.0. This requirement flows directly to OS vendors — Microsoft, Red Hat, and others serving the NSS market must have ML-KEM and ML-DSA support validated and shipping by that date.

Niche Equipment

Support and prefer by 2030. Exclusively use by 2033.

Constrained devices, large PKI systems, and other specialized equipment receive the most generous timeline, reflecting the engineering challenges of implementing post-quantum algorithms on resource-limited hardware and the complexity of migrating large-scale certificate infrastructure. ML-DSA-87 signatures are significantly larger than ECDSA signatures, and ML-KEM-1024 ciphertexts are larger than ECDH shared secrets. For constrained IoT devices and embedded systems, these size increases may require hardware redesigns.

Custom Applications and Legacy Equipment

Update or replace by 2033.

Systems that cannot be updated to support CNSA 2.0 must be replaced. There is no “grandfather clause.” The 2033 date provides nearly a decade from the original advisory, but the clock is running.

Enforcement: How CNSA 2.0 Gets Teeth

A policy without enforcement is a suggestion. CNSA 2.0 has several enforcement mechanisms that give it operational weight.

The January 2027 Acquisition Gate

Starting January 1, 2027, all new acquisitions for National Security Systems must support CNSA 2.0 algorithms unless an exception is explicitly noted in the acquisition documentation. This is the sharpest enforcement mechanism in the entire CNSA 2.0 framework, and I examine its implications in dedicated analysis.

The operative word is “acquisition.” Defense acquisition programs run 18 to 36 months from requirements definition to delivery. A system that begins procurement today and delivers in early 2028 must already include CNSA 2.0 support in its design. For vendors, this means engineering decisions made in 2025 determine whether products are eligible for NSS deployment in 2027. The deadline does not allow catch-up.

NIAP Validation

Products used in NSS require validation by the National Information Assurance Partnership against approved Protection Profiles. NIAP began releasing updated Protection Profiles incorporating CNSA 2.0 algorithms in 2026, as confirmed by NSA’s Dr. Morgan Stern at RSA Conference 2026. Products that have not been validated against these updated profiles will not be eligible for new NSS deployments. The validation process itself takes months, adding another layer of lead time that organizations must account for.

For commercial vendors performing only signature verification (as opposed to generation), the requirement is less demanding: CAVP (Cryptographic Algorithm Validation Program) testing suffices. But for any product that generates signatures, performs key encapsulation, or handles the full cryptographic lifecycle, CMVP (Cryptographic Module Validation Program) validation is required, and that process currently runs 12 to 18 months.

The CNSA 1.0 Compliance Trap

One of the less-noticed enforcement provisions creates an accelerated timeline for organizations that are behind on CNSA 1.0. Any NSS that is not currently compliant with CNSA 1.0 has six months from the publication of the updated CNSSP 15 to achieve compliance with CNSA 2.0 — not CNSA 1.0. If compliance is not achieved within that window, the system must submit a waiver request within 90 days.

The implication is blunt: if you fell behind on CNSA 1.0, you cannot catch up to the old standard. You must leapfrog to the new one. This provision eliminates the possibility of using CNSA 1.0 compliance as a waystation and forces lagging systems directly into the PQC transition.

RMF Integration

Approving Officials must measure CNSA 2.0 compliance through the Risk Management Framework process when assessing Security Control SC-12 (Cryptographic Key Establishment and Management). NSS should not be assessed against “FIPS-validated” in the RMF process; instead, solutions must be “NSA-approved,” a higher bar that includes NIAP validation, correct configuration per CNSSP 15, and adherence to additional NSA guidance.

Waivers

Using any cryptographic algorithm that the National Manager has not approved requires a waiver specific to the algorithm, implementation, and use case. Waivers are not blanket authorizations; each must be individually justified and approved. As I discuss in the defense contractor article in this series, treating waivers as a strategy rather than an exception is a losing approach — each waiver carries administrative cost, creates audit exposure, and requires a remediation plan.

CNSA 2.0 and NIST PQC: Same Algorithms, Different Mandate

A common point of confusion: how does CNSA 2.0 relate to NIST’s post-quantum cryptography standards? The short answer is that CNSA 2.0 is a policy layer built on top of NIST’s standards layer, and the two are complementary but not identical.

NIST standardized the algorithms. FIPS 203 defines ML-KEM with three parameter sets (512, 768, 1024). FIPS 204 defines ML-DSA with three parameter sets (44, 65, 87). FIPS 205 defines SLH-DSA with multiple parameter sets across SHA-2 and SHAKE variants. NIST’s role is to say: “These algorithms are sound. Here are the specifications. Choose what fits your application.”

NSA’s role through CNSA 2.0 is to say: “For National Security Systems, you will use these specific algorithms at these specific parameter levels, and nothing else.” CNSA 2.0 narrows NIST’s menu to a single option per function:

• Key establishment: ML-KEM-1024 only (not 512, not 768)
• Digital signatures: ML-DSA-87 only (not 44, not 65)
• Firmware/software signing: LMS or XMSS (single-tree only), or ML-DSA-87
• Hashing: SHA-384 or SHA-512 only
• Symmetric encryption: AES-256 only

This narrowing serves interoperability. When every NSS product supports exactly the same algorithm at exactly the same parameter level, interoperability testing becomes tractable. The proliferation of options that benefits the broader commercial market would create a combinatorial testing burden in the classified environment.

But the narrowing also creates a gap. NIST standardized SLH-DSA as a conservative option. CNSA 2.0 does not include it. NIST is finalizing FN-DSA for applications where ML-DSA’s signature and public key sizes are problematic. CNSA 2.0 will not include it. Organizations that want the security diversity NIST envisioned — lattice-based algorithms as the primary suite with hash-based and other alternatives as fallbacks — cannot get that within CNSA 2.0’s framework.

This matters for crypto-agility planning. As I discuss in my introduction to crypto-agility, the ability to swap algorithms without re-architecting systems is essential because no algorithm is guaranteed permanent. CNSA 2.0 is a snapshot of NSA’s current assessment. If lattice hardness assumptions were to weaken, the suite would need to be revised. Organizations that design for crypto-agility now will be able to respond to such a revision without an emergency migration.

Reading Between the Lines

Every algorithm suite encodes assumptions about the threat environment. CNSA 2.0 is no exception. Three signals emerge from NSA’s choices.

NSA is confident in lattice cryptography. The decision to exclude SLH-DSA and to preemptively rule out future algorithm additions is a strong expression of confidence in the long-term security of lattice-based constructions. NSA performed its own analysis and “considers [CNSA 2.0 algorithms] appropriate for long-term use in protecting the varied missions of U.S. NSS.” For an organization that protects national secrets with multi-decade sensitivity, “long-term” means exactly what it sounds like. They are betting that lattice assumptions will hold.

This does not mean the bet is riskless. The academic cryptanalysis community continues to probe lattice problems, and several national authorities (notably Germany’s BSI) maintain a more cautious posture by recommending algorithm diversity. But NSA has decided that operational simplicity and interoperability outweigh the hedging value of algorithmic diversity for NSS.

NSA sees firmware signing as the most urgent transition. The earliest deadlines, the strongest language, and the most detailed implementation guidance all cluster around firmware and software signing. This reflects a pragmatic assessment: firmware verification algorithms, once deployed, may be locked in for the operational life of the hardware. A router deployed in 2025 with only ECDSA firmware verification might still be in service in 2040. If a cryptanalytically relevant quantum computer (CRQC) exists by then, that router’s firmware integrity cannot be trusted. Building quantum-resistant roots of trust now is insurance against a future that cannot be patched retroactively.

This priority connects directly to my CRQC Quantum Capability Framework. The capabilities required to build a CRQC are advancing across multiple engineering fronts simultaneously. Whether a CRQC arrives in 2032 or 2042, systems deployed today with classical-only firmware verification face the same vulnerability. The only variable is the urgency — and NSA has decided the urgency is sufficient to mandate immediate action on firmware signing.

NSA is optimizing for a managed transition, not a panicked one. The staggered timeline, the allowance for hybrid deployments during transition periods, and the measured extension of deadlines for niche equipment all suggest that NSA expects this migration to take years and is planning accordingly. This is not a crisis response. It is an orderly phase-out of algorithms that are expected to become vulnerable within the operational lifetime of currently deployed systems.

The contrast with how some in the private sector frame the quantum threat is instructive. As I have written about the quantum panic industry, the commercial market sometimes oscillates between breathless urgency and dismissive skepticism. NSA’s approach occupies neither extreme: the threat is real enough to mandate action with hard deadlines, but not so imminent that it requires emergency measures. That calibration is useful for any organization trying to set its own quantum readiness timeline.

Beyond NSS: Why CNSA 2.0 Matters Even If It Doesn’t Apply to You

CNSA 2.0 formally applies only to National Security Systems. In practice, its influence extends considerably further, for three reasons.

First, the defense industrial base supply chain carries the requirement downstream. Any defense contractor, sub-tier supplier, or commercial vendor whose products are deployed in or interact with NSS is directly affected. If your networking equipment, operating system, or HSM ends up in a classified environment, it must meet CNSA 2.0 requirements. The prime contractor will flow these requirements down, and starting in 2027, products that cannot demonstrate CNSA 2.0 support will lose eligibility for NSS-adjacent contracts. I cover the full implications for defense contractors in Part 4 of this series.

Second, CNSA 2.0 is becoming a de facto benchmark for high-assurance cryptography in commercial sectors. Major banks are already referencing CNSA 2.0 algorithm choices in procurement language. Insurance underwriters are beginning to ask about post-quantum readiness, and CNSA 2.0 provides a concrete standard to reference. I explore why financial services organizations are adopting CNSA 2.0 voluntarily in Part 5.

Third, allied nations are paying attention. Australia’s ASD has recommended ML-DSA-87 (the same parameter level CNSA 2.0 mandates). NATO interoperability requirements will likely converge on CNSA 2.0 algorithm choices for allied systems that need to communicate with U.S. NSS. The suite is becoming the reference point for the “Five Eyes plus” security ecosystem, even as European authorities diverge on specific choices like SLH-DSA.

As I have argued consistently, the debate about when Q-Day will arrive is becoming secondary to the ecosystem of deadlines that are already set. Regulators, insurers, investors, and clients are creating their own quantum clocks, and CNSA 2.0 is one of the loudest. Whether a CRQC exists in 2032 or 2042, the January 2027 acquisition gate arrives in eight months regardless.

Where to Start

For organizations that need to act on CNSA 2.0, the path forward has several immediate steps:

Inventory your cryptographic dependencies. Before you can migrate, you need to know what you are migrating from. Identify every use of RSA, ECDSA, ECDH, and Diffie-Hellman in your products and infrastructure. The PQC Migration Framework at pqcframework.com provides a structured methodology for this inventory.

Determine your CNSA 2.0 exposure. Do any of your products, systems, or services touch National Security Systems? Do any of your customers sell into NSS? If the answer to either question is yes, CNSA 2.0 applies to you, at minimum through your supply chain obligations.

Prioritize firmware and software signing. If your products include firmware, the signing mechanism should be your first migration target. Validated LMS and XMSS implementations are commercially available from several HSM vendors today. Waiting for ML-DSA validation to become widespread is an option, but it introduces timeline risk given the CMVP queue.

Begin FIPS 140-3 planning now. NIST moves all FIPS 140-2 certificates to Historical status in September 2026. Federal procurement will require FIPS 140-3 validated modules. If your cryptographic module needs to support both FIPS 140-3 validation and CNSA 2.0 algorithms, the combined lead time for both processes means starting immediately.

Design for crypto-agility. CNSA 2.0 represents NSA’s current assessment, not a permanent endpoint. As I discuss in my introduction to crypto-agility, the ability to update cryptographic algorithms without re-architecting systems is essential insurance against future algorithm changes. Build your migration with the assumption that you may need to swap algorithms again within the lifetime of the system.

For the broader organizational readiness question — how to build the business case, brief a board, and staff the migration program — Quantum Ready covers the strategic dimension comprehensively. And for a detailed walkthrough of the first concrete actions, see my Practical Steps to Quantum Readiness guide.

CNSA 2.0 is the clearest answer the U.S. government has given to the question “what should we actually do about the quantum threat?” The algorithms are selected. The timelines are published. The enforcement mechanisms are in place. What remains is execution.