Does CNSA 2.0 apply to quantum tooling?
Yes — if your quantum tooling seals workloads, signs audit records, or establishes keys for cloud routing in an NSS program, it falls under CNSA 2.0 the same way classical cryptographic modules do. The January 1, 2027 deadline for new NSS acquisitions is not a recommendation.
What CNSA 2.0 requires
NSA's Commercial National Security Algorithm Suite 2.0 mandates ML-DSA (FIPS 204) for digital signatures and ML-KEM (FIPS 203) for key establishment. For NSS deployments, the default parameters are ML-DSA-87 and ML-KEM-1024. Firmware signing follows SP 800-208 where applicable.
Where quantum tooling fails today
- IBM Quantum, IonQ, Amazon Braket, Rigetti, and Quantinuum use classical TLS and account-level API keys — not CNSA 2.0 at the workload layer
- Experiment results arrive unsigned — no ML-DSA binding between submitter and execution record
- Most SDK integrations have no SP 800-208 signed release manifests or published SBOM
What "compliant" looks like
A CNSA 2.0-ready quantum provenance layer signs every workload with ML-DSA-87 before execution, uses ML-KEM-1024 for cloud routing key exchange, and produces offline-verifiable audit records. Air-gap deployment eliminates cloud dependency entirely for classified programs.
Open schema: audit-record-schema.json