The federal post-quantum migration clock moved while many organizations were still discussing whether to start an inventory. In June 2026, the White House put dates against the work. The first major deadline is not 2035. For the most sensitive federal civilian systems, it is 2030.
Executive Order 14412, signed June 22, and OMB Memorandum M-26-15, issued two days later, turned a long-range transition into an accountable program. Agencies must name a migration lead, submit a plan, and move their highest-priority systems through key establishment and digital-signature milestones. For CIOs with older application portfolios, this changes the planning conversation now, even where the order does not directly bind their organization.
This is the third post in our quantum readiness series. The first addressed the exposure created when adversaries collect encrypted data today for future decryption. The second explained the NIST and CNSA 2.0 schedules. The new development is execution: a federal timetable with owners, plans, phases, and nearer dates.
June 2026: Put Names and Dates on the Work
The executive order directs each federal agency head to identify a post-quantum cryptography (PQC) migration lead within 30 days of June 22. That lead reports to the CIO and oversees the cryptographic inventory, the prioritized plan, and coordination across the agency. OMB’s memo then requires agencies to submit their migration plans to OMB and the Office of the National Cyber Director within 120 days of June 24. The plan is due in October 2026, well before most systems will be ready to move.
The deadlines are specific. Federal high-value assets and high-impact systems, excluding National Security Systems, must use PQC for key establishment by December 31, 2030, and for digital signatures by December 31, 2031. OMB asks agencies to prioritize other systems with highly sensitive data or elevated quantum risk in those phases. Its final phase calls for completing migration of remaining systems by 2035, taking risk and commercial product availability into account.
Those distinctions matter. The order’s 2030 and 2031 requirements apply to defined federal systems; they are not universal deadlines for every private enterprise. National Security Systems follow a separate path, including CNSA 2.0. Treating every date as a blanket mandate would weaken an otherwise strong case for action.
The Schedule Starts Before the Deadline
OMB lays out five phases. Discovery, governance, and planning run through 2026 and 2027. Pilots and early migrations follow in 2027 and 2028. Prioritized key-establishment migration runs from 2028 through 2030, followed by the digital-signature phase in 2031 and completion of remaining systems by 2035. NIST also has a pilot on a subset of its own systems due by the end of 2027.
That sequence leaves less room than the final date suggests. A team that discovers a hard-coded RSA dependency in 2029 may still have to change an application, update a certificate chain, negotiate an interface with another organization, test performance, and clear its release process before the 2030 milestone. Procurement, vendor roadmaps, and scarce test environments can consume more time than the code change itself.
A plan submitted this fall will not contain every answer. OMB explicitly expects it to mature. But it must show enough of the estate and its dependencies to support real decisions: what moves first, what needs a vendor, what can be retired, and which systems cannot support PQC or a hybrid approach at all.
Legacy Systems Turn Dates into Dependencies
The memo tells agencies to build PQC upgrades into planned cloud migrations, software development, and hardware refreshes. It also directs them to identify systems that cannot support PQC or hybrid cryptography and prioritize replacement or decommissioning. That is an application modernization decision, not merely a cryptography library upgrade.
Consider a claims or licensing system that uses an aging application server, a custom authentication service, and several partner interfaces. Updating TLS at the perimeter might protect one connection, but it does not address a signature generated inside the application, an embedded key exchange, or a downstream device that cannot process new algorithms. The system owner needs an end-to-end view of where cryptography sits and who controls each change.
That view is often missing. Source code, configuration, certificates, hardware security modules, identity services, APIs, and third-party products may all carry different dependencies. Documentation may describe the intended design rather than the system that actually runs. An inventory that stops at servers and software licenses will miss the work that determines whether a migration can finish on time.
The Private-Sector Signal Is Real, but Different
The executive order also tells federal sector risk management agencies to help critical infrastructure owners and operators develop PQC plans. It directs the Federal Acquisition Regulatory Council to propose a rule requiring covered contractors to comply with applicable NIST FIPS by the end of 2030. A proposed rule is a step toward procurement obligations, not a final contractor requirement today.
Private companies should therefore avoid two bad readings: assuming the federal dates already bind every commercial system, or dismissing the order because they do not. Agencies will ask suppliers about product support, cloud providers will have to divide migration responsibilities with customers, and new acquisitions can create obligations that outlast the current platform. The sensible response is to check contracts and product roadmaps while building the same basic visibility the federal program requires.
What Leaders Should Do This Quarter
Appoint one accountable owner to lead a portfolio-level inventory. Start with systems that protect long-lived sensitive information, support critical operations, or depend on digital signatures for trust. Record the algorithms, libraries, certificates, interfaces, vendors, and refresh dates that control the path to migration. Then separate systems that can move through configuration or supported upgrades from those that need code changes, architecture work, or replacement.
Ask each major vendor for a dated PQC support plan and evidence of interoperability, rather than accepting a generic readiness statement. Run an early pilot against a representative dependency chain, including identity, application logic, data exchange, and operations. Use what breaks to revise budgets and the work sequence. OMB’s phased structure is useful here even for organizations outside its direct scope.
The important change in 2026 is not that quantum computers suddenly crossed a known threshold. It is that federal leaders assigned responsibility and shortened the practical planning window for priority systems. Organizations that wait until 2030 to discover their cryptographic dependencies will find that 2030 was never the start date.
The next post in this series will examine where cryptography hides inside legacy applications and why a conventional asset inventory rarely shows the full exposure.
Book a Call with Aspen
If you need to understand how your legacy application portfolio fits these timelines, let’s talk. Aspen can help map the dependencies inside your systems, identify the applications that need more than a library update, and build a modernization sequence around the dates that now matter.
Schedule a discovery chat: https://calendly.com/aspen-ess/aspen-ess-discovery-chat
