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

IIS TLS Certificate Deployment with CertKit

With public TLS certificate lifetimes shrinking to just 47 days by 2029, administrators must find ways to automate certificate enrollment and renewal for workloads that require them. One of the most common is Microsoft Internet Information Services (IIS). I’ve been using CertKit.io to handle this process for workloads like Always On VPN and DirectAccess, so it made sense to migrate my public-facing IIS servers to this solution as well. The migration went smoothly, but I encountered an unexpected issue when deploying a new IIS server using CertKit.

CertKit Agent

CertKit Agents make loading certificates on the server a breeze. The CertKit agent automatically detects installed software (e.g., Terminal Services, RRAS, DirectAccess, IIS, etc.) and handles the server-side process of assigning the TLS certificate to the application. For RRAS and DirectAccess, it works perfectly. For an IIS server with an HTTPS binding and TLS certificate already configured, it works without issue as well. However, I ran into a snag when I tried to deploy a certificate to a brand-new IIS server.

New Server

After installing the CertKit agent on an IIS server, it searches for existing HTTPS web bindings to identify the workload. However, on a freshly installed IIS server, no HTTPS bindings have been configured yet, so the agent doesn’t recognize the IIS workload.

Of course, you could create an HTTPS web binding before installing the agent, but you’ll need a TLS certificate first. This introduces the classic “chicken and egg” scenario. 🤪 Fortunately, there are a few ways to resolve the issue.

Windows Certificate Store

With this method, you configure the CertKit agent to download and install the certificate into the local computer certificate store on the IIS server. Once complete, you can create the HTTPS binding in the IIS Manager console or by using PowerShell. After that, restart the CertKit agent service by running the following PowerShell command.

Restart-Service -Name certkit-agent -PassThru

The IIS workload will now appear in the agent’s Software list. At that point, you can delete the Windows certificate store configuration and replace it with the IIS configuration.

Self-Signed Certificate

Using this method before installing the CertKit agent allows the agent to automatically discover IIS after installation, which can be helpful when deploying IIS servers programmatically. First, create a short-lived certificate (one day in this example) and configure the IIS site binding by running the following PowerShell commands.

$Hostname = 'www.example.net'
$Certificate = New-SelfSignedCertificate -DnsName $Hostname -CertStoreLocation 'Cert:\LocalMachine\My' -KeyAlgorithm RSA -KeyLength 2048 -HashAlgorithm SHA256 -NotAfter (Get-Date).AddDays(1) -TextExtension @('2.5.29.37={text}1.3.6.1.5.5.7.3.1')
$Params = @{
    Name                 = 'Default Web Site'
    BindingInformation   = '*:443:'
    Protocol             = 'https'
    CertificateThumbPrint = $Certificate.Thumbprint
    CertStoreLocation    = 'Cert:\LocalMachine\My'
}
New-IISSiteBinding @Params

Once complete, run iisreset.exe to apply the changes. Now, when you install the CertKit agent, it will automatically detect IIS, and you can assign your public TLS certificate accordingly. You can delete the old self-signed certificate later if desired.

Summary

If you’re automating server builds, the self-signed certificate approach is typically the easiest because it enables IIS discovery immediately. For ad-hoc deployments, installing to the Windows certificate store first is usually the quickest option.

Additional Information

CertKit.io

CerKit Agent Support for Always On VPN SSTP and DirectAccess IP-HTTPS TLS Certificates

Always On VPN IKEv2 Security Vulnerability April 2026

Microsoft published its Security Updates for April 2026 today, and the good news is that there are no Windows Server Routing and Remote Access (RRAS) vulnerabilities this month. However, they disclosed a critical remote code execution (RCE) vulnerability that impacts deployments using Internet Key Exchange version 2 (IKEv2).

IKE Service Extensions RCE

CVE-2026-33824 addresses a security vulnerability in the Windows Internet Key Exchange (IKE) Service Extensions. This vulnerability is a Remote Code Execution (RCE) vulnerability, with a CVSS 3.1 base score of 9.8 (Critical). Always On VPN implementations that use the device tunnel or IKEv2 for the user tunnel are affected.

Impact

This vulnerability presents a unique challenge to Always On VPN administrators as IKEv2 is required to support device tunnel connections. Some implementations also use IKEv2 for the user tunnel. In either case, the vulnerable VPN server, often domain-joined, is reachable from the Internet, greatly increasing the attack surface and exposure to this vulnerability.

Recommendations

For deployments that use IKEv2 (device or user tunnel), administrators should update their RRAS server as soon as possible to protect against potential attacks on this service.

Not Using IKEv2?

If you are not using the device tunnel or IKEv2 for the user tunnel, ensure the following IKEv2 ports are blocked at the edge firewall.

  • Inbound UDP port 500 (IKE)
  • Inbound UDP port 4500 (IKE NAT-T)

In addition, consider disabling IKEv2 on the RRAS server by opening an elevated command window and running the following command.

netsh.exe ras set wanports device = "WAN Miniport (IKEv2)" rasinonly = disabled ddinout = disabled ddoutonly = disabled maxports = 0

Optionally, you can use the Routing and Remote Access management console (rrasmgnt.msc) to perform this task.

  1. Right-click on Ports and choose Properties.
  2. Select WAN Miniport (IKEv2).
  3. Click Configure.
  4. Uncheck Remote access connections (inbound only).
  5. Uncheck Demand-dial routing connection (inbound and outbound).
  6. Enter 0 in the Maximum ports field.
  7. Click Ok.

Additional Information

Microsoft Security Updates for April 2026

CVE-2026-33824 – Windows Internet Key Exchange (IKE) Service Extension RCE