Microsoft AD CS Adds Post-Quantum Cryptography Support with ML-DSA

Despite predictions of its decline, Microsoft Active Directory Certificate Services (AD CS) continues to evolve. Following significant enhancements introduced in late 2025, including CRL partitioning and support for 16K database pages, the May 2026 update adds another important capability: support for Post-Quantum Cryptography (PQC).

ML-DSA

Specifically, the May 2026 update adds support for ML-DSA-44, ML-DSA-65, and ML-DSA-87 in Windows Server 2025 for AD CS. This enables administrators to begin evaluating post-quantum cryptographic algorithms and assessing PQC readiness in enterprise PKI environments

Configuration

After applying the May 2026 update to an issuing Certification Authority (CA), administrators will find new PQC algorithms under the Algorithm name drop-down list, as shown here.

Note: If you don’t see these new algorithms, ensure you have selected Key Storage Provider from the Provider Category drop-down list. In addition, ensure that you select Signature on the Request Handling tab.

Test Results

Initial testing across common enterprise certificate scenarios produced mixed results. While PQC works well in some scenarios, other workloads still show limitations.

Code Signing

Code signing with an ML-DSA-44 certificate issued by AD CS works perfectly. For example, I can use Set-AuthenticodeSignature to sign a PowerShell script, as shown here.

Viewing the file’s properties shows that the encryption algorithm used to sign the file was ML-DSA-44, as expected.

IIS

TLS-based workloads proved more challenging. Attempts to configure an HTTPS binding in IIS failed with the following error message.

There was an error while performing this operation. A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520).

RRAS and SSTP

Similar limitations occurred when testing remote-access VPN scenarios using RRAS and SSTP. Specifically, configuring a PQC TLS certificate for SSTP in RRAS failed. Although I was able to assign the certificate using Set-RemoteAccess, the RemoteAccess service failed to start.

Remote Desktop

Unfortunately, using PQC certificates for RDP also fails. Although I could assign the PQC certificate to the RDP listener, clients fail to connect using RDP and return the following error message.

This computer can’t connect to the remote computer. Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

Error code: 0x904
Extended error code: 0x7

Summary

The May 2026 update marks an important milestone for AD CS by introducing initial support for PQC algorithms, allowing organizations to begin evaluating ML-DSA certificates in enterprise environments. Early testing shows promising results for signing scenarios such as code signing; however, broader infrastructure workloads, including TLS, VPN, and Remote Desktop, remain limited today. Although PQC support is still in its early stages, these updates demonstrate Microsoft’s ongoing investment in AD CS and provide administrators with an opportunity to begin preparing their PKI environments for the post-quantum future. Additional PQC enhancements, including ML-KEM support and broader ecosystem integration, are anticipated in future Windows updates.

Additional Information

Microsoft May 2026 Security Updates (KB5087539)

Post Quantum Cryptography in the Enterprise

Microsoft Security Service Edge Now Generally Available

A few weeks ago, Microsoft announced the general availability of its Security Service Edge (SSE) offering, Global Secure Access (GSA). GSA encompasses Entra Internet Access, a cloud-based Secure Web Gateway, and Entra Private Access, a Zero Trust Network Access (ZTNA) solution for accessing private data and applications on-premises.

ZTNA vs. VPN

Entra Private Access will be a compelling alternative to traditional VPN solutions such as Windows Always On VPN. Where traditional VPNs grant the endpoint an IP address on the internal network, Entra Private Access provides more granular access and does not require the device to be directly connected to the network.

GSA Client

Administrators must install the GSA client on all endpoints using Entra Internet Access or Entra Private Access. Today, the client is available for Windows and Android devices. iOS and macOS clients are forthcoming.

Private Network Connector

The Entra Private Access solution relies on the Entra Private Network Connector. The Entra Private Network Connector is a software component installed on-premises that provides remote access connectivity. Previously, it was called the Azure AD Application Proxy. Essentially, it is the same technology extended to support TCP and UDP network access in addition to HTTP.

Limitations

Entra Private Access is the way of the future for secure remote access. However, today, there are still some important limitations associated with this technology.

Private DNS

Although Microsoft announced general availability for Entra Private Access, it still lacks the private DNS feature many organizations require to provide feature parity with their existing VPN. This feature is still in private preview at the time of this writing. Hopefully, Microsoft will release this feature soon.

Device Connection

Entra Private Access does not support device-based connections. This limits its capabilities for domain-joined devices. If your organization uses hybrid Entra join today, consider sticking with Always On VPN until you move to native Entra joined endpoints.

Licensing

Global Secure Access (Entra Private Access and Entra Internet Access) are included in the Microsoft Entra Suite license. More information about Entra licensing can be found here.

Additional Information

Microsoft Global Secure Access Now Generally Available

Microsoft Entra Global Secure Access (GSA) Overview

Microsoft Entra Security Service Edge (SSE) on the RunAs Radio Podcast

Microsoft Entra Plans & Pricing

Always On VPN PowerShell Script Issues in Windows 11

Many administrators are now beginning to test Always On VPN functionality on the latest Microsoft Windows client operating system, Windows 11. Initially, Microsoft had some issues with provisioning and managing Always On VPN profiles on Windows 11 using Microsoft Endpoint Manager/Intune, but those have been resolved. However, some lingering problems may delay enterprise deployments of Always On VPN on Windows 11 for some organizations, specifically those using PowerShell with Active Directory group policy startup scripts or System Center Configuration Manager (SCCM).

Important Note: The issues outlined in this article have been resolved! The fix for the WMI enumeration bug is addressed in the following updates:

Windows 11 21H2 – KB5022905 (build 22000.1641)

Windows 11 22H2 – KB5026446 (build 22621.1778)

MakeProfile.ps1

Microsoft has published guidance for deploying Always On VPN profiles using PowerShell with their MakeProfile.ps1 script. This script extracts configuration details from a template VPN profile to create another PowerShell script called VPN_Profile.ps1, which is used to create the Always On VPN profile. SCCM administrators commonly use VPN_Proifle.ps1 to deploy Always On VPN profiles. However, running this script on Windows 11 fails and returns the following error message.

“Unable to create [VPN profile name] profile: A general error occurred that is not covered by a more specific code.”

This issue appears to be related to a problem with the WMI-to-CSP bridge, specifically enumerating the MDM_VPNv2_01 class in the root\cimv2\mdm\dmmap namespace. Here you can see the template VPN profile with PowerShell and Get-VpnConnection.

However, attempts to view the MDM_VPNv2_01 class of this VPN profile using PowerShell and Get-CimInstance fail.

New-AovpnConnection.ps1

Interestingly, administrators may find that my Always On VPN PowerShell deployment script works more reliably on Windows 11, although not always. In my experience, I’ve found that it sometimes fails once (profile is loaded, but the configuration is incomplete), then works after deleting the profile and creating it again. If the Microsoft-provided script isn’t working, give mine a try and see if it works better for you.

Note: When deploying Always On VPN profiles using my PowerShell deployment script via Active Directory startup scripts, it seems to fail consistently for some reason. Go figure. 😉

Remove-AovpnConnection.ps1

The issues described previously with Windows 11 are also negatively affecting some of my other PowerShell scripts. For example, running Remove-Aovpnconnection.ps1 on Windows 11 fails and returns the following error message.

“A general error occurred that is not covered by a more specific error code.”

Current Status

Microsoft is currently aware of this issue. However, I am aware of no timeframe for resolution at the time of this writing. Hopefully, Microsoft addresses this soon so organizations can move forward with their Windows 11 migration projects.

Additional Information

Microsoft Windows Always On VPN Windows 11 Issues with Microsoft Endpoint Manager/Intune

Microsoft Windows Always On VPN Profile Deployment Script

Microsoft Windows Always On VPN Remove Always On VPN Profile Script

Always On VPN PowerShell Script Repository on GitHub