Always On VPN and Azure VPN Gateway SSTP Protocol Retirement

The Azure VPN gateway has been an option for supporting Microsoft Always On VPN client connections for organizations moving resources to the cloud. Today, Azure VPN gateway supports Internet Key Exchange version 2 (IKEv2), OpenVPN, and Secure Socket Tunneling Protocol (SSTP), although SSTP support has long been limited in scope and scalability. However, Microsoft recently indicated that some important changes are coming soon that will affect VPN protocol support on the Azure VPN gateway.

SSTP and Azure VPN Gateway

Microsoft has announced plans to deprecate and eventually remove support for SSTP on the Azure VPN gateway.

Key Dates

Here is Microsoft’s timeline for retiring SSTP for VPN connections.

  • March 31, 2026 – SSTP can no longer be enabled on new or existing gateways
  • March 31, 2027 – Existing SSTP connections will stop functioning

SSTP: Second Class Citizen

The retirement of SSTP for Azure VPN gateway should not have a significant impact on Always On VPN deployments. Support for SSTP on Azure VPN gateway has always been limited, making it a less viable option for most Always On VPN deployments. SSTP connections are capped at 128 concurrent connections (256 in active-active mode), regardless of gateway SKU. Additionally, Azure VPN gateway does not support simultaneous user and device tunnels, further limiting its usefulness in modern Always On VPN designs.

Plan Migration Now

If you are using Azure VPN gateway to support Always On VPN client connections, now is the time to begin planning a migration to IKEv2, which offers better scalability and native Always On VPN support. Alternatively, consider Windows Server RRAS in Azure, a third-party VPN solution, or Entra Private Access if Azure VPN gateway no longer meets your requirements.

More Information

For official guidance, see SSTP Protocol Retirement and Connections Migration. If you’re unsure how this change affects your Always On VPN deployment, or you would like help planning a migration, this is a good time to review your design and roadmap. Fill out the form below, and I’ll provide you with more information.

Additional Information

SSTP Protocol Retirement and Connections Migration

Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN

Windows Server RRAS in Microsoft Azure

Microsoft Entra Private Access

Resolving PKCS Certificate Mapping Issues in Windows Autopilot Hybrid Join Deployments

Microsoft Windows Autopilot streamlines device provisioning through Intune, allowing IT administrators to preconfigure new Windows devices with minimal hands-on effort. However, when combined with Hybrid Entra Join and PKCS certificate deployment, specific challenges arise—particularly with certificate mapping and authentication.

Hybrid Entra Join

During autopilot provisioning, administrators may also choose to join the device to their on-premises Active Directory domain, a deployment model called Hybrid Entra join. Hybrid Entra join presents some unique challenges when using Autopilot to remotely provision devices. Specifically, the user must have connectivity to a domain controller to perform the first logon, as they do not have a user profile on the endpoint.

Device Tunnel

To support offline Hybrid Entra join during Autopilot provisioning, administrators can deploy the Always On VPN device tunnel to provide pre-logon connectivity to domain controllers. A device tunnel connection enables users to log on to their newly provisioned device remotely.

Requirements

The following prerequisites must be met to support the Always On VPN device tunnel.

  • The endpoint must be running Windows Enterprise edition.
  • An Always On VPN device tunnel profile must be assigned to the device.
  • A machine certificate must be deployed to the endpoint that includes the Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2).

Note: If you plan to use the subscription step-up upgrade from Windows Professional to Windows Enterprise, the device tunnel will not connect automatically after provisioning is complete, which prevents the user from logging in. More details and a workaround for this issue can be found here.

Strong Certificate Mapping

Microsoft knowledge base article KB5014754, released in May of 2022, introduced changes to domain controllers to require strong certificate mapping when using certificates to authenticate to Active Directory (AD). It was initially deployed in compatibility mode, only warning administrators when certificates are used for authentication that aren’t strongly mapped. However, full enforcement is mandatory beginning with the September 2025 security updates. This requirement introduces some challenges when issuing certificates to the device using PKCS during Autopilot provisioning.

Intune PKCS Certificates

When using PKCS certificates and the Intune Certificate Connector, the endpoint’s on-premises AD security identifier (SID) is not added to the issued certificate during Autopilot. Interestingly, this does not happen when using SCEP certificates. If the device certificate is not strongly mapped, the Always On VPN device tunnel will still authenticate successfully because Always On VPN does not use AD to authenticate device connections. Instead, Always On VPN simply verifies the certificate (e.g., that it is not expired or revoked) and allows authentication if the certificate passes the validation.

However, enterprise Wi-Fi access may fail without strongly mapped certificates if device authentication is required. Also, there may be other scenarios where a device authentication certificate without strong mapping may cause authentication to fail.

Workarounds

There are a few ways to work around this limitation. Consider the following options.

Native Entra ID Join

The simplest way to avoid the challenges of PKCS certificates and Hybrid Entra join is to avoid it altogether in favor of native Entra join. However, this may not be an option for everyone.

Use SCEP

For some reason, certificates issued with SCEP do not suffer from this limitation. In my testing, SCEP certificates are always strongly mapped. However, deploying SCEP certificates is much more complex than using PKCS. (Pro tip: Cloud PKI for Intune uses SCEP and requires no configuration! It’s definitely something to consider.)

Short-Lived Certificates

Another option is to deploy temporary, short-lived certificates (valid for only a few days) using PKCS to ensure the Always On VPN device tunnel works, and then deploy a permanent, long-term certificate post-deployment that includes the strong mapping. To do this, administrators can leverage dynamic group assignments in Intune. For example, the administrator can assign the short-lived certificate to an Autopilot Provisioning devices group and later assign a long-term certificate to the Hybrid Joined devices group.

Here’s an example of the dynamic group membership configuration.

Autopilot Provisioning Devices:

(device.devicePhysicalIDs -any (_ -contains “[ZTDId]”)) -and (device.deviceTrustType -ne “ServerAD”)

Hybrid Entra Join Devices:

(device.deviceTrustType -eq “ServerAD”)

In this configuration, the initial PKCS certificate is deployed without the strong mapping when the endpoint is enrolled to Autopilot but has not yet joined the domain. During this time, the endpoint will only be a member of the Autopilot Provisioning Devices group and will receive the short-lived, temporary certificate. Later, once the endpoint has successfully joined the domain, the device will move from the provisioning group to the Hybrid Entra Join Devices group. When this happens, a permanent, strongly mapped long-term certificate is enrolled on the device.

Manual Certificate Mapping

Certificates can be manually mapped via the altSecurityIdentities property of the computer object in AD. Obviously, this doesn’t scale well, so my good friend Steve Prentice published a PowerShell script to automate this process. You can find more details and the script here.

Summary

Windows Autopilot streamlines device provisioning with Intune, but Hybrid Entra Join introduces challenges when PKCS certificates lack strong mapping during initial deployment, potentially disrupting VPN and Wi-Fi authentication. Administrators can avoid this by switching to native Entra join or by using workarounds such as switching to SCEP, using short-lived certificates, or manually mapping certificates.

Additional Information

KB5014754 – Certificate-based authentication changes on Windows domain controllers

How To: Map a user to a certificate via all methods available in the altSecurityIdentities attribute

Hybrid Autopilot: Automating altSecurityIdentities

Configure Microsoft Entra hybrid join

Overview: Cloud PKI for Microsoft Intune

What’s New in Absolute Secure Access v14

Absolute Software recently announced a significant upgrade for its popular secure remote access and Zero Trust Network Access (ZTNA) solution. Version 14 of Secure Access introduces many compelling new features and updates that administrators will find beneficial. In addition, crucial security vulnerabilities in the previous release have been addressed.

New Features

Absolute Secure Access v14.x includes many enhancements over previous releases. Here are a few of the highlights.

Improved Performance

Absolute Secure Access v14 provides much faster throughput on multi-gigabit networks (e.g., 2.5Gbps Wi-Fi 6E/7 or 10Gbps wired). New kernel-level optimizations reduce CPU overhead by up to 40% on high-speed links, improving performance on faster networks.

Modern Certificate Handling

SHA-1 has been deprecated since 2011, and beginning with Absolute Secure Access v14, support for SHA-1 certificates has been removed completely.

Enhanced Client Auto Reconnect

Improved client auto-reconnect logic now survives Windows standby mode for more than 12 hours (previous versions were capped at around 4 hours). This will reduce frustration when devices return from standby for extended periods.

Automatic Host Group Updates

Host groups are an excellent way to streamline policy configuration for services like Microsoft 365 and AWS. These cloud providers publish the IP addresses of their services, which are dynamic and often change over time. Absolute Secure Access v14 now supports automatic host group updates for these services. Microsoft 365 updates occur every 28 days, and AWS updates occur every 5 days by default. This interval is configurable for administrators.

Security Updates

Absolute Secure Access v14 closes four server-side CVEs as well as 14 third-party CVEs (Apache, OpenSSL, etc.) that were not patched in v13.x.

Summary

If you have deployed previous versions of Absolute Secure Access, consider upgrading to v14.x today. You’ll gain improved performance, reduced administrative overhead, critical security updates, and much more. If you’d like help with your migration or want to learn more about the new capabilities in Absolute Secure Access v14, fill out the form below, and I’ll provide more information.

Additional Information

Absolute Secure Access

Absolute Secure Access Enterprise VPN Advanced Features In Depth

Absolute Secure Access and IPv6