CNSA 2.0 Just Narrowed the PQC Field. ML-KEM-768 Will Not Clear NSS.
NSA's April 2026 clarification narrowed the post-quantum cryptography field for National Security Systems. The CNSA 2.0 algorithm suite now requires ML-KEM-1024 for key encapsulation and ML-DSA-87 for digital signatures. ML-KEM-768 will not clear NSS workloads, regardless of how a vendor labeled it.
The clarification matters because the NIST post-quantum standardization process produced parameter set choices, not single algorithms. ML-KEM is the standard. ML-KEM-768 and ML-KEM-1024 are different parameter sets within that standard, and they target different security strengths against the same adversary model.
What changed in April
NSA's CNSA 2.0 guidance had named ML-KEM and ML-DSA since publication. The April 2026 update specified that NSS deployments must use the highest published parameter sets, ML-KEM-1024 and ML-DSA-87, not the smaller ML-KEM-768 or ML-DSA-65. The latter two remain acceptable for civilian federal workloads under the broader NIST FIPS 203 and FIPS 204 standards.
Vendors that listed ML-KEM-768 against NSS workloads had a footnote problem before April. After the clarification, those statements need rewrites. PQC-ready is now a parameter-set claim, not a marketing line.
Why parameter sets matter
ML-KEM-768 targets NIST security category 3, roughly equivalent to AES-192 against a quantum-capable adversary. ML-KEM-1024 targets NIST security category 5, AES-256 equivalent. For NSS deployments where data confidentiality requirements span decades and the adversary is assumed nation-state, category 5 is the floor.
The same logic applies to digital signatures. ML-DSA-65 targets category 3, ML-DSA-87 targets category 5. The CNSA 2.0 baseline is category 5 across the board. There is no path to compliance through smaller parameter sets, regardless of performance or implementation cost trade-offs.
What this means for procurement
DoD program offices building FY27 acquisition packages now have a binary criterion. The product implements ML-KEM-1024 and ML-DSA-87 against the published NIST FIPS 203 and FIPS 204 test vectors, or it does not. There is no partial credit for ML-KEM-768.
Solicitations that closed before the April 2026 clarification may have been answered by vendors who interpreted CNSA 2.0 broadly. Those statements remain valid against the prior baseline. Solicitations that close from May 2026 forward will reference the clarification by name. Vendors can no longer treat "PQC-ready" as a synonym for "any ML-KEM parameter set."
How Lattix implements CNSA 2.0 in production
Lattix Technologies binds parameter-set selection to data classification at the policy decision point (PDP). Each object's classification metadata is the input the PDP reads when releasing a wrapping key. A civilian-classified object inherits ML-KEM-768. An NSS-classified object inherits ML-KEM-1024 and ML-DSA-87. Both classes run through the same deployment, the same policy engine, the same SDKs. Application code does not change between deployment classes.
The integration is policy-first, not codebase-first. Existing applications continue to read and write through the Lattix SDKs and APIs. The policy enforcement point (PEP) intercepts the read or write event, evaluates the ABAC policy against the requesting principal's attributes and the object's classification, and releases the wrapping key under the parameter set the policy names. An application that compiled under ML-KEM-768 in 2026 will accept ML-KEM-1024 in 2027 because cryptographic agility is a property of the platform, not the calling code.
For NSS workloads, every encrypted object inherits ML-KEM-1024 and ML-DSA-87 by policy at write time. Audit reduces to a query against Merkle-tree lineage in tamper-evident audit storage. The lineage record names the parameter set in effect at every read and every key release, so the assessor's question, "did this object decrypt under CNSA 2.0 parameters at this access," reduces to a deterministic lookup rather than a log reconstruction.
Hybrid deployments are supported through the same policy mechanism. Programs that need to interoperate with classical-cryptography consumers run hybrid mode on a per-object basis: the object carries both a classical-wrapped key and a post-quantum-wrapped key, and the consumer reads whichever it can decrypt. The policy authority controls the hybrid window and closes it on a schedule, not on a code release.
The migration path Lattix runs against
Programs that have not yet bound their data layer to PQC parameter sets follow a four-step sequence with the Lattix platform.
First, inventory the NSS data flows, shared-storage locations, and cross-domain solutions that touch CUI or classified data. The classification inventory feeds the policy authority. The storage inventory feeds the wrapping coverage plan.
Second, wrap at write. Stand up the PEP next to the highest-volume NSS data producers. Configure the policy authority so newly produced NSS objects wrap under ML-KEM-1024 and ML-DSA-87 from the moment of creation. New flows enter the architecture compliant.
Third, backfill. Re-wrap existing NSS objects against the higher parameter set. The backfill happens at the wrapper layer through a key authority rotation, not by re-encrypting and re-distributing each object. The lineage records the rotation, so the assessor can verify that every legacy object now sits under CNSA 2.0 parameters.
Fourth, evidence. Pull the audit pack from lineage. The pack lists every object, the parameter set in effect, the principals that decrypted, and the policy version that authorized each release. The C3PAO or NSS assessor reads the pack against the FY27 acquisition language directly. The artifact composes from the platform's normal logs, not from a separate compliance pipeline assembled for the audit.
What to do this quarter
Review vendor responses against the CNSA 2.0 April 2026 clarification, not the September 2022 original. Reject any NSS bid that lists ML-KEM-768 or ML-DSA-65 as the post-quantum baseline. For civilian workloads, both parameter sets remain acceptable, but the FY27 ramp will favor architectures that can rotate between them on policy.
The clarification is not a new standard. It is a narrowing of the field. Vendors that already implement the higher parameter sets are compliant. Vendors that did not are revising statements, and the revision tells procurement reviewers everything they need to know about how seriously the vendor took the original guidance.