← Back to Blog
Post-Quantum CryptographyNSACNSADefenseCompliance

CNSA 2.0 and the January 2027 Deadline for National Security Systems

Lattix branded cover for CNSA 2.0 and the January 2027 Deadline for National Security Systems. /18 section number, twenty months remaining statistic, ML-KEM-1024 / ML-DSA-87 algorithm metadata, IBM Plex Mono on dark grid background, surgical yellow accent on the January 2027 milestone in a transition timeline strip.

The NSA's Commercial National Security Algorithm Suite 2.0 binds new acquisitions for National Security Systems to ML-KEM-1024 and ML-DSA-87 effective January 1, 2027. The deadline is set. The algorithm choice is set. The 2030 and 2035 follow-on milestones for applications and infrastructure are set. What program offices choose between now and January is the transition pattern, and the transition pattern determines whether the deadline lands as a procurement formality or as a rebuild.

The CNSA 2.0 timeline published by NSA Cybersecurity Directorate in CSA-U/OO-181708-22 sets four cascading milestones. New NSS acquisitions: January 1, 2027. Software and firmware signing: full exclusive use beginning January 1, 2027. Operating systems, custom applications, and cloud services: full migration by 2033. National Security Systems infrastructure end-to-end: full migration by 2035. The cascade is intentional. The 2027 mark gives program offices three years to align acquisitions before the application layer comes due, and another two years before the infrastructure has to follow.

What CNSA 2.0 requires

The suite specifies ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) for digital signatures, AES-256 for symmetric encryption, and SHA-384 or SHA-512 for hashing. The parameter selection is narrow. NSA mandates ML-KEM-1024 specifically, not ML-KEM-768 or ML-KEM-512. NSA mandates ML-DSA-87 specifically, not ML-DSA-65 or ML-DSA-44. The November 2025 update to CNSA 2.0 sharpened this further: the suite is the exclusive algorithm set for NSS once each milestone hits. Hybrid modes that pair a post-quantum algorithm with a classical algorithm are explicitly disallowed beyond the migration period.

The exclusivity is what separates CNSA 2.0 from the NIST civilian timeline under NIST IR 8547. NIST's transition guidance allows hybrid deployments through 2030. CNSA 2.0 does not. A vendor delivering an NSS-bound system after January 1, 2027 ships ML-KEM-1024 and ML-DSA-87 or fails compliance. The acquisition language already reflects this. The FY26 and FY27 contract packages from major NSS program offices carry CNSA 2.0 language in the cryptographic requirements section, and contracting officers are rejecting bids that do not name the specific algorithms.

Why migration is harder than the algorithm choice

The hard part of post-quantum migration is not selecting ML-KEM-1024. NIST published the FIPS standards in August 2024. The reference implementations are available. The major cryptographic libraries shipped support in 2024 and 2025. Selecting the algorithm is a build step that takes hours.

The hard part is decoupling the algorithm choice from the application code. Most cryptographic implementations across the Defense Industrial Base treat the key exchange algorithm, the key wrapping logic, and the policy that gates the wrap and unwrap as tightly coupled application concerns. Migration in this architecture means rebuilding the application against the new algorithm. The build, the test, the validation, the certification, and the re-authorization cycles run on calendar timelines that do not align with the CNSA 2.0 cascade.

Program offices that have run migration exercises through 2025 report consistent failure modes. The algorithm swap itself completes in days. The cryptographic module validation against FIPS 140-3 with the new algorithm completes in months under CMVP. The application re-test against the validated module completes in additional months. The Authority to Operate re-issuance under RMF completes in additional months. The end-to-end calendar from algorithm selection to deployed system runs twelve to eighteen months for a single application. A program with twenty applications under one ATO boundary multiplies that by twenty.

The CNSA 2.0 cascade compresses the calendar through 2030 for applications and through 2035 for infrastructure. Programs that migrate one application at a time against tightly coupled cryptography will not finish the application layer by the 2030 milestone.

The architectural pattern that decouples the choice from the code

Cryptographic agility is the term of art. The architectural pattern is wrapped-key, policy-bound data objects with the cryptographic operation performed by a centralized, validated module that the application does not implement directly.

In this pattern, each data object carries its own data encryption key. The data encryption key is wrapped under a key-wrapping operation performed by a key access service. The application does not encrypt or decrypt directly. The application requests a release from the key access service, and the service performs the cryptographic operation under whichever validated algorithm the service is currently configured to use. Rotating from a legacy algorithm to ML-KEM-1024 is a configuration change in the key access service plus a re-wrap pass over the existing data. The application code does not change. The cryptographic module validation refreshes once for the service, not once per application.

The pattern has a second property that matters under CNSA 2.0. The wrapped-key architecture preserves cryptographic operation on the object during the transition. Data wrapped under the legacy algorithm remains readable until the re-wrap pass completes. Data wrapped under ML-KEM-1024 after the re-wrap is readable under the new algorithm. The migration runs at the service layer without taking the application offline.

How Lattix supports the migration

Lattix Technologies implements this pattern. The Lattix Key Access Service performs key wrapping and policy evaluation. The cryptographic module is FIPS 140-3 validated and supports ML-KEM-768, ML-KEM-1024, and ML-DSA-87. Application clients call a stable API to request key release. The algorithm in use at the service layer is a configuration. Re-wrap operations against existing data run as a service-side process that does not require application changes.

A program migrating to CNSA 2.0 under this pattern executes three operations. First, the key access service moves to ML-KEM-1024 in configuration. Second, a re-wrap pass runs over the protected data store. Third, new data created after the cutover wraps under the new algorithm. The application clients do not change. The cryptographic module re-validates once. The ATO refresh runs against the service boundary, not the application boundary.

The pattern does not eliminate the work. It bounds the work to a single service layer that the program office controls, and removes the multiplier across the application portfolio. A twenty-application program under one ATO migrates the service once, runs the re-wrap pass once, and re-authorizes against the service layer.

What program offices should be doing now

Twenty months between today and the January 2027 mark is enough time to migrate a program that starts the architecture work in the current quarter. It is not enough time to migrate a program that delays into Q4 2026.

The starting work is an inventory and a coupling assessment. The inventory identifies every cryptographic operation across the program's application portfolio. The coupling assessment determines, for each operation, whether the algorithm is implemented in application code, in a shared library called by application code, or in a centralized service. Operations implemented in application code carry the full migration calendar. Operations behind a shared library cut the calendar. Operations behind a centralized service cut the calendar further and concentrate the validation work.

Programs that finish the inventory and coupling assessment in Q2 and Q3 2026 have a defensible path to January 2027. Programs that have not started the assessment by Q4 2026 will accept rebuild risk on the application layer or accept procurement delay on the acquisition layer.

The January 2027 mark is procurement-facing. The 2030 mark is application-facing. The 2035 mark is infrastructure-facing. Programs that align the architecture against all three marks now will face one transition. Programs that align against each mark in turn will face three.

References

← Back to Blog