On July 1st, 2026, Mark Russinovich, CTO of Microsoft Azure, published something that should land on every infrastructure team's radar: Microsoft is accelerating its quantum-safe migration deadline to 2029. That is not 2035. That is not some regulatory footnote for government contractors. That is three years from now, and it comes from the person responsible for securing one of the world's largest cloud platforms.
Russinovich's reasoning was direct: "Cryptographically relevant quantum computers could arrive sooner than previously expected — the work required to prepare is significant." Microsoft is embedding post-quantum cryptography (PQC) requirements into its Secure Future Initiative, the same disciplined engineering framework the company has been using since its post-breach security overhaul. When a company that runs Azure sets a hard internal engineering deadline, I pay attention.
But the deadline is the least important part of this story. The real threat is already in play.
Harvest Now, Decrypt Later — This Is Happening Today
The "harvest now, decrypt later" (HNDL) attack model is not theoretical. Nation-state adversaries — and likely several sophisticated criminal organizations — are already collecting encrypted traffic at scale with the explicit intent of decrypting it once quantum computing reaches sufficient capability. Every TLS session your systems terminate today, every encrypted backup you write tonight, every digitally signed certificate you issue this week — all of it is a candidate for future decryption.
The timelines matter enormously here. If a cryptographically relevant quantum computer arrives in 2031, an attacker who started harvesting your encrypted API traffic in 2026 will have five years of data to work through. Medical records, financial transactions, intellectual property, authentication tokens, long-lived secrets — the shelf life of sensitive data often far exceeds the shelf life of the cryptography protecting it.
HNDL changes the threat model in a way that most teams have not internalized: your current encryption is already being attacked, just not yet decrypted. The attack is deferred, not absent.
What Microsoft Is Actually Doing
Microsoft's announcement is not a press release about future intentions. It is a concrete engineering commitment across three specific domains:
Network Cryptography: TLS 1.3 First
Microsoft is upgrading its network infrastructure to TLS 1.3 as the baseline, which is a prerequisite for hybrid and post-quantum key exchange. TLS 1.3 eliminated the negotiation weaknesses that made TLS 1.2 vulnerable to downgrade attacks, and it provides the cleaner handshake architecture needed to bolt on post-quantum key encapsulation. If you're still running TLS 1.2 endpoints in 2026, this is your first problem to fix — not because quantum computers are coming, but because the classical security of TLS 1.2 is increasingly marginal on its own terms.
Stored Data: Crypto-Agility
This is the piece most organizations are completely unprepared for. Crypto-agility means your systems can swap cryptographic algorithms without requiring a system redesign — practically speaking, it means every encrypted blob carries self-describing metadata about which algorithm produced it, and your read path can handle the old format while your write path uses the newest algorithm.
Think about how many places in your infrastructure this is not true today. Config files encrypted with a hardcoded KMS key and algorithm. Backups sealed with RSA-2048 via a library version from 2019. JWTs signed with ECDSA P-256 hardwired into your auth middleware. Session tokens written by code that assumes the cipher suite is a constant. Crypto-agility requires going through all of that and building in the abstraction layer that makes algorithm rotation a configuration change, not an emergency rewrite.
The standard recommendation from NIST and the migration guides coming out of ANSSI and the UK's NCSC is hybrid cryptography: pair your current classical algorithm (X25519 for key exchange, ECDSA for signatures) with a new PQC algorithm in parallel. That way the session is protected as long as either algorithm holds, which buys time without abandoning your existing security posture.
Trust Chains: Code Signing, Certificates, and Update Pipelines
This is the one that keeps me up at night. Code signing is the chain of trust that tells your systems — and your users' systems — that software came from where it claims to come from. If an attacker harvests your code-signing certificates today and decrypts them post-quantum, they can forge signatures with your identity retroactively. The same problem applies to certificate authorities, software update pipelines, and key protection infrastructure. The trust chain that holds together the entire software supply chain is built on algorithms that quantum computers will break.
Microsoft is explicitly targeting PQC migration for all of these. Google and Cloudflare have made parallel 2029 commitments. The Trump administration's executive order in June 2026 set a 2030 deadline for federal agencies to move high-value systems. The UK NCSC and France's ANSSI are pushing similar timelines, with France tying security product certification to quantum-safe requirements starting in 2027.
The NIST Standards Are Finalized — Your Algorithm Choices Are Made
If your team has been waiting for the standards to stabilize before moving, that excuse expired on August 13, 2024. NIST finalized three Federal Information Processing Standards that define the PQC algorithm landscape:
- FIPS 203 — ML-KEM: The primary Key Encapsulation Mechanism, replacing RSA and ECDH for establishing shared secrets in TLS and other protocols. ML-KEM-768 is the recommended parameter set for most enterprise use cases.
- FIPS 204 — ML-DSA: The primary digital signature algorithm, replacing ECDSA and RSA for signing certificates, tokens, and authentication artifacts. ML-DSA-65 is the enterprise baseline.
- FIPS 205 — SLH-DSA: A stateless hash-based signature scheme providing a different mathematical foundation than ML-DSA, useful for high-assurance scenarios where algorithm diversity matters.
ML-KEM is derived from the CRYSTALS-Kyber submission. ML-DSA comes from CRYSTALS-Dilithium. Both are lattice-based, which means their security rests on the presumed hardness of lattice problems rather than the integer factorization and discrete logarithm problems that RSA and ECC rely on — and that quantum computers can solve efficiently using Shor's algorithm.
NIST's transition plan (NIST IR 8547) deprecates RSA-2048 and ECC P-256 by 2030 and removes all quantum-vulnerable algorithms from NIST standards by 2035. NSA's CNSA 2.0 goes further, mandating PQC for new national security systems by 2027. Your government clients are already on the clock.
Where Your Migration Actually Starts
I've been through enough large-scale infrastructure migrations to know that the hard part is never choosing the new technology — it's finding everywhere the old technology lives. Before you can migrate your cryptography, you need a cryptographic inventory.
That means systematically mapping:
- TLS termination points: Load balancers, API gateways, reverse proxies, service meshes — every place where certificates are presented and key exchange happens.
- Encrypted storage: Database encryption at rest, backup encryption, object storage server-side encryption, secrets management (Vault, AWS KMS, Azure Key Vault).
- Signing infrastructure: Code signing certificates, CI/CD pipeline keys, container image signing, artifact registries.
- Authentication tokens: JWTs, SAML assertions, OAuth tokens — anything signed asymmetrically with a long TTL.
- Inter-service communication: mTLS, SSH, any protocol using asymmetric cryptography for identity or key establishment.
Most organizations underestimate the scope by a factor of five or ten. Cryptography is embedded in libraries, frameworks, and SDKs in ways that make it invisible until you specifically go looking. Run NIST's NCCoE migration guidance through your architecture diagrams and you will find cryptographic dependencies you forgot you had.
The migration itself follows a pattern: inventory first, then build crypto-agility into your abstraction layers, then deploy hybrid classical-plus-PQC for new connections while maintaining backward compatibility on your read paths, then rotate. Think of it like an IPv6 dual-stack migration — you run both protocols simultaneously until the old one is drained. I ran IPv6 migrations for years before it actually mattered at scale; post-quantum migration will follow the same slow-then-sudden adoption curve, except the deadline is harder because the downside is retroactive exposure, not just future incompatibility.
The Clock Is Already Running
I've been running hosting infrastructure since the late 1990s. I watched HTTPS adoption take a decade longer than it should have because "we'll deal with it when it's a real problem" became a default posture. We are in that same early phase of post-quantum migration right now, with one critical difference: the threat is already active. Harvest-now-decrypt-later attacks don't announce themselves. The collection is silent; only the decryption, years from now, reveals the exposure.
Microsoft's 2029 commitment is not the finish line. It is a forcing function — the moment when the largest software platform in the enterprise world tells its customers that quantum-safe cryptography is the baseline expectation, not a premium feature. When Azure, Google Cloud, and Cloudflare have all migrated by 2029, the systems that haven't migrated will stand out as the weak link in every chain they touch.
Start your cryptographic inventory this quarter. Not next year, not when the project gets funded, not when a vendor makes it easier. The work is significant — Russinovich said exactly that — and the systems that start now will be in position to migrate incrementally. The systems that wait will face an emergency rewrite under pressure.
Three years is not as much runway as it sounds like when you're talking about enterprise cryptography infrastructure.