On July 1, 2026, Microsoft Azure CTO Mark Russinovich announced that Microsoft was accelerating its quantum-safe migration deadline to 2029. As of July 6, that leaves roughly three years to complete work across network encryption, stored data, and the systems that establish trust in software.
Russinovich said cryptographically relevant quantum computers could arrive sooner than previously expected, while the preparation required remains significant. Microsoft is putting post-quantum cryptography, or PQC, requirements into its Secure Future Initiative, the engineering program introduced as part of its post-breach security overhaul.
The date gives infrastructure teams a planning target. The harder problem is that some data encrypted today will still need to remain confidential after a capable quantum computer becomes available.
Encrypted traffic can be collected before it can be decrypted
“Harvest now, decrypt later” describes an attacker collecting encrypted data and retaining it until the technology needed to decrypt it becomes available. Nation-state adversaries are reported to be collecting encrypted traffic at scale for this purpose. Sophisticated criminal organizations may be doing the same.
Consider a hypothetical quantum computer capable of breaking widely used public-key cryptography in 2031. An attacker collecting encrypted API traffic from 2026 onward could have five years of material waiting for decryption. Medical records, financial transactions, intellectual property, authentication tokens, and long-lived secrets can remain sensitive well beyond the lifetime of the cryptography protecting them.
That makes data retention relevant to migration priorities. A connection that only needs short-lived confidentiality presents a different risk from one carrying records that must remain private for decades. TLS traffic and encrypted backups both belong in the assessment, along with the algorithms and key-protection mechanisms they depend on.
Collection doesn't require the attacker to break the encryption today. For information with a long confidentiality requirement, waiting for a working quantum attack could leave already-captured data exposed.
Microsoft's migration covers three areas
Network encryption and TLS 1.3
Microsoft is upgrading its network infrastructure to TLS 1.3 as the baseline for hybrid and post-quantum key exchange. The protocol provides the handshake architecture needed to integrate post-quantum key encapsulation, the process used to establish a shared secret between two parties.
For infrastructure teams still operating TLS 1.2 endpoints in 2026, moving to TLS 1.3 should be an early part of the plan. That work includes load balancers, reverse proxies, API gateways, and service meshes, rather than just public-facing web servers. It also establishes a clearer starting point for testing post-quantum support across clients and servers.
Stored data and crypto-agility
Crypto-agility is the ability to change cryptographic algorithms without redesigning a system. For encrypted storage, a practical design records which algorithm and format produced each encrypted object. The read path can then continue handling older data while the write path starts using a newer algorithm.
Existing systems often make that difficult. Configuration files may depend on a hardcoded KMS key and algorithm. Backups may rely on RSA-2048 through a library version from 2019. Authentication middleware may hardwire ECDSA P-256 for JWT signatures, while session-token code assumes its cipher suite will never change.
These dependencies need an abstraction layer that makes algorithm rotation manageable. Otherwise, each change becomes a separate application rewrite, with its own compatibility and deployment problems.
Hybrid cryptography pairs an existing classical algorithm with a post-quantum algorithm. Examples include retaining X25519 for key exchange or ECDSA for signatures while adding a PQC component. Properly constructed, the combination is intended to preserve protection as long as either component remains secure. This allows migration without immediately abandoning established algorithms.
Guidance from NIST, France's ANSSI, and the UK's National Cyber Security Centre is part of the migration planning landscape. Hybrid deployment also requires backward compatibility: older stored data still needs to be readable while new writes and connections move to the newer schemes.
Code signing, certificates, and software updates
Code signing allows a system to check that software came from the claimed publisher and hasn't been altered. Its security depends on signing keys, certificate authorities, validation software, and the update pipeline that delivers the signed code.
A sufficiently capable quantum computer could undermine the RSA and elliptic-curve algorithms used in those trust chains. The consequence would extend beyond confidential data. An attacker able to compromise signing keys could forge signatures under a trusted identity, affecting software updates, certificates, and other signed artifacts.
Microsoft is explicitly targeting these areas for PQC migration, including key-protection infrastructure. Google and Cloudflare have made parallel 2029 commitments. According to reporting on the Trump administration's June 2026 executive order, federal agencies face a 2030 deadline for moving high-value systems. The UK's NCSC and France's ANSSI are pursuing similar timelines, with France tying security product certification to quantum-safe requirements starting in 2027.
The initial NIST standards are available
NIST finalized three Federal Information Processing Standards on August 13, 2024. Teams no longer need to wait for that initial set of standards before beginning an inventory or planning implementation work.
- FIPS 203, ML-KEM: A key encapsulation mechanism for establishing shared secrets in TLS and other protocols, taking over functions served by RSA and ECDH. ML-KEM-768 is the recommended starting point for most enterprise use cases in this migration approach.
- FIPS 204, ML-DSA: A digital signature algorithm for uses such as certificates, tokens, and authentication artifacts currently signed with ECDSA or RSA. ML-DSA-65 is the proposed enterprise baseline.
- FIPS 205, SLH-DSA: A stateless hash-based signature scheme with a different mathematical foundation from ML-DSA. It offers algorithm diversity for high-assurance applications.
ML-KEM comes from the CRYSTALS-Kyber submission, while ML-DSA comes from CRYSTALS-Dilithium. Both are lattice-based. Their security rests on the presumed difficulty of lattice problems, rather than the integer factorization and discrete logarithm problems underlying RSA and elliptic-curve cryptography. Shor's algorithm would allow a sufficiently capable quantum computer to solve those latter problems efficiently.
NIST's transition plan, NIST IR 8547, places RSA-2048 and ECC P-256 deprecation at 2030 and removal of quantum-vulnerable algorithms from NIST standards at 2035. NSA's CNSA 2.0 sets a 2027 PQC requirement for new national security systems. Organizations serving government customers need to account for those requirements alongside their cloud providers' migration plans.
Start by locating the cryptography
Choosing an algorithm is only part of the work. Before a team can replace cryptography, it needs to find the applications, libraries, devices, and external services that use it.
A cryptographic inventory should cover:
- TLS termination points: Load balancers, API gateways, reverse proxies, and service meshes where certificates are presented and key exchange happens.
- Encrypted storage: Database encryption at rest, backups, object-storage server-side encryption, and secrets-management systems such as Vault, AWS KMS, and Azure Key Vault.
- Signing infrastructure: Code-signing certificates, CI/CD pipeline keys, container-image signing, and artifact registries.
- Authentication artifacts: JWTs, SAML assertions, and OAuth tokens, particularly those signed asymmetrically with a long time to live.
- Inter-service communication: mTLS, SSH, and other protocols that use asymmetric cryptography for identity or key establishment.
Libraries, frameworks, and SDKs can hide these dependencies from architecture diagrams. NIST's NCCoE migration guidance provides a basis for reviewing those diagrams and investigating the implementation beneath them.
The practical sequence is to inventory dependencies, build crypto-agility into the relevant interfaces, deploy hybrid classical-plus-PQC protection for new connections, and then rotate or retire older cryptography. Stored-data migrations also need read paths that remain compatible with older formats during the transition.
There is a useful comparison with IPv6 dual-stack migration: old and new mechanisms coexist while dependencies move. The difference is the consequence of delay. With quantum-vulnerable encryption, the risk can include future exposure of data already collected, rather than just incompatibility with newer systems.
Use 2029 to plan the work, not postpone it
If Microsoft, Google, and Cloudflare complete their stated migrations by 2029, applications that still depend on older cryptography will need particular attention. A provider's migration doesn't remove an application's hardcoded algorithms, old signing libraries, or incompatible clients.
The recommendation is to start the cryptographic inventory this quarter. The results should show which data needs long-term confidentiality, where algorithm changes require code changes, and which migrations depend on vendors. Teams can then introduce compatibility support and test hybrid deployments incrementally. Leaving that discovery until a deadline approaches makes an emergency rewrite more likely.
