A recent Quantum Insider analysis lays out a math problem that federal program offices have been avoiding. The National Security Agency's CNSA 2.0 timeline calls for new National Security Systems to use quantum-resistant algorithms by the start of 2027. From today, that is under 230 days. Most program offices have not finished a cryptographic inventory, let alone a migration.This is no longer a strategic planning conversation. It is an execution problem with a fixed deadline.
CNSA 2.0 sets the algorithms: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for signatures, SLH-DSA (FIPS 205) as the stateless hash-based backup, and CNSA-2-approved symmetric primitives. New NSS acquisitions starting in 2027 are expected to default to these algorithms. By 2030, all NSS, new and legacy, must be quantum-resistant. By 2035, NIST is set to prohibit the classical RSA and elliptic-curve algorithms still running most federal infrastructure today.
Three deadlines, three different problems. The 2027 milestone is the closest, and it is the one most program offices are least prepared for, because it forces a decision about every new acquisition: how is this system meeting CNSA 2.0?
The honest answer is that the work nobody wants to do has not been done. Three patterns recur across federal program offices we encounter.
No accurate cryptographic inventory. Most agencies cannot produce a current list of where RSA, ECDSA, and ECDH are in use across their stack, let alone which keys are managed by which CA, which protocols use which suites, and where the dependencies cross system boundaries. NIST has been clear that inventory is the prerequisite to migration, and the inventory has not been built.
PKI is the bottleneck. Post-quantum algorithms are heavier. ML-DSA signatures are roughly 17x larger than ECDSA. ML-KEM public keys are roughly 30x larger than ECDH. Existing PKI infrastructure, including certificate authorities, certificate stores, TLS stacks, and embedded firmware update paths, was not built for these payload sizes or these performance profiles. The migration is not a drop-in algorithm swap. It is a structural change to how trust is provisioned and renewed.
Hybrid is the consensus, and hybrid doubles the work. Google and Meta have published the lessons from their large-scale PQC rollouts. Both are running hybrid, meaning classical and post-quantum side by side, to hedge against undiscovered weaknesses in the new algorithms. That is the right call. It also means every system temporarily carries two cryptographic stacks, two key types, and two failure modes. For program offices still trying to manage one PKI, doubling the surface area is a serious problem.
For program offices that need to land the 2027 milestone, the work has to be triaged. Trying to migrate everything in 230 days is not realistic. Landing CNSA 2.0 on new acquisitions is.
Days 1 to 30: Inventory the new pipeline, not the legacy estate. The legacy estate has until 2030. The 2027 deadline is about new acquisitions. Pull the list of every NSS-bound system entering acquisition or development in the next 18 months. For each one, identify which cryptographic primitives it relies on and where the dependencies sit. This is a smaller, tractable list.
Days 31 to 90: Identify the PKI dependencies that will block migration. For each new system, map the trust anchors, certificate paths, and key management dependencies. The ones that depend on classical PKI for device identity, code signing, or session establishment are the ones that will be hardest to land on CNSA 2.0 in time.
Days 91 to 150: Pilot hybrid where possible, and identify candidates for architectural replacement where it is not. Some systems can run hybrid TLS, hybrid signatures, and hybrid key exchange in a way that satisfies the new requirements and stays interoperable with existing infrastructure. Others, particularly constrained or air-gapped systems, cannot accommodate the payload size or the operational overhead of two parallel cryptographic stacks. Those systems need a different architecture, not a heavier version of the one they already have.
Days 151 to 200: Document, harden, and prepare for the auditors. The 2027 milestone will be measured. New NSS programs will have to demonstrate CNSA 2.0 alignment as part of acquisition gating. Programs that have done the work need to be able to show their work.
CNSA 2.0 is a forcing function. It is also a preview of every cryptographic transition that will follow. The 2030 deprecation is coming. The 2035 prohibition is coming. After that, every time the standards body changes its mind about a primitive, the same migration will have to happen again.
The agencies that will move smoothly through 2030 and 2035 are the ones that build cryptographic agility into the architecture now. That means a current cryptographic inventory, a clear separation between the protocol layer and the algorithms that ride underneath it, and a key management system that does not assume a specific cryptographic primitive will live forever.
This is where the structural argument against PKI lands hardest. PKI was designed in the pre-quantum era around assumptions, including long-lived certificates, persistent credentials, and asymmetric trust, that were never going to age well. Bolting post-quantum algorithms onto that architecture preserves the architectural flaws and adds the operational weight of the new primitives.
AKMSecure takes a different approach. Autonomous Key Management™ is built on a symmetric-key, session-based architecture that is natively quantum-resistant, with no post-quantum retrofit required. Every session is independently verified with no persistent credentials. There are no certificates to rotate, no CAs to upgrade, and no key sizes to renegotiate when the standards change. When NIST changes its recommended algorithms in 2030, 2035, or 2040, AKM-protected systems do not need to be re-architected. The protocol stays. The math underneath it changes.
That is the actual definition of cryptographic agility, and it is what the 2027 deadline is quietly asking program offices to invest in.
AKMSecure delivers a patented Autonomous Key Management™ protocol built to replace outdated PKI approaches with a dynamic, quantum-secure, air-gapped-capable architecture. Instead of relying on persistent credentials that can be stolen, reused, or abused, AKM enables independently verified sessions with no standing privileges left behind. The result is a model that better aligns with Zero Trust principles, reduces certificate-based risk, and supports resilient operations across enterprise IT, OT and Tactical Edge environments. Built to NSA-grade security standards and deployable as a lightweight SDK, AKMSecure helps organizations modernize trust at the protocol layer without rebuilding everything around it.