Post-Quantum Security: Why Microsoft and Google’s 2029 Goals Don’t Cover Your Entire IT Estate

For Windows and Microsoft 365 shops, the piece is worth reading alongside what Microsoft, Google and the UK's National Cyber Security Centre (NCSC) have actually published. The picture is more useful, and more specific, than "the cloud vendor will sort it".

The core argument: deadlines mark the edge of responsibility​

Owen's claim is that the 2029 dates from Microsoft and Google Cloud can give customers a false sense of containment. A platform may adopt quantum-resistant protection while an older application can't use it. A backup may encrypt its contents well while the method protecting its key stays vulnerable. In his words, one supplier can finish its preparations and still leave the customer exposed through a system beyond its control.

Google Cloud draws that line explicitly in its 11 August 2026 roadmap:

• Google's side: Google manages the transition of its infrastructure, including its network, encryption in transit, global front ends and the ALTS protocol. The original packet describes this as "security of the cloud".
• The customer's side: customers must manage their own applications, including updating client software so it can negotiate post-quantum handshakes. They must also manage the lifecycle of their asymmetric keys and update their service configurations with quantum-safe settings and policies.
• Hardware caveat: Google says some physical components may extend beyond 2029 because hardware moves through a mix of active replacement and natural refresh cycles.

Owen says the same division applies to Microsoft and other major platforms. That is a reasonable inference, but it is his inference. Google's description is Google's own, and other providers may draw the boundaries differently. Check each contract.

Where the dates come from​

Mixing up these dates is easy, so here they are separately.

The NCSC's three milestones are worth spelling out. By 2028, organisations should define migration goals, discover what depends on cryptography and draft a plan. By 2031 they should complete early migration of the highest-priority systems. By 2035 they should finish migration across systems, services and products. The NCSC's 2026 Annual Review repeats these dates and tells leaders to engage suppliers and technology partners to understand their preparedness.

These are planning horizons, not forecasts of when a quantum computer will break today's public-key encryption. Owen makes the same point.

A note on Microsoft's dates. In a 30 June 2026 Security Blog post, Mark Russinovich, CTO of Microsoft Azure, said Microsoft was bringing its quantum-safe timeline forward. The goal is to move products and services to PQC by 2029. The post says Microsoft is also folding PQC requirements into its Secure Future Initiative. This is a stated goal for Microsoft's products. It is not a promise about your endpoints, applications or certificates.

What Windows already ships​

Owen says Microsoft has "begun adding support" to Windows and Windows Server. Other reporting gives more detail:

• November 2025: Post-quantum algorithms became generally available in Windows Server 2025, Windows 11 clients (24H2, 25H2) and .NET 10. They arrived through updates to the Cryptography API: Next Generation (CNG) libraries and certificate functions. The algorithms are exposed only through CNG providers, not the older legacy CryptoAPI. That last point matters if you have older line-of-business software.
• May 2026: Microsoft's Windows Server documentation says AD CS currently supports ML-DSA. The requirements are Windows Server 2025 with the 2026-05 Security update (KB5087539) or later on the CA servers. Clients need Windows 11 24H2 or 25H2 with the 2025-10 non-security update (KB5067036) or later. The same page lists ML-KEM support in AD CS as planned for a later phase.
• July 2026: A Microsoft Tech Community post says hybrid TLS using ML-KEM key exchange groups is now generally available in Windows 11 and Windows Server 2025. A third-party summary dates this to the 14 July 2026 security updates, with the hybrid exchange in the Schannel stack.

The consequence for administrators is plain. Windows Server 2025 and recent Windows 11 builds have the pieces. A fleet on older Windows versions, or a PKI built on older CAs, does not get them automatically. Whether and how hybrid key exchange is switched on for your servers and clients is a configuration question. Verify it against Microsoft's current documentation rather than assuming a default.

Why "harvest now, decrypt later" drives the priorities​

Owen's most useful move is reframing the problem. Instead of guessing when a quantum computer arrives, ask which stolen information would still hurt if it were read years later. Intellectual property, legal material and personal data qualify. Routine operational data mostly doesn't.

Microsoft's own post says the same. Organisations are prioritising data with long confidentiality lifetimes, because encrypted data captured today could be exposed later. Microsoft also says its customers keep finding that the hardest part is not choosing algorithms. It is working out where cryptography exists across apps, services, networks, identities, certificates and hardware.

One caution. Owen says quantum computers will break the strongest current public-key encryption "in a few days or even hours". The sources I could verify support the threat and the migration rationale. They do not support that precise figure, so treat it as the author's assertion.

Where mid-sized estates get caught​

Owen names the mid-market problem as the connections between providers. Cloud services must work with older software, internal certificate systems, network equipment and backup products, all moving at different speeds. The NCSC's guidance backs this up:

• Commodity platforms: if you rely entirely on them, PQC upgrades will probably arrive from your provider and through routine refresh of laptops, phones, servers and routers.
• Everything else needs a plan: bespoke IT, operational technology, and private PKI are examples.
• Enterprise PKI: migrating it means creating a new PQC root of trust and issuing new certificates to every entity on the network. Some devices may need physical handling.
• Coexistence: most estates will run traditional and post-quantum cryptography side by side for a while. The NCSC advises seeking solutions with cryptographic agility.
• Don't roll your own: the NCSC says most organisations should not write their own PQC implementations. Certified implementations and trusted libraries will exist.
• Slower areas: the NCSC expects confidentiality protection to arrive first, with certificate-based PKI and IoT and industrial protocols following more slowly. It also flags WebPKI and industrial control system protocols as particularly hard.

The NCSC also stresses that its guidance is aimed mainly at large organisations, critical infrastructure and companies with bespoke IT. Mid-sized firms should apply it proportionately. Owen himself says most organisations don't need a standalone quantum security programme.

A practical checklist​

This synthesises Owen's advice with the NCSC, Microsoft and Google guidance above.

1. Name an owner. Microsoft advises defining ownership, scope and milestones for a multi-year transition. Involve security, IT operations and procurement.
2. Inventory cryptography. The NCSC says this needn't be a formal asset register. Understand each system's nature, scale, versions and patch levels, and dependencies between components. Include certificates, keys, backup products, network gear and supplier-run services.
3. Rank by confidentiality lifetime. Start with the data that would still matter in ten years.
4. Check Windows baselines. Confirm which servers and clients run Windows Server 2025 or Windows 11 24H2/25H2 with the relevant updates. Treat everything else as a gap to plan for.
5. Modernise protocols. Microsoft recommends TLS 1.3 as a baseline across clients and servers, and reducing legacy protocol use.
6. Build crypto-agility into new systems. Microsoft describes this as making cryptographic settings configurable outside the application and removing hard-coded algorithms.
7. Put it in procurement. Hardware bought now may still be running in 2031. A long software contract can lock in an app that can't adopt stronger encryption without a rebuild.
8. Ask sharper supplier questions. Skip "is it quantum-ready?" Ask:
   • Which products will change?
   • Does the change need new hardware or extra cost?
   • What must we configure ourselves?
   • Who owns anything that can't be updated?
9. Scrutinise managed providers. Owen warns that a managed security provider cannot simply assume it inherits Microsoft's readiness and passes it on wholesale. Its value is in interpreting platform changes across your wider estate.
10. Signal demand. The NCSC suggests publishing a statement of intent, so suppliers see customers asking for PQC products.

The bottom line​

Owen's piece is an opinion from a Microsoft security specialist, and it ends by pitching the role of such specialists, so read it with that in mind. The core point survives checking against primary sources. Microsoft's 2029 goal, Google's 2029 target and the NCSC's 2028/2031/2035 milestones are different things. Vendors cover their platforms, and the NCSC's dates cover your estate.

The practical deadline Owen offers is the next purchase or renewal that could lock vulnerable technology in for five or ten years. For most mid-sized IT teams, that is a better starting point than a quantum calendar.