Azure Post-Quantum Support in 2026

Published · Updated

Microsoft has been shipping post-quantum cryptography (PQC) across its platforms since late 2024, with general availability of ML-KEM and ML-DSA APIs arriving on Windows Server 2025 and Windows 11 in mid-2025. However, the story for Azure cloud services specifically is more nuanced: some PQC capabilities are production-ready, others are in preview, and several important services have no PQC support yet.

This article separates what is shipped and production-ready from what is announced, previewed, or planned. All information is verified against Microsoft’s official documentation and announcements as of August 2026.

SymCrypt: The foundation

SymCrypt is Microsoft’s core cryptographic library. It underpins Windows, Azure Linux, Microsoft 365, and Azure services. Understanding SymCrypt’s PQC status is essential because it determines what is even possible in the Microsoft ecosystem.

Status: Production (GA)

In September 2024, Microsoft updated SymCrypt to include ML-KEM (FIPS 203) and XMSS support. In May 2025, Microsoft announced ML-DSA support in SymCrypt as well. In June 2025, Microsoft announced they are rewriting SymCrypt in Rust for modernization, with ML-KEM and ML-DSA as part of the algorithm suite.

SymCrypt now supports:

AlgorithmStandardStatus
ML-KEM-512/768/1024FIPS 203GA
ML-DSA-44/65/87FIPS 204GA
XMSSSP 800-208GA

SymCrypt is open source on GitHub (MIT license) and provides the foundation for PQC across all Microsoft platforms.

Windows Server 2025 and Windows 11: PQC APIs

Status: Generally Available

Microsoft announced in July 2025 that PQC algorithms are generally available in Windows Server 2025 and Windows 11 (24H2, 25H2) and .NET 10. This includes:

  • ML-KEM key encapsulation via CNG (Cryptography Next Generation) APIs
  • ML-DSA digital signatures via CNG APIs
  • Hybrid TLS key exchange using ML-KEM alongside ECDH (via Schannel and Kestrel)

The hybrid TLS groups available are:

  • X25519MLKEM768 (NIST security level 3 hybrid)
  • SecP256r1MLKEM768
  • SecP384r1MLKEM1024

These can be enabled in TLS 1.3 connections on Windows Server 2025 and Windows 11 using standard TLS group configuration mechanisms.

Important: TLS 1.3 is a prerequisite for PQC. Microsoft explicitly states that organizations should migrate from older TLS versions before enabling PQC.

Azure TLS: Hybrid post-quantum key exchange

Status: Rolling out, varies by service

Microsoft is deploying ML-KEM hybrid key exchange across Azure service endpoints. The timeline and completeness vary:

What works today

  • ASP.NET / Kestrel: Hybrid TLS with ML-KEM key exchange groups is GA when running on Windows Server 2025. Schannel (Windows TLS stack) negotiates X25519MLKEM768 by default when both client and server support it.
  • Azure App Service on Windows Server 2025: Inherits Schannel PQ support.
  • .NET 10 HttpClient: Supports PQ TLS when running on Windows Server 2025 or Linux with SymCrypt-OpenSSL 1.9.0+.

What does NOT work yet

  • Azure Front Door: No public documentation of ML-KEM support for edge TLS termination.
  • Azure Application Gateway: No PQC-specific TLS policy options documented.
  • Azure CDN: No ML-KEM support announced.

The gap between Windows platform support and Azure managed service support is significant. Having ML-KEM in SymCrypt and Schannel does not automatically mean every Azure service’s TLS endpoint negotiates it. Each service must explicitly enable and test the new cipher groups.

Azure Key Vault: No PQC key types yet

Status: Not available

As of August 2026, Azure Key Vault does not support post-quantum key types. The documented key types remain:

  • EC (P-256, P-256K, P-384, P-521)
  • RSA (2048, 3072, 4096)
  • oct-HSM / AES (128, 192, 256) for symmetric operations (Premium tier, preview)

There are no ML-KEM or ML-DSA key types available in Key Vault vaults or Managed HSM. You cannot generate, store, or use post-quantum keys in Azure Key Vault today.

Microsoft does note that AES-256 symmetric keys stored in Key Vault are considered “quantum-resistant” per CNSA 2.0 guidance (symmetric algorithms require only doubled key sizes for quantum security). But this is not the same as having native post-quantum asymmetric key support.

Contrast with AWS: AWS KMS added ML-DSA signing key support in June 2025 and supports ML-KEM hybrid TLS for API connections. Azure Key Vault lags significantly in this area.

Contrast with Google Cloud: Google Cloud KMS PQ signatures reached GA in July 2026. KEM operations and the August 2026 quantum-safe key import methods remain Preview.

SymCrypt-OpenSSL: PQC for Azure Linux

Status: GA (version 1.9.0+)

For Azure Linux workloads, Microsoft provides SymCrypt-OpenSSL, an OpenSSL provider that routes cryptographic operations through SymCrypt. Version 1.9.0 (released May 2025) includes ML-KEM and ML-DSA support.

This means:

  • Linux VMs on Azure can use PQ TLS if running SymCrypt-OpenSSL 1.9.0+
  • Applications using OpenSSL on Azure Linux can access ML-KEM and ML-DSA
  • The underlying FIPS validation applies to the SymCrypt module

This is particularly relevant for containerized workloads on AKS (Azure Kubernetes Service) running Azure Linux.

.NET 10 PQC APIs

Status: GA

.NET 10 (released November 2025) exposes ML-KEM and ML-DSA APIs directly:

  • System.Security.Cryptography.MLKem class for key encapsulation
  • System.Security.Cryptography.MLDsa class for digital signatures
  • Integration with HttpClient for hybrid PQ TLS connections

These APIs delegate to SymCrypt on Windows and to SymCrypt-OpenSSL on Linux. They are production-ready and follow the NIST FIPS 203/204 standards.

Azure DevOps SSH: No PQC

Status: Not available

Azure DevOps SSH endpoints do not support post-quantum key exchange. OpenSSH 10.2 (which supports the mlkem768x25519-sha256 hybrid key exchange) shows warnings when connecting to Azure DevOps because only classical Diffie-Hellman groups are offered. RFC 10042 now provides a published Informational reference for hybrid ML-KEM SSH key exchange, but that standards milestone does not add support to an endpoint that does not offer the method. There is no announced timeline for PQC support in Azure DevOps SSH.

Active Directory Certificate Services: ML-DSA available

Windows Server 2025 AD CS supports pure ML-DSA certificate authorities and leaf certificates with the required 2026 security updates. All three ML-DSA parameter sets are supported. ML-KEM and composite ML-DSA or ML-KEM certificates remain planned phases in Microsoft’s documentation.

This is a Windows Server PKI capability operated by the organization. It is not an Azure Key Vault or Managed HSM PQ key type. Compatibility with relying parties must be tested because not all applications and devices recognize ML-DSA certificates.

Microsoft’s stated timeline

Microsoft has publicly committed to:

  • 2029: Enable early adoption of quantum-safe capabilities across products
  • 2033: Complete transition to post-quantum cryptography for all products and services

This is a long timeline. Organizations needing PQC support in Azure managed services today may find gaps, particularly in Key Vault, managed databases, and edge networking services.

What you can do today on Azure

For TLS connections (production-ready)

  1. Deploy workloads on Windows Server 2025 to get Schannel PQ TLS support
  2. Use .NET 10 applications with HttpClient configured for PQ TLS
  3. On Linux, deploy with SymCrypt-OpenSSL 1.9.0+ and configure applications for ML-KEM groups
  4. Ensure all connections use TLS 1.3 (mandatory for PQC)

For application-level cryptography (production-ready)

  1. Use .NET 10 ML-KEM/ML-DSA APIs for application-layer PQ operations
  2. Use SymCrypt directly (C/C++ workloads) for ML-KEM, ML-DSA, and XMSS
  3. Use SymCrypt-OpenSSL provider for existing OpenSSL-based applications on Linux

What you cannot do yet

  • Store or manage PQ keys in Azure Key Vault
  • Use PQ TLS with Azure Front Door, Application Gateway, or CDN
  • Use PQ signatures for Azure DevOps artifacts
  • Generate PQ certificates in Azure Managed HSM

Comparison with other cloud providers

For a maintained workflow-level view, see AWS vs Azure vs Google Cloud post-quantum support.

CapabilityAWSGoogle CloudAzure
PQ TLS for service APIsGA (KMS, ACM, Secrets Manager)Varies by service; not uniformly customer-configurablePartial (IaaS only)
PQ managed key workflowsKMS ML-DSA signing GA; ML-KEM is a separate TLS capabilityCloud KMS signatures GA; KEM and quantum-safe import PreviewNo PQ key types in Key Vault or Managed HSM
PQ crypto libraryAWS-LC (FIPS validated with ML-KEM)Tink + BoringSSLSymCrypt (GA)
Platform PQ APIsAWS-LC APIsCloud KMS APIs.NET 10, CNG, SymCrypt
Hybrid TLS to originGA (s2n-tls)Varies by serviceGA (Windows Server 2025)

Azure’s strength is in GA platform APIs through SymCrypt, Windows, and .NET. In managed key workflows, AWS offers production ML-KEM TLS and ML-DSA signing, while Google Cloud offers GA PQ signatures but Preview KEM and quantum-safe import capabilities. Azure Key Vault has no PQ key types.

SymCrypt FIPS validation status

Microsoft SymCrypt Cryptographic Library version 103.8.0 has an Active FIPS 140-3 Level 1 validation under certificate #5313, issued June 5, 2026. The certificate’s security policy lists ML-KEM and ML-DSA as non-approved, not allowed algorithms: invoking them causes the module to operate outside approved mode. SymCrypt can therefore expose production PQC APIs without those PQC operations being validated under certificate #5313.

The previous reference on this page to certificate #4688 was incorrect. Certificate #4688 belongs to Microsoft’s FIPS 140-2 BitLocker Dump Filter and is now Historical; it is not evidence for SymCrypt validation. See the FIPS 140-2 to FIPS 140-3 transition guide for how Active, Historical and algorithm-scope claims differ.

Contrast with AWS: AWS-LC 3’s Active FIPS 140-3 certificate #5314, issued in June 2026, includes ML-KEM as an approved algorithm. Its approved algorithm list does not show ML-DSA. AWS’s December 2024 announcement described the module entering the validation process, not an issued certificate.

Recommendations

  1. Start with TLS: Enable hybrid PQ TLS on Windows Server 2025 workloads today. This is the lowest-risk path because the hybrid approach means classical security is maintained even if there are PQ implementation issues.

  2. Plan around Key Vault gaps: If your architecture depends on Azure Key Vault for key management, recognize that PQ key types are not available yet. Consider using application-level PQ crypto (via .NET 10 or SymCrypt) with classical key wrapping in Key Vault as an interim measure.

  3. Monitor the managed services rollout: Azure Front Door, Application Gateway, and CDN PQ support will likely follow Windows Server 2025 adoption internally at Microsoft, but no dates are published.

  4. Use TLS 1.3 everywhere: This is a prerequisite and will require migration from TLS 1.2 where it is still in use.

References

  • Microsoft Security Blog: “Post-Quantum Cryptography APIs Now Generally Available on Microsoft Platforms” (July 2025)
  • Microsoft Tech Community: “ASP.NET, Kestrel and Schannel GA with TLS 1.3 Post-Quantum Cryptography” (July 2026)
  • Microsoft Tech Community: “Post-Quantum Cryptography Comes to Windows Insiders and Linux” (May 2025)
  • Microsoft Research: “Rewriting SymCrypt in Rust to modernize Microsoft’s cryptographic library” (June 2025)
  • SecurityWeek: “Microsoft Adds Support for Post-Quantum Algorithms in SymCrypt Library” (September 2024)
  • Microsoft Learn: “Key types, algorithms, and operations - Azure Key Vault” (updated July 2026)
  • Microsoft Security Blog: “Microsoft’s quantum-resistant cryptography is here” (December 2024)
  • Microsoft: “Companion guide: Transitioning to post-quantum cryptography” (January 2026)
  • GitHub: microsoft/SymCrypt (MIT License)

FAQ

Does Azure Key Vault support post-quantum keys?

No. As of August 2026, Azure Key Vault supports only EC (P-256/P-384/P-521), RSA, and AES key types. There are no ML-KEM or ML-DSA key types available. Microsoft has not announced a specific date for PQC key support in Key Vault.

Can I use PQ TLS to connect to Azure services?

It depends on the service and how you connect. If you connect to an Azure VM running Windows Server 2025 or to an application using .NET 10 on Azure, hybrid PQ TLS works. Managed service endpoints (like Azure SQL, Cosmos DB, or Storage) have not confirmed PQ TLS support.

Is SymCrypt FIPS-validated for PQC algorithms?

No under the currently verified certificate. SymCrypt version 103.8.0 has Active FIPS 140-3 certificate #5313, but that certificate’s security policy places ML-KEM and ML-DSA in the non-approved, not-allowed table. The APIs can be generally available while those operations remain outside the certificate’s approved mode. AWS-LC 3 certificate #5314 includes approved ML-KEM, but not ML-DSA, and was issued in June 2026.

What is the difference between SymCrypt and SymCrypt-OpenSSL?

SymCrypt is Microsoft’s core C cryptographic library. SymCrypt-OpenSSL is an OpenSSL engine/provider that routes OpenSSL API calls to SymCrypt’s implementations. This allows existing Linux applications that use OpenSSL to benefit from SymCrypt’s algorithms (including PQC) without code changes.

When will Azure fully support PQC?

Microsoft has stated a goal of enabling early adoption by 2029 and completing the full transition by 2033. For managed Azure services, no specific per-service timelines are published. The platform (Windows, .NET, SymCrypt) is ready; the managed services layer is catching up.

Should I wait for Azure PQC or use another provider?

If your primary concern is PQ TLS for API calls to cloud services, AWS provides production ML-KEM hybrid TLS on KMS, ACM, and Secrets Manager. Google Cloud KMS instead has GA ML-DSA and SLH-DSA signing plus Preview KEM operations and quantum-safe software-key import. If your workloads run on Azure IaaS, you can use GA platform PQ APIs through SymCrypt, .NET 10, or OpenSSL 3.5, while Azure Key Vault still lacks PQ key types.

Sources