Post-quantum cryptography refers to encryption algorithms designed to resist attacks from quantum computers, which can break the RSA and elliptic-curve algorithms that underpin virtually all current enterprise software. Whether Microsoft 365 qualifies as quantum safe is a direct compliance and risk question for IT managers, CISOs and Data Protection Officers who are responsible for data that must remain confidential for years or decades.
Does Microsoft 365 Use Post-Quantum Encryption?
Microsoft 365 is in the early stages of post-quantum migration, but it is not yet quantum safe across its full product surface.
Microsoft has made public progress on the cryptographic library level. In 2024, the company announced integration of ML-KEM, one of the three algorithms standardised by NIST in August 2024 (published as FIPS 203), into its SymCrypt library, and began piloting post-quantum TLS in a limited set of services. This is meaningful foundational work, but it is not the same as a completed migration of Microsoft 365’s storage, authentication and collaboration layers.
NIST’s finalisation of ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) in August 2024 marked the formal starting point for compliant migration. Before those standards existed, no vendor could claim NIST-certified quantum-safe cryptography. Now that they exist, the question is how quickly and completely each product integrates them.
As NIST’s post-quantum cryptography project lead Dustin Moody has stated: “Adversaries are harvesting encrypted data today with the intent to decrypt it once a cryptographically relevant quantum computer becomes available. The migration to post-quantum cryptography cannot wait.”
Which Parts of the Microsoft 365 Stack Remain Vulnerable?
Several layers of the Microsoft 365 architecture are not covered by the post-quantum work announced to date.
| Layer | Current Status | Quantum Risk |
|---|---|---|
| Transport (TLS) | PQC pilot in select services | Partially mitigated in pilot scope |
| At-rest file and email encryption | Classical AES with RSA/ECDH key wrapping | Key exchange vulnerable to harvest-now-decrypt-later |
| Authentication tokens (Azure AD / Entra ID) | RSA and ECDSA signatures | Token forgery risk once quantum capable hardware exists |
| Third-party connectors and APIs | Vendor-dependent, largely classical | Chain-of-trust gaps |
| Client-side desktop applications | No confirmed PQC rollout | End-to-end encryption not post-quantum |
The most immediate practical risk is the harvest-now-decrypt-later attack: an adversary captures Microsoft 365 traffic or exported data today and decrypts it once a cryptographically relevant quantum computer is operational. Estimates for when such machines will arrive range from ten to twenty years, but regulated data with a confidentiality requirement of that duration is already at risk. This is precisely why US National Security Memorandum NSM-10 directed federal agencies to begin cryptographic inventory and post-quantum migration planning, with the first inventory deadline set for 2025.
Anne Neuberger, US Deputy National Security Advisor for Cyber and Emerging Technology, described the stakes directly in the context of NSM-10: “The transition to quantum-resistant algorithms is one of the most important cryptographic transitions in history, and it needs to happen before quantum computers powerful enough to break current encryption exist.”
What Does a Quantum-Safe Workspace Look Like Today?
A genuinely quantum-safe workspace applies NIST-standardised post-quantum algorithms at every layer where classical asymmetric cryptography currently operates, not just the transport layer.
In practical terms, that means four things. First, key encapsulation for both data in transit and data at rest must use ML-KEM or an equivalent FIPS 203-compliant mechanism, replacing RSA and ECDH key wrapping. Second, digital signatures on documents, emails and identity tokens must migrate to ML-DSA or SLH-DSA. Third, the key management infrastructure itself must not re-introduce classical algorithms at any point in the chain, including hardware security modules and certificate authorities. Fourth, the hosting jurisdiction matters: data sovereignty and auditability of the cryptographic implementation require either on-premise deployment or a hosting provider subject to a legal framework that does not permit third-party compelled access.
Organisations evaluating alternatives to Microsoft 365 on quantum-safety grounds are looking at solutions built on open, auditable cryptographic stacks. Nextcloud Enterprise, for example, is deployable in configurations where the full encryption layer is under the customer’s direct control, and providers such as Qsentinel offer managed deployments that combine this architecture with post-quantum encryption and sovereign hosting in Swiss or on-premise environments.
The honest conclusion for IT and security leaders is this: Microsoft 365 is not quantum safe today in any comprehensive sense. The migration is underway at the library level, but the product surface of Exchange Online, SharePoint, Teams and the associated identity infrastructure has not been confirmed as fully migrated to NIST-standardised post-quantum cryptography. Organisations with long-horizon data sensitivity requirements should treat this not as a future problem but as a current architecture decision.
FAQ
Is Microsoft 365 currently quantum safe?
No, not fully. Microsoft has begun integrating post-quantum algorithms into its SymCrypt cryptographic library and is piloting post-quantum TLS in select services, but the full Microsoft 365 product suite has not completed migration to NIST-standardised post-quantum cryptography as of 2024.
What is the harvest-now-decrypt-later threat?
This is an attack strategy where adversaries capture encrypted data today and store it, planning to decrypt it once a sufficiently powerful quantum computer exists. Data protected only by classical encryption (RSA, ECDH) is already at risk from this strategy, particularly for information with long confidentiality requirements.
Which NIST standards apply to post-quantum encryption?
NIST finalised three standards in August 2024: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a stateless hash-based signature scheme. These replace RSA and elliptic-curve-based algorithms for sensitive applications.
Which layers of Microsoft 365 remain vulnerable?
At-rest encryption of stored files and emails, legacy authentication flows using classical RSA or ECDH key exchange, third-party integrations and connectors, and client-side encryption in desktop applications are all areas where quantum-safe migration is not yet complete or independently verified.
What does a quantum-safe workspace need beyond post-quantum TLS?
Post-quantum TLS protects data in transit but covers only one layer. A genuinely quantum-safe workspace also requires post-quantum algorithms for at-rest encryption, digital signatures on documents and identity tokens, and key management systems that do not rely on classical asymmetric cryptography at any point in the chain.
Hoe Qsentinel dit oplost
Qsentinel is the managed Nextcloud Enterprise workspace, enhanced by Qsentinel with post-quantum encryption and sovereign private AI, hosted in Switzerland or on-premise, out of reach of the CLOUD Act.