Your Microsoft 365 tenant encrypts terabytes of data every day — emails in Exchange Online, files in SharePoint, device telemetry from Intune, authentication tokens through Entra ID. Every byte of that traffic is protected by cryptography that was designed before quantum computers were considered a realistic threat. That assumption no longer holds.
In August 2024, NIST published its first finalized post-quantum cryptography standards, giving the industry a concrete migration target for the first time. In May 2025, Google's Quantum AI team published a landmark paper showing that RSA-2048 — the backbone of most enterprise encryption — could theoretically be broken in under a week using roughly one million noisy qubits. That is a 20-fold reduction from their 2019 estimate. The timeline just got shorter. If you manage Microsoft 365 endpoints for a living, this is your briefing.
What Is Post-Quantum Cryptography and Why Should Intune Admins Care?
Post-quantum cryptography (PQC) refers to a new generation of cryptographic algorithms designed to resist attacks from both classical and quantum computers. The algorithms your endpoints use today — RSA, ECDH, ECDSA — rely on mathematical problems (factoring large integers, discrete logarithm) that are hard for classical CPUs but trivially solvable by a sufficiently powerful quantum computer running Shor's algorithm.
For a Modern Workplace Engineer, this matters for one concrete reason: the management channel, the data plane, and your stored encrypted data are all in scope. Your Intune MDM communication relies on HTTPS with RSA/ECDH key exchange. Exchange Online delivers encrypted mail protected by RSA keys. BitLocker recovery keys are escrowed over RSA-secured channels. S/MIME certificates issued from your internal CA are RSA-2048 by default.
None of this breaks tomorrow. But the threat is not waiting for tomorrow either.
The Harvest Now, Decrypt Later (HNDL) Threat — Active Today
The most underappreciated risk is not the eventual quantum computer — it is what is happening on your network right now. Nation-state actors and sophisticated threat groups are already capturing encrypted traffic in bulk with one goal: store it until a cryptographically relevant quantum computer (CRQC) is available, then decrypt everything retroactively.
This is the Harvest Now, Decrypt Later (HNDL) attack model, and it fundamentally changes your threat horizon. It does not matter that a CRQC does not exist yet. If your organization handles any of the following, you are already inside the threat window:
- Healthcare: Patient records with decades-long confidentiality requirements
- Legal & Finance: M&A communications, contracts, transaction records
- Defense supply chain: Technical specifications, compliance data, credentials
- HR & Identity: Entra ID tokens, certificates, conditional access policy data
- Long-term IP: R&D data, proprietary configurations, trade secrets
If that data needs to remain confidential past 2030, the window for action is now — not when Microsoft or NIST forces your hand.
The Standards Are Here: NIST FIPS 203, 204, 205
On August 13, 2024, NIST published the first three finalized post-quantum cryptography standards, ending years of "the standards are not ready" as an excuse for inaction:
- FIPS 203 — ML-KEM (Module-Lattice Key Encapsulation Mechanism): The primary quantum-resistant algorithm for key exchange, replacing RSA and ECDH in TLS handshakes and key establishment. Based on CRYSTALS-Kyber.
- FIPS 204 — ML-DSA (Module-Lattice Digital Signature Algorithm): Quantum-resistant digital signatures for authentication and integrity verification, replacing ECDSA and RSA-PSS. Based on CRYSTALS-Dilithium.
- FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm): A hash-based alternative for digital signatures with different security assumptions, serving as a cryptographic diversity option. Based on SPHINCS+.
NIST's guidance establishes a clear organizational deadline: vulnerable public-key systems should be deprecated after 2030 and fully disallowed after 2035. These are not aspirational targets — they are driving vendor roadmaps, including Microsoft's.
Where Microsoft Stands: The Quantum Safe Program Roadmap
Microsoft has published its Quantum Safe Program (QSP) strategy, and the timeline is more advanced than most tenants realize. Here is where things stand as of mid-2025, and what is coming:
Already Shipped
- ML-KEM and ML-DSA are generally available in Windows Server 2025 and Windows 11 (24H2, 25H2) via Cryptography API: Next Generation (CNG). Your endpoints running these builds already have PQC algorithm support at the OS layer.
- X25519MLKEM768 hybrid TLS key exchange is the default in Microsoft Edge 131 and newer. This is not a preview or opt-in flag — it is active on every managed browser running Edge 131+. The TLS handshake from your endpoints to Microsoft services already combines classical X25519 with ML-KEM-768 where the server supports it. This was enabled by default in November 2024.
- SymCrypt (Microsoft's core cryptographic library underpinning Windows, Azure, and M365) has been updated with verified PQC algorithm support.
2026 — Core Infrastructure Migration
- Signing services and key management services transition to quantum-safe standards
- Network services and Microsoft Entra authentication infrastructure migrating to PQC
- Active Directory Certificate Services (ADCS) PQC capability targeted for general availability
- Azure Key Vault and Azure Managed HSM on track for PQC support
2027 — Full Platform Integration
- PQC integration into Windows, Azure services, Microsoft 365, data platforms, and AI services
- Intune backend and MDM channel expected to be PQC-capable as part of the Azure services phase
2029 / 2033 — Early Adoption and Full Completion
- Microsoft targets enabling early PQC adoption across all products by 2029
- Full company-wide transition to post-quantum cryptography targeted for 2033 — two years ahead of most government deadlines
Key takeaway for admins: Microsoft is not waiting. The foundational PQC work is already running on your Windows 11 endpoints and in Edge today. What is not yet migrated is the data plane — your mail encryption, your VPN tunnels, your S/MIME certificates, your application TLS configurations. That part is your responsibility.
Real-World Impact on Your Managed Environment
Use Case 1 — The Intune-Managed Windows Fleet
Your endpoints running Windows 11 23H2 and earlier are negotiating TLS sessions using cipher suites that include RSA key exchange. These sessions have no forward secrecy — if the server's RSA private key is ever compromised (including retroactively by a quantum computer), every recorded session from every device can be decrypted. Run this audit across your fleet before your next security review:
# Check all enabled TLS cipher suites on a managed endpoint
Get-TlsCipherSuite | Select-Object Name, Exchange, Cipher, Hash | Format-Table -AutoSize
# Flag RSA key exchange suites — zero forward secrecy, prime HNDL targets
Get-TlsCipherSuite | Where-Object { $_.Exchange -eq 'RSA' } | Select-Object Name
If you see TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, or any suite with Exchange: RSA in the output, those sessions are in your HNDL exposure window. Disable them now via Intune or Group Policy.
Use Case 2 — Cipher Suite Hardening via Intune (Graph API / OMA-URI)
Push a hardened cipher suite order to your entire managed fleet using this Intune Custom Configuration profile. This payload prioritizes TLS 1.3 suites — which mandate ephemeral key exchange and provide forward secrecy by design — and surfaces ECDHE-based TLS 1.2 suites above any RSA key exchange fallbacks:
{
"@odata.type": "#microsoft.graph.windows10CustomConfiguration",
"displayName": "PQC-Ready Cipher Suite Hardening",
"omaSettings": [
{
"@odata.type": "#microsoft.graph.omaSettingString",
"displayName": "SSL Cipher Suite Order",
"omaUri": "./Device/Vendor/MSFT/Policy/Config/Cryptography/TLSCipherSuites",
"value": "TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
}
]
}
Deployment recommendation: Target a pilot device group first. Some legacy line-of-business applications and older web servers fail when RSA key exchange is removed from the client's supported cipher list. Validate in pilot before rolling to production rings.
Use Case 3 — S/MIME and Purview Message Encryption (OME)
This is your highest-exposure surface from an HNDL perspective. Every email signed or encrypted with RSA-2048 S/MIME certificates today is a future liability if stored by an adversary. Microsoft Purview Message Encryption (OME) configurations also inherit key length from your underlying cryptographic infrastructure.
Immediate steps:
- Audit your internal CA: if you are issuing S/MIME certs at RSA-2048, migrate to RSA-4096 or ECDSA P-384 as a transitional step. Neither is quantum-safe, but RSA-4096 meaningfully increases the qubit count required for an attack.
- Review key rotation schedules in Purview. Stale long-lived keys stored alongside archived mail maximize your HNDL exposure window.
- Begin tracking NIST PQC certificate standards maturation — hybrid X.509 certificate formats that embed both classical and post-quantum keys are under active development and will define the next migration phase.
Use Case 4 — BitLocker Keys in Intune
BitLocker recovery keys escrowed to Intune are protected in transit and at rest by Microsoft's infrastructure encryption — currently RSA-based at the service layer. This is on Microsoft's migration roadmap for the 2026-2027 phase. Your action item is operational, not architectural: validate that your BitLocker key rotation policy is active. Long-lived, stale recovery keys stored indefinitely in Intune extend your exposure duration beyond what is necessary.
Use Case 5 — Edge Browser TLS on Managed Endpoints
If your fleet is on Edge 131 or newer (which it should be under any active Intune patching policy), the hybrid X25519+ML-KEM-768 key exchange is already active by default for connections to servers that support it. You do not need to enable this — it is on.
What you do need to monitor is enterprise firewall and proxy compatibility. The larger TLS ClientHello packet produced by hybrid key exchange has broken TLS inspection on older FortiGate, Palo Alto, and Cisco appliances. Check that your network inspection infrastructure is running firmware that handles ML-KEM key shares without errors before assuming your PQC-enabled browser traffic is flowing cleanly.
# Verify TLS 1.3 negotiation and hybrid key exchange via Edge # Navigate to: edge://net-internals/#security # Look for: key exchange = X25519MLKEM768 on a TLS 1.3 connection # Registry check for TLS minimum version on managed endpoints Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -ErrorAction SilentlyContinue Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -ErrorAction SilentlyContinue # Enabled should be 0 (disabled) on both — confirm TLS 1.0 and 1.1 are off
Your PQC Action Plan for This Quarter
You do not need to solve the entire quantum migration this sprint. You need to stop accumulating unnecessary risk. Here is a prioritized, practical checklist for Modern Workplace Engineers:
🔴 Do This Now (No Dependencies, High Impact)
- Run the cipher suite audit PowerShell snippet across a sample of your managed endpoints. Document RSA key exchange suites that are still enabled.
- Deploy the OMA-URI cipher suite hardening payload to a pilot Intune device group.
- Verify TLS 1.0 and 1.1 are fully disabled across your managed fleet (registry audit above).
- Check that Edge is on version 131+ across your fleet — confirm via Intune device reports or the Edge Update policy status report.
🟡 Do This This Quarter (Planning Required)
- Audit your internal CA: document all issued S/MIME and device certificates with RSA-2048 key lengths. Build a migration schedule.
- Review your Purview encryption configuration and key rotation schedule. Identify any OME templates tied to legacy RSA key infrastructure.
- Validate your network inspection infrastructure (firewall, proxy, SSL inspection) handles hybrid PQC TLS without errors on Edge 131+ clients.
- Work with your CISO or DPO to classify data by sensitivity horizon. Identify data that must remain confidential past 2030.
🟢 Do This This Year (Strategic)
- Subscribe to the Microsoft 365 Message Center and filter for cryptographic algorithm deprecation notices.
- Bookmark and periodically review the Microsoft Quantum Safe Program strategy page — it is being updated as milestones are hit.
- Begin scoping what a crypto-agile Intune configuration baseline looks like for your environment — the ability to swap cipher configurations fleet-wide within a single change window is a capability worth building now.
- Plan for ADCS modernization. PQC certificate issuance through ADCS is targeted for early 2026 — your PKI infrastructure needs to be positioned to consume it.
The Bottom Line for Modern Workplace Engineers
The quantum threat is not a future problem being handed to a future version of your team. The Harvest Now, Decrypt Later model means the attack surface is accumulating in your mail flow logs, your SharePoint audit trails, and your Intune device telemetry right now. Every RSA-encrypted session your managed endpoints negotiate today is a transaction that a capable adversary can archive and revisit.
Microsoft is moving. The OS-layer PQC algorithms are already on your Windows 11 endpoints. The hybrid TLS key exchange is already running in Edge. The platform migration through 2026-2027 is confirmed. What is not automatic is the configuration work on your data plane — the cipher suite ordering, the S/MIME certificate infrastructure, the Purview encryption policies, the PKI readiness. That work belongs to the Modern Workplace team, and the window to do it before it becomes urgent is open right now.
Quantum readiness is not a CISO checkbox. It is endpoint hygiene for the next decade.
