Quantum computing does not need to arrive on schedule for your quantum-readiness program to be late. The deadlines already have dates.
That distinction matters. Too much of the conversation around post-quantum cryptography still centers on predicting when a cryptographically relevant quantum computer will exist. It could be sooner than expected, or it could take longer. NIST and the National Security Agency have deliberately removed that uncertainty from migration planning. They have published transition schedules that tell organizations when today’s public-key cryptography must give way to quantum-resistant alternatives.
This is the second post in our quantum readiness series. The first focused on harvest now, decrypt later, and why long-lived data can already be exposed even though a capable quantum computer does not yet exist. The next question is more operational: when do organizations have to move? For many systems, the answer is already on the calendar.
NIST Has Defined the Outer Boundary
NIST finalized its first post-quantum cryptography standards in 2024, including ML-KEM for key establishment and ML-DSA for digital signatures. That moved the discussion from algorithm selection to migration. Organizations no longer need to wait for the final standards to begin the work.
NIST’s transition framework establishes the direction for quantum-vulnerable public-key algorithms. RSA, elliptic-curve cryptography, and other affected schemes move toward deprecation after 2030 and disallowance after 2035, depending on algorithm, parameter set, and use. NIST describes 2035 as the point by which quantum-vulnerable algorithms are expected to be removed from its standards, with higher-risk systems moving earlier.
Read that carefully. 2035 is not a forecast for the arrival of a quantum computer. It is a migration boundary. Whether a cryptographically relevant quantum computer arrives in 2031, 2038, or later does not change the work required to identify vulnerable cryptography, update products and applications, test interoperability, replace unsupported components, and retire old implementations.
CNSA 2.0 Makes the Calendar More Concrete
For U.S. National Security Systems, CNSA 2.0 is more prescriptive. NSA did not publish one distant finish line and leave every technology team to work backward from it. It created a category-by-category transition schedule, because the migration path for code signing is not the same as the path for routers, operating systems, cloud services, or a custom application written twenty years ago.
The milestones create a sequence that organizations can plan against:
- Software and firmware signing: support and prefer CNSA 2.0 by 2025, with exclusive use by 2030.
- Web browsers, servers, and cloud services: support and prefer CNSA 2.0 by 2025, with exclusive use by 2033.
- Traditional networking equipment, including VPNs and routers: support and prefer CNSA 2.0 by 2026, with exclusive use by 2030.
- Operating systems: support and prefer CNSA 2.0 by 2027, with exclusive use by 2033.
- Custom applications and legacy equipment: update or replace by 2033.
The 2027 acquisition requirement adds another forcing function for National Security Systems. New acquisitions must be planned around CNSA 2.0 support rather than buying another generation of technology that creates a future migration problem. Procurement decisions made now can either reduce the transition workload or lock it in.
The Dangerous Date Is Not 2035
A common planning mistake is to look at 2035, count nine years from 2026, and conclude that there is plenty of time. That is the wrong calendar. An enterprise does not migrate cryptography in one event. It migrates thousands of dependencies across products, protocols, certificates, libraries, applications, interfaces, hardware devices, and third-party services. Some can change through configuration. Others require code changes, vendor upgrades, architectural work, or complete replacement.
For a custom application estate, 2033 is much closer than it appears. If a legacy application requires eighteen months to analyze, remediate, test, certify, and deploy, the deadline is not December 2033. The practical deadline is when that work must start. Multiply that problem across hundreds of applications competing for the same architects, security teams, test environments, funding, and release windows, and the available runway contracts quickly.
This is why you should treat published dates as fixed points in a portfolio plan, not as dates to begin thinking about the problem.
Work Backward, Not Forward
The useful planning question is not, “When will quantum computers break RSA?” No CIO or CISO can answer that with enough precision to build a responsible program. The useful question is, “What must be true about our environment by 2030, 2033, and 2035?” That question can be answered.
Start with the fixed dates, then work backward through the dependencies. Which systems contain RSA or ECC? Which vendors have committed to post-quantum support? Which applications can accept a library or platform upgrade, and which have cryptography embedded directly in old code? Which interfaces require coordinated changes on both ends? Which systems will reach end of life before their cryptographic deadline, making replacement more sensible than remediation?
That exercise turns quantum readiness from a technology prediction into a portfolio management problem. It also exposes an uncomfortable reality: the systems most likely to consume the most time are often the systems organizations understand the least. Older custom applications frequently have incomplete documentation, hidden dependencies, unsupported components, and institutional knowledge concentrated in a few people. Those are exactly the systems that should move to the front of discovery.
The Clock Is a Planning Tool
Debating whether NIST’s dates are conservative or whether the quantum threat will materialize sooner offers no benefit. The standards and transition schedules already provide enough direction to act. NIST has established the outer migration framework. CNSA 2.0 shows what a staged, technology-specific transition looks like when national security is at stake.
The organizations that handle this well will not wait for a quantum breakthrough to create urgency. They will use the dates that already exist to inventory cryptography, sequence the portfolio, align refresh cycles, and remove vulnerable dependencies while there is still room to make deliberate decisions.
The deadlines were always coming. Now they are written down.
The next post in this series looks at what changed in 2026 and why the migration window is becoming less forgiving, even though the final dates have not moved.
Book a Call with Aspen
f your board, customers, or regulators are asking about quantum readiness and you are unsure how your legacy application portfolio fits the NIST or CNSA 2.0 timeline, let’s talk. Aspen can help you understand what is in your systems, identify where cryptographic risk is concentrated, and build a modernization roadmap around existing deadlines.
Schedule a discovery chat: https://calendly.com/aspen-ess/aspen-ess-discovery-chat
