The PQC Clock Is Now Official
A White House executive order and Microsoft's accelerated timeline give PQC migration real deadlines. Here's what changed.
Two things happened in the past ten days that shifted PQC migration from “we should probably start thinking about this” to “there are deadlines now, and they’re closer than you’d expect.”
On June 22, President Trump signed Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks.” On July 1, Microsoft announced it’s pulling its quantum-safe transition timeline forward to 2029. Neither event is surprising on its own. But together, they make the timeline concrete for anyone still treating PQC as a 2030s problem.
What the executive order actually requires
The EO sets two hard deadlines for federal agencies. By December 31, 2030, agencies must transition their most sensitive systems to post-quantum encryption. By December 31, 2031, they need post-quantum authentication in place too. Federal contractors have to comply with NIST’s post-quantum FIPS standards by the end of 2030.
The near-term requirements are more interesting than the deadlines, though. Agencies have 30 days to name a lead PQC transition official. By October 22, 2026, every agency needs to submit a PQC Migration Plan to OMB and ONCD. The Department of Commerce has to run a PQC migration pilot project, completed by the end of 2027.
If you sell software or services to the federal government, that October date matters. Four months from now, your customers will need to explain how they plan to reach post-quantum compliance. They’ll be asking you what your migration timeline looks like.
Why Microsoft moved the date up
Microsoft’s announcement came nine days after the EO, which is probably not a coincidence. Mark Russinovich, Azure’s CTO, said advances in quantum research have “shifted the risk horizon” and that cryptographically relevant quantum computers could arrive sooner than previously expected.
The company is accelerating its Quantum Safe Program to get critical products and services onto PQC by 2029. That’s ahead of both the federal deadline and the CNSA 2.0 timeline, which requires new acquisitions for National Security Systems to be PQC-compliant by January 2027.
Microsoft identified three focus areas: upgrading network cryptography to TLS 1.3, building crypto-agility for stored data so they can swap algorithms without redesigning underlying systems, and transitioning trust chains like code signing and certificate issuance to PQC algorithms.
The crypto-agility piece is worth paying attention to. Microsoft is essentially saying they expect to change algorithms more than once. If you’re designing your migration as a one-time swap from classical to post-quantum, you’re building something rigid when the world is asking for flexibility.
The gap nobody’s closing
A 2026 measurement study of 32,011 domains found that 49.3% now support hybrid post-quantum key exchange. That sounds like progress until you see the next number: 0% have adopted hybrid post-quantum certificates.
Zero. Not low. Zero.
Key exchange protects data in transit. Certificates prove you’re talking to who you think you’re talking to. Half the internet has started protecting the pipe, but nobody has started authenticating the endpoints with quantum-safe algorithms. That gap between encryption and authentication is exactly where attackers look.
The IETF’s PLANTS working group is making progress on post-quantum certificate standards for TLS, but standards and deployment are different conversations. Even once the specs are done, the certificate ecosystem (CAs, browsers, server software, monitoring tools) all need to catch up.
What this means if you’re planning a migration
The policy picture is getting clearer fast. Between the White House EO, CNSA 2.0 timelines, and the EU’s NIS2 amendment (which explicitly calls out harvest-now-decrypt-later attacks as “likely occurring already now”), the regulatory pressure is real and coming from several places at once.
If you haven’t started your cryptographic inventory, you’re behind. Not theoretically behind, but behind in a way where your federal customers will be asking questions in October that you’ll want to have answers for.
The organizations I’ve seen handle this well tend to start by inventorying cryptographic dependencies, then prioritize anything with long confidentiality requirements. They build for crypto-agility rather than a one-time algorithm swap, and they focus on key exchange first (where tooling is more mature) while keeping an eye on the certificate standards.
The 2030 deadlines feel far away. The October 2026 planning deadlines don’t.