CNSA 2.0 Compliance on QNSI: ML-KEM-1024 and ML-DSA-87 as a Policy Setting

Evidence boundary: any present-tense QNSI product wording below describes source-declared contracts, architecture targets, or vendor-run artifacts-not independently observed production behavior. Conformance artifacts prove only their stated algorithm scope. End-to-end production execution is NOT VERIFIED.

If you build, operate, or supply US national security systems, CNSA 2.0 is not a forecast - it is the algorithm suite your buyers will hold you to, and new national-security systems are expected to run it from January 2027. That is months away, not years. Meanwhile most estates are still keyed on RSA and ECDSA, and every quarter of delay grows the pile of recorded traffic an adversary can decrypt later.

QNSI maps CNSA 2.0 algorithms to maximum/government policy source contracts. Platform-wide enforcement, dual-control effects, audit ingestion, and deployment behavior remain NOT VERIFIED.

CNSA 2.0 in 60 seconds

Two operational readings matter. The dates are completion dates, not start dates. And harvest-now-decrypt-later means long-lived secrets are exposed today, before any deadline arrives.

What it is: the NSA's Commercial National Security Algorithm Suite 2.0 - the algorithms required to protect US national security systems (NSS) in the quantum era.
Asymmetric: ML-KEM-1024 (FIPS 203) for key establishment; ML-DSA-87 (FIPS 204) for signatures; hash-based signatures for software and firmware signing.
Symmetric and hashing stay classical but raised: AES-256 and SHA-384.
When: new NSS from January 2027, with staged exclusive-use dates per product category running through roughly 2030-2033 - and the end state for NSS is pure PQC, not hybrid.
Who: NSS owners and the vendors and contractors who supply them. It flows down the supply chain - and commercial regulated buyers increasingly borrow it as their working definition of quantum-safe.

On QNSI, the suite is a policy tier

QNSI enforces crypto policy per tenant across four tiers. Government permits FIPS-finalized algorithms only and can require HSM custody. That requirement fails closed unless an evidence-backed, live-qualified HSM path is active.

The source contract checks policy at key generation and key use and rejects stale downgrade modes. Complete operation coverage and deployment behavior remain NOT VERIFIED:

import { QnsiClient } from "@heossihq/qnsi";

const qnsi = new QnsiClient({ apiKey: process.env.QNSI_API_KEY! });

// On a government-tier tenant, only FIPS-finalized algorithms exist:
await qnsi.kms.createKey({ algorithm: "kyber-1024", purpose: "kem" }); // ML-KEM-1024 - allowed
await qnsi.kms.createKey({ algorithm: "dilithium-5", purpose: "signing" }); // ML-DSA-87 - allowed
await qnsi.kms.createKey({ algorithm: "kyber-512", purpose: "kem" }); // rejected by policy

The policy itself is under dual control

The source defines maker-checker contracts for crypto-policy changes, tenant deletion, and root/master key revocation. Complete requester/approver separation, application effects, and deployment behavior remain NOT VERIFIED.

Source defines audit events and ML-DSA root-signing contracts for approval workflows. Complete event ingestion, publication, and independent reconstruction remain NOT VERIFIED.

The evidence file you hand the assessor

Public algorithm conformance: live NIST ACVP evidence for both of QNSI's independent implementations (liboqs primary, @noble/post-quantum cross-verifying secondary) at qnsi.heossi.com/verify/conformance.
Operational provenance: source-defined hash chaining and ML-DSA checkpoint signatures, with complete event coverage verified separately from the recorded deployment.
Inventory: the CBOM crypto inventory with CycloneDX export and PQC readiness scoring - the artifact EO 14412 (June 2026) points at, with CBOM minimum elements due within 270 days, and the fastest way to find every RSA/ECDSA holdout before your assessor does.
Adjacent frameworks: compliance evidence packs for SOC 2, ISO 27001, HIPAA, GDPR, PCI DSS, PDPA, and MAS TRM - because a CNSA-aligned program rarely answers to only one regime.

Verify before you engage: QNSI's NIST ACVP conformance evidence is public at qnsi.heossi.com/verify/conformance - per-algorithm results, regenerated each release, no account required.

The honest line

Mapping to CNSA 2.0 and producing evidence is not the same as holding an NSA certification or CMVP validation. Customer HSM custody is a deployment-specific result: the selected device, configuration, operations, and vendor-certificate scope must pass qualification before QNSI represents the root as hardware-backed.

Your first 90 days

Stand up a Free Forever tenant and run the CBOM inventory across your clouds - know exactly where RSA and ECDSA still live.
Put new and NSS-adjacent workloads on the maximum or government tier now. January 2027 is about new systems first - greenfield is where alignment is cheapest.
Re-key long-horizon secrets onto ML-KEM-1024-backed keys, using KMS rotation and in-place key algorithm upgrade.
Turn on dual-control approvals, export the evidence pack, and put the ACVP conformance link in front of your assessor.

Start now

A workspace can expose policy call surfaces, but a rejection response is not independent proof of deployment-wide enforcement. Complete policy coverage remains NOT VERIFIED.

Scoping a CNSA 2.0 program - NSS, defense supply chain, or a regulated buyer borrowing the suite? Talk to an architect at /contact.