On October 19, 2026, Microsoft announced an update for the Entra Global Secure Access (GSA) client. This latest release, v2.34.222, adds support for a new sign-in option, updates Conditional Access sign-in frequency, improves diagnostics, and enhances local network bypass. It also improves Windows Firewall behavior off network, along with telemetry and accessibility improvements.
The GSA client now supports Web sign-in for Windows. This credential provider enables browser-based Windows sign-in using methods such as Microsoft Authenticator, Temporary Access Pass (TAP), or a SAML-P federated identity. Web sign-in requires a Microsoft Entra-joined device running Windows 11 version 22H2 with KB5030310 or later, plus internet connectivity.
Windows Firewall Profile
This release improves Windows Firewall profile selection when Private Access is enabled. When the device is not directly connected to the corporate network, Windows Firewall does not activate the Domain profile.
Traffic Forwarding Profile Details
The new GSA client features improved diagnostics. With this update, the Forwarding profile tab in the Advanced diagnostics section now displays the Traffic Forwarding Profile Name as it appears in the Entra admin center, along with the Traffic Forwarding Profile ID.
Traffic Forwarding Profile Name and ID
Conditional Access
GSA client v2.34.222 now includes support for Conditional Access sign-in frequency for Private Access applications. This feature is part of a phased rollout and might not be available in all tenants immediately.
Prefer Local Network Bypass
With this update, the Prefer local network option limits bypass to connections destined for IP addresses in common private network ranges. Microsoft documentation doesn’t elaborate on specifically which ‘common private network ranges’, but I suspect this means private IPv4 address ranges as defined in RFC 1918.
GSA Traceroute Changes
In GSA client v2.34.222, Microsoft has replaced the command-line version of the GSA traceroute tool (GsaTracert.exe) with a new GUI version. However, during my initial testing (and confirmed by others testing this feature), it appears to be broken at this time. When I launch GsaTracert.exe, the UI returns the following error message.
“Could not retrieve the forwarding profile from the registry. Ensure the Global Secure Access Client is installed and running.”
I will post an update as soon as Microsoft resolves this issue.
Additional Changes
In addition to the changes highlighted above, the new GSA client includes the following additional enhancements.
UDP tunneling improvements
Memory utilization improvements
New telemetry capabilities
Accessibility improvements
Bug fixes and other miscellaneous improvements
Summary
GSA client v2.34.222 introduces several useful enhancements for administrators and users. Organizations should validate the update against their existing configuration before broad deployment. My initial testing also identified an issue with the updated diagnostic tool, as described above.
Entra Internet Access includes an optional TLS Inspection feature that allows the GSA client to decrypt HTTPS traffic, inspect for threats, identify policy violations, and enforce Data Loss Prevention (DLP) policies. Importantly, enabling TLS inspection for GSA allows administrators to apply prompt injection protection policies to control the usage of generative AI applications.
TLS Inspection Certificate
Before enabling TLS inspection for Entra Internet Access, administrators must first create a TLS inspection certificate. This certificate must be signed by a trusted certification authority (CA). The process is simple and straightforward, and well-documented here.
Invalid Certificate Error
After enabling Entra Internet Access TLS inspection, administrators may find that all websites subject to TLS inspection are inaccessible. The browser displays the following error message:
Your connection isn’t private Attackers might be trying to steal your information from <website> (for example, passwords, messages, or credit cards.)
NET:ERR_CERT_INVALID
Clicking on the Advanced button shows the following additional information:
<website> uses encryption to protect your information. When Microsoft Edge tried to connect to <website> this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be <website>, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Microsoft Edge stopped the connection before any data was exchanged.
You can’t visit <website> right now because the website sent scrambled credentials that Microsoft Edge can’t process. Network errors and attacks are usually temporary, so this page will probably work later.
Root Cause (Pun Intended!)
This issue can be caused by restrictions placed on the root CA. Specifically, if the root CA certificate includes a policy that restricts the CA path length (the number of subordinate CAs allowed downstream), the Microsoft Global Secure Access Intermediate CA, which issues certificates for TLS-inspected websites, cannot be validated successfully.
In this example, the root CA certificate includes a basic constraint that defines a maximum of 1 intermediate CA in the chain. Crucially, the extension is marked as Critical, so it must be enforced.
Because the root CA enforces a path length constraint of 1, the TLS inspection subordinate CA can exist beneath it, but no additional subordinate CA certificates are permitted. As a result, the Microsoft Global Secure Access Intermediate CA exceeds the allowed chain depth, causing certificate validation to fail.
Resolution
The fix for this issue is simple, yet complex. The root CA certificate must be renewed, this time without enforcing the CA path length policy. To do this, open an elevated command window on the root CA and run the following command.
Important: If your CA hierarchy uses CAPolicy.inf to define the CAPathLength setting, update the file before renewing the CA certificate.
Next, restart the CA service for the change to take effect.
Restart-Service CertSvc -PassThru
Finally, renew the CA certificate.
certutil.exe -f -renewcert ReuseKeys
Restart the CA service once more for the change to take effect.
Restart-Service CertSvc -PassThru
Once complete, distribute the new root CA certificate to Active Directory and to Intune-managed endpoints using a Trusted Certificate device configuration policy.
Finally, configure a new Entra TLS inspection certificate in the Entra admin center to replace the old one, signed with the updated root CA certificate. Once the certificate has been uploaded, ensure it is enabled.
Important: Renewing a root CA certificate can be highly disruptive. Proceed with caution in production environments. Ensure that all enterprise assets receive the new root CA certificate in a timely manner. Alternatively, to reduce the chance of disruption, consider deploying a new root CA dedicated to Entra TLS inspection.
Result
Once these changes are made, the certificate chain will allow the Microsoft Global Secure Access Intermediate CA to exist beneath the TLS inspection CA, resulting in a valid certificate chain for TLS-inspected websites. Browsers will once again trust the dynamically generated certificates, eliminating the ERR_CERT_INVALID error.
The following certificate chain shows the corrected configuration after renewing the root CA certificate and recreating the TLS inspection certificate.
Summary
Entra Internet Access TLS inspection relies on a certificate chain that includes the Microsoft Global Secure Access Intermediate CA. If the root CA that signs the TLS inspection certificate enforces a restrictive path length constraint, certificate validation can fail, causing browsers to display ERR_CERT_INVALID errors for all TLS-inspected websites. Reviewing the certificate chain and understanding how basic constraints affect subordinate CAs can help quickly identify and resolve this issue. When deploying TLS inspection, ensure that CA hierarchy restrictions are compatible with this deployment scenario. Consider using a dedicated PKI hierarchy to minimize operational impact.
I recently had the opportunity to connect with Merill Fernando from Microsoft as a guest on his popular Entra.News podcast to discuss Microsoft Entra Private Access, which is part of the Entra Global Secure AccessSecurity Service Edge (SSE) service. We spent the hour talking about the similarities and differences between classic VPN technologies and zero-trust network access (ZTNA). In addition, we discussed some technical aspects of Entra Private Access, and I shared migration and coexistence strategies to help ease the transition to zero trust. Also, we discussed the importance of integrating Entra Conditional Access and the shift from network to application access. You’ll find the interview at Entra.News and also on YouTube. Enjoy!
Microsoft Entra Private Access is a Zero Trust Network Access (ZTNA) solution that provides secure access to private enterprise resources. With the release of Global Secure Access (GSA) client version 2.26.108, Microsoft has addressed a crucial functionality gap by adding support for Bring Your Own Device (BYOD), enabling secure access from non-managed endpoints.
BYOD Support in Global Secure Access
Microsoft introduced BYOD support for Entra Private Access with the release of the GSA client version 2.26.108. This update allows the GSA client to be installed on Microsoft Entra-registered devices that are not domain-joined or managed by the organization, enabling secure access to private resources from personal or unmanaged endpoints.
Use Cases
BYOD support in GSA and Entra Private Access enables several common scenarios where network access from managed devices is impractical or unavailable, including:
Vendor or contractor access
IT incident response from unmanaged endpoints
Temporary or seasonal staffing
Collaboration with external partners
Replacing Legacy VPN for Ad Hoc Access
Historically, legacy VPN solutions were the primary option for providing ad hoc access to private resources from unmanaged devices. With the introduction of BYOD support in the GSA client, organizations can now extend Entra Private Access to these scenarios without deploying or maintaining a separate VPN infrastructure.
Additional Changes
In addition to adding BYOD support, GSA client v2.26.108 includes the following new enhancements.
GSA traceroute enhancements, including a 50M MB speed test between the client and edge service.
Summary
BYOD support removes a key barrier to adopting Microsoft Entra Private Access. Organizations can now securely provide access to private resources using Zero Trust policies, even when users connect from unmanaged or personal devices, and without relying on legacy VPN solutions.
The predominant solution for secure remote access today in the Microsoft ecosystem is Always On VPN. Always On VPN is based on traditional Virtual Private Network (VPN) technology originally developed in the mid-1990s. However, Microsoft recently introduced Entra Private Access, which is part of the Global Secure Access (GSA) Security Service Edge (SSE). Entra Private Access is an identity-centric Zero Trust Network Access (ZTNA) solution designed to replace traditional VPN solutions. It offers significantly improved security with granular resource access without dependency on on-premises infrastructure. This article outlines where each solution fits best and how organizations can transition safely between them.
Always On VPN
First introduced in Windows 8, Microsoft Always On VPN provides seamless, transparent, secure remote access using client-based VPN protocols such as Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). When establishing a VPN connection, a virtual network adapter is created, and an IP address is assigned to the interface to facilitate tunneled network communication with the internal network.
Architecture
Always On VPN requires substantial on-premises supporting infrastructure. In addition to the VPN servers themselves, administrators must also deploy authentication servers (RADIUS or NPS) and certificate services (AD CS). Administrators must manage public TLS certificates for SSTP connections. Also, larger deployments may require on-premises load balancers and/or cloud-based Global Server Load Balancing (GSLB) solutions. Further, additional configuration is needed to integrate Entra ID Conditional Access. Because this infrastructure must be publicly accessible by design, it becomes an attractive target for attackers. In addition, the complex infrastructure has many interdependencies, resulting in significant administrative overhead for network and security administrators.
Access Model
Most commonly, Always On VPN provides full network access to the internal network. Full network access is accomplished by configuring IP routing on the client to ensure internal client network subnets are routed over the VPN tunnel. In this model, clients are often implicitly trusted once connected. Once authenticated and authorized, users receive full, unfettered access to the internal network across all protocols and ports. This level of access introduces a significant security risk and does not adhere to modern zero-trust network access models. To address this, administrators must implement additional security controls internally (perimeter or DMZ firewalls) to restrict network access for Always On VPN clients.
Zero Trust Always On VPN?
Always On VPN includes support for traffic filters that can restrict network access and provide zero-trust-like access. However, these controls exist only on the client side, so an attacker with administrative access to the endpoint can easily bypass them. They should not be considered a reliable way to enforce zero trust for Always On VPN connections.
Entra Private Access
Entra Private Access is part of Microsoft’s Global Secure Access (GSA) Security Service Edge (SSE). It is a robust, cloud-based zero-trust network access (ZTNA) service that provides granular access to on-premises resources. It requires installing a client-side agent and one or more Private Network connectors on-premises to facilitate remote network access. Entra Private Access deeply integrates with Entra ID, so you can easily configure Conditional Access policies for any published resource, including multifactor authentication for legacy protocols such as SSH.
Limited Network Access
Unlike legacy VPNs, GSA does not create a virtual network interface when establishing a connection. Instead, GSA operates as a filter driver deep in the Windows networking stack, intercepting and rerouting network traffic bound for the internal network. The GSA client eliminates the complexities of IP address management, network routing, and firewalling. In addition, authentication and authorization are handled natively by Entra ID and Conditional Access.
Minimal Infrastructure
Entra Private Access is a cloud-based service with minimal on-premises supporting infrastructure requirements. Administrators must only deploy the Entra Private Network connector on one or more on-premises servers to facilitate remote access for Global Secure Access clients. The Entra Private Network is a lightweight software agent that requires little to no post-deployment support. The administrative burden is much lighter compared to Always On VPN.
Key Differences at a Glance
The table below highlights the most important architectural, security, and operational differences to help determine which solution best fits your environment.
Aspect
Always On VPN
Entra Private Access
Architecture
On-premises VPN gateway(s)
Cloud-based service
Access Model
Full network access via a routable IP address assigned to the endpoint
Per-resource zero-trust network access (ZTNA); no full network access
Authentication
On-premises AD or Entra ID (AD-synced accounts only)
Entra Private Network connector (minimum one server, two recommended for redundancy)
Device Support
Windows only
Cross-platform (Windows, macOS, iOS, Android)
Licensing
Included in OS license
Additional per-user costs with Entra Suite or standalone Entra Private Access license
Advantages of Always On VPN for Domain-Joined Endpoints
Always On VPN integrates more naturally with classic Active Directory domain-joined Windows devices. Always On VPN includes features that Entra Private Access does not currently provide, which administrators may require to provide full support for their mobile devices.
Device Tunnel Support
The Always On VPN device tunnel provides machine-based pre-logon connectivity. The device tunnel ensures access to on-premises authentication services (domain controllers) before the user logs on to the endpoint. The device tunnel allows for logging in without cached credentials (e.g., for new users) and streamlines password changes. In addition, it ensures network access to support complete group policy processing for remote users. Entra Private Access is user-based only and does not include device-based connectivity. The device tunnel is one of the most significant functional gaps between Always On VPN and Entra Private Access.
Note: Although device-based connections are not currently available in Entra Private Access at the time of this writing, Microsoft may add the feature in the future.
Windows Native Integration
Always On VPN leverages the built-in Windows VPN client, which integrates deeply with the operating system. The Windows VPN client is mature and robust, supporting secure authentication protocols with certificates or smart cards. Always On VPN requires no additional client software. For Entra Private Access, administrators must deploy and manage a separate software component, the Global Secure Access client.
Full Network Access
The domain is a trust boundary, and domain-joined endpoints require broad network access to function. For example, domain-joined endpoints must have access to domain controllers, and most access those resources using several protocols and numerous different ports. In addition, these endpoints must be able to connect to a variety of other internal resources, such as DNS servers, certification authorities (CAs), revocation servers (HTTP, OCSP, LDAP), systems management servers, file shares, printers, and more. Furthermore, much of this access occurs via Remote Procedure Call (RPC) and Distributed COM (DCOM), which use ephemeral (dynamic) port ranges (49152-65535). Enforcing firewall policy to restrict access for remote domain-joined clients is challenging because these endpoints require significant resources.
So, if your managed endpoints are primarily domain-joined and depend on pre-logon network connectivity, Always On VPN remains the more mature and feature-complete choice today.
Why Entra Private Access is Ideal for Native Entra ID Joined Devices
Entra Private Access is designed around a cloud-first, identity-centric Zero Trust model and has explicit client and device requirements that align best with Entra ID joined devices.
Client Requirements
The Global Secure Access client required for Entra Private Access requires Windows devices to be Microsoft Entra-joined or Microsoft Entra hybrid-joined. Domain-joined only (non-hybrid) devices are not supported. Unlike the native VPN client built into Windows, the Global Secure Access client is a separate piece of software that administrators must install independently.
Per-App Zero Trust
Entra Private Access controls access using FQDNs or IPs (individual, ranges, or networks) and specific protocol/port combinations instead of full network routing. Per-app access aligns with the modern cloud-native device model by avoiding broad network exposure and evaluating every access request through Conditional Access (including device compliance, MFA for legacy protocols, and more). Unlike Always On VPN, the principle of least privilege is enforced at all times.
Simplified Management
Entra Private Access requires minimal on-premises supporting infrastructure. There’s no need for VPN servers, RADIUS servers, or complicated certificate services for VPN authentication. Entra Private Access natively uses Entra ID and Conditional Access, eliminating the need for certificate authentication.
Cross Platform
Entra Private Access provides cross-platform support. Not only does it support Windows clients (Enterprise or Professional editions), but it also supports macOS, iOS, and Android. Broad client support makes Entra Private Access a comprehensive, secure remote access solution for all your managed endpoints.
In summary, Entra Private Access provides a cleaner, more secure, and lower-management experience for organizations moving toward Entra ID joined device fleets, especially when combined with Microsoft Intune for management and Conditional Access policies for enhanced security.
Licensing
Always On VPN and Entra Private Access use different licensing models.
Always On VPN
No per-user or per-device licensing required for Always On VPN. Always On VPN licensing is included with the Windows operating system license you already own.
Entra Private Access
Entra Private Access requires a separate license and incurs an additional per-user cost. It is included with the Microsoft Entra Suite license (~$12.00/user/month), or as a separate, standalone Entra Private Access license (~$5.00/user/month). You can learn more about Microsoft Entra licensing here.
Migration Path
Migrating from Always On VPN to Entra Private Access is low-risk. Using a phased approach, administrators can move from Always On VPN to Entra Private Access with minimal disruption. Start by planning for Entra Private Access (client agent deployment, connector placement, conditional access policies, etc.), then gradually deploy the solution, initially coexisting with Always On VPN but moving toward full deployment. Once complete, decommission the legacy VPN. Key steps include:
Assess your resources, devices, and Entra ID licensing.
Enable Entra Private Access, deploy one or two Private Network Connectors on-premises, and install the Global Secure Access client on devices.
Configure access rules. Begin with Quick Access to replicate VPN-like behavior.
Run both solutions side-by-side. Pilot with a small group, migrate apps/users incrementally, and enforce Conditional Access (including MFA for sensitive applications).
Phase out and decommission Always On VPN once stable.
This approach reduces infrastructure overhead, delivers granular zero trust security, and aligns with a cloud-first identity strategy.
Summary
Microsoft Always On VPN provides reliable on-premises remote access for Windows devices using protocols such as IKEv2 and SSTP. Today, it remains the best choice for environments that use traditional Active Directory domain-joined devices, where pre-logon connectivity and broad network access are required. However, Always On VPN requires heavy infrastructure and typically grants risky full network access.
Entra Private Access is the preferred solution for organizations adopting a cloud-first, Zero Trust strategy with Entra ID joined endpoints. Its per-application access model, native Conditional Access enforcement, reduced infrastructure footprint, and cross-platform support make it ideal for modern managed endpoints where least-privilege access and simplified operations are priorities.
In practice, many organizations will benefit from running both solutions in parallel during a transition period, using Always On VPN to support domain-joined endpoints and Entra Private Access for modern, Entra-joined devices. Over time, as device fleets and applications modernize, Entra Private Access can progressively replace legacy VPN infrastructure while improving security posture and reducing operational complexity.
Ready to Modernize Your Remote Access Strategy?
Schedule a free one-hour consultation to review your current Always On VPN deployment, assess readiness for Entra Private Access, and identify a secure, practical migration path tailored to your environment. We’ll cover architecture considerations, device requirements, licensing implications, and common pitfalls—no obligation required. Fill out the form below to request more information and schedule your free consultation.
I’m very excited to announce that I will be attending the annual Techmentor Conference at the Microsoft HQ campus in Redmond, Washington, this year. The event takes place August 11-15, 2025. The Techmentor Conference is one of my favorite IT pro conferences because it offers unparalleled access to experts worldwide. I will deliver two presentations at this year’s event. I hope you’ll join me!
Entra Private Access
On Tuesday, August 12, 2025, I will be presenting a session on Zero Trust Network Access with Microsoft Entra Private Access. ZTNA is the future of remote access and provides many security and operational benefits over traditional client-based VPN technologies.
On Wednesday, August 13, 2025, I’ll discuss Simplified Certificate Management with Microsoft Cloud PKI for Intune. As organizations integrate cloud-native devices in their environments, administrators must solve the problem of issuing and managing certificates for users and devices that are not domain-joined. Cloud PKI for Intune is an excellent solution that provides deployment flexibility to address these unique and specific requirements.
Registration for the event is open now. Use the promo code HICKS and receive $500.00 off the price of admission. Don’t miss this excellent opportunity to learn from the best. Register today!
Recently, I wrote about Microsoft Always On VPN and Entra Conditional Access and how conditional access improves your organization’s security posture by making policy-based access decisions based on various signals such as user identity, location, device compliance, platform, sign-in risk, and more. In this post, I’ll provide step-by-step instructions for integrating Entra Conditional Access with existing Always On VPN deployments.
Requirements
To use Microsoft Entra Conditional Access with Always On VPN you must have Entra ID P1 at a minimum. To use advanced features such as risk-based policy assessment, you must have Entra ID P2. In addition, all endpoints must be under Intune management; either native Entra ID joined, or hybrid Entra ID joined.
Enable VPN Support
To begin, open the Microsoft Entra admin center (https://entra.microsoft.com/), navigate to Identity > Protection > Conditional Access, and perform the following steps.
Click VPN Connectivity.
Click New certificate.
From the Select duration drop-down list, choose an appropriate certificate validity period.
Click Create.
Once complete, click Download certificate and copy the certificate file to a domain-joined system on-premises.
Publish Certificate
Next, administrators must publish the Entra VPN root certificate in Active Directory to support domain authentication. Open an elevated PowerShell or command window and run the following commands.
certutil.exe -dspublish -f <path to certificate file> RootCA
certutil.exe -dspublish -f <path to certificate file> NtAuthCA
Note: You must be a domain administrator to perform this task.
Conditional Access Policy
Navigate to Identity > Protection > Conditional Access and click Policies, then perform the following steps to create a conditional access policy for VPN access.
Click New Policy.
Enter a descriptive name for the new policy.
Click the link in the Target resources section.
From the Select what this policy applies to drop-down list, select Resources (formerly cloud apps).
In the Include section, choose Select resources.
Click the link in the Select section.
Enter VPN in the search field.
Check the box next to VPN Server.
Click Select.
Click the link in the Grant section.
Select Grant access.
Check the box next to Require device to be marked as compliant.
Click Select.
On the Enable policy slider, select On.
Click Create.
NPS
Changes to Network Policy Server (NPS) policy and configuration are required to support Always On VPN with Entra Conditional Access.
NPS Policy
To update the Always On VPN network policy to support Entra Conditional Access, open the NPS management console (nps.msc), expand Policies, then select Network Policies and perform the following steps.
Right-click on the Always On VPN policy and choose Properties.
Select the Settings tab.
Select Vendor Specific in the RADIUS Attributes section.
Click Add.
Select the Allowed-Certificate-OID attribute.
Click Add.
Click Add.
Enter 1.3.6.1.4.1.311.87 in the Attribute value field.
Click Ok.
Click Ok.
Click Close.
Click Ok.
Important Note: This change will block new Always On VPN user tunnel connections until you update the client configuration. When integrating an existing Always On VPN implementation with Entra Conditional Access, consider creating a new NPS policy and corresponding security group to migrate users to conditional access seamlessly.
NPS Configuration
By default, NPS will perform revocation checks for certificates used for domain authentication. However, Entra Conditional Access uses short-lived certificates (one-hour lifetime) that do not include CRL Distribution Point (CDP) information. Therefore, administrators must change the NPS server configuration to disable revocation checking for certificates lacking this information.
To do this, open the registry editor (regedit.exe) and create a new registry key with the following settings.
Once complete, the server must be rebooted for the change to take effect.
Client Configuration
After making all required changes to the supporting infrastructure, you must also update the Always On VPN client configuration to leverage Entra Conditional Access. Changes to client configuration vary depending on the method used to deploy and manage Always On VPN client configuration settings.
Intune
When using Microsoft Intune and the native VPN policy type to deploy and manage Always On VPN client configuration settings, perform the following steps to update the VPN configuration to include Entra Conditional Access support.
Click Enable next to Conditional access for this VPN connection.
Click Enable next to Single sign-on (SSO) with alternate certificate.
Enter Client Authentication in the Name field.
Enter 1.3.6.1.5.5.7.3.2 in the Object Identifier field.
Enter the organization’s root certification authority (CA) certificate thumbprint in the Issuer hash field.
XML
When using a custom XML configuration file for Always On VPN client configuration settings deployed using Intune or PowerShell, edit the XML file, remove the existing <TLSExtensions></TLSExtensions> section, and replace it with the following.
In addition, add the following code between the <VPNProfile></VPNProfile> tags after <TrustedNetworkDetection>.
Note: You will find a sample XML configuration file you can copy and paste from on GitHub here.
DPC
When using Always On VPN Dynamic Profile Configurator (DPC) for managing Always On VPN client configuration settings, open the DPC group policy and navigate to Computer Configuration > Policies > Administrative Templates > DPC Client > User Tunnel Settings > Advanced and perform the following steps.
Following the guidance in this post to integrate Entra Conditional Access with Always On VPN can significantly improve your organization’s security posture. In the example above, the conditional access policy is a basic one. Yet, it dramatically reduces the attack surface for your remote access infrastructure by ensuring only compliant devices can establish a VPN connection.
Administrators can use advanced conditional access policy settings to strengthen the VPN’s security further by performing additional checks, such as requiring strong, phishing-resistant credentials and requesting multifactor authentication (MFA) for risky sign-ins.
Microsoft recently introduced Entra Private Access, an identity-centric Zero Trust Network Access (ZTNA) solution to provide secure remote access to on-premises resources. With Entra Private Access, administrators can leverage Entra Conditional Access to enforce policy-based access control for network access. However, Entra Private Access isn’t for everyone. It does not provide full feature parity with Always On VPN, and there are also licensing considerations. However, for those organizations using Always On VPN, the good news is that you can integrate Entra Conditional Access with Always On VPN today to gain some of the security benefits it provides.
Conditional Access
Microsoft Entra Conditional Access is a security feature that enables administrators to create and enforce policies that specify how users can access resources. In the specific case of Always On VPN, conditional access is critical to ensuring legitimate access to authenticated users on authorized devices.
Signals
Conditional access policies use a wide variety of signals for policy enforcement, such as:
User Identity: Who is making this access request?
User Properties: Is this user a member of a specific group?
Location: Where is this access request originating?
Device Management: Is this device joined to Entra ID?
Device State: Is this device compliant with security policies?
Device Platform: Is this a Windows device?
Risk Level: Is this login considered risky?
Access Control
Based on these signals, administrators can design a conditional access policy to enforce granular access control, such as:
Enforce specific authentication types (e.g., phishing-resistant credentials)
Allow access only from specific device platforms (e.g., Windows only)
Require Entra hybrid-joined device
Block access when a device is not compliant with security policies
Always On VPN
Entra Conditional Access works with Always On VPN by issuing a special, short-lived user authentication certificate once the user has been authorized. The Always On VPN infrastructure can be configured to use this certificate to grant access to the VPN. Integrating conditional access with Always On VPN can significantly improve the security posture of organizations using this feature.
Are you ready? In just a few short weeks(!) Microsoft will release the February 2025 security updates. This is a critical update because Microsoft plans to enable full enforcement of strong certificate mapping on Active Directory Domain Controllers (DCs) with this release. Administrators unprepared for this may incur outages for workloads using certificate-based authentication such as Always On VPN, Wi-Fi, and others.
Microsoft introduced strong certificate mapping with the May 2022 update KB5014754 to address vulnerabilities identified with certificate-based authentication. The update makes changes to Active Directory Certificate Services (AD CS) certification authorities (CAs) to embed the principal’s Security Identifier (SID) on issued certificates with a new certificate extension. The update also changes domain controller behavior to monitor and optionally enforce strong certificate mapping for authentication.
Enforcement Mode
When first introduced, the update is configured in compatibility mode. If a certificate that isn’t strongly mapped is presented for authentication, an event is recorded in the event log indicating that. Microsoft has been planning for years to enable full enforcement. After many delays, that time is now upon us. Specifically, full enforcement for strong certificate mapping will be enabled by default on DCs after applying the February 2025 security updates.
Note: Administrators can switch back to compatibility mode for now. See below for more details.
Limitations
Initially, the strong certificate mapping update was applied only to online certificate templates. Specifically, those templates are configured to build the subject name from Active Directory information. However, offline templates, where the subject name is supplied in the request, do not include this information by default. Crucially, any certificate issued with Microsoft Intune with PKCS or SCEP uses offline templates and is not strongly mapped. The lack of strong certificate mapping options for Intune-issued certificates forced Microsoft to delay its full enforcement deadline until these limitations were resolved.
Updates
In October 2024, Microsoft Intune announced support for strong certificate mapping for PKCS and SCEP certificates. Administrators can now configure these certificates to include strong certificate mapping. However, administrators must take action to affect this change.
PKCS
To enable strong certificate mapping for PKCS certificates, administrators must ensure that the certificate connector is running at least version 6.2406.0.1001. In addition, the following registry key must be configured on the connector server.
The Intune Certificate Connector server must be restarted for this change to take effect. No changes are required on the PKCS certificate policy in Intune.
SCEP
To enable strong certificate mapping for SCEP certificates, administrators must add the following attribute/value pair to the Subject alternative name settings on their existing Intune SCEP certificate policy.
Attribute: URI Value: {{OnPremisesSecurityIdentifier}}
Preparation
Administrators using certificate-based authentication against on-premises Active Directory should ensure all user and device authentication certificates include embedded SID information. For certificates issued on-premises, with Intune using PKCS or certificates issued by Entra Conditional Access, the certificate should now have the extension 1.3.6.1.4.1.311.25.2, including the principal’s SID.
SCEP certificates issued using Intune will include the following information in the Subject Alternative Name field.
URL=tag:microsoft.com,2022-09-24:sid:<sid>
Note: This applies to certificates issued using Cloud PKI for Microsoft Intune as those certificates are deployed using a SCEP device configuration policy.
Opt-Out
With the February 2025 security update, all domain controllers will be switched to full enforcement mode. Authentication requests using certificates without strong mapping will be denied in this configuration.
If your organization is not prepared to move to full enforcement mode, the February 2025 update allows administrators to opt out and switch back to compatibility mode by enabling the following registry key on all domain controllers.
Administrators are strongly encouraged to update all user and device authentication certificates before September 2025. With the September 2025 security update, Microsoft will no longer honor the opt-out registry settings and strictly enforce strong certificate mapping for all certificate-based authentication requests.
Troubleshooting
Certificate authentication is commonly used for Always On VPN and Wi-Fi authentication. If full enforcement mode is enabled on domain controllers and a certificate is presented for authentication that is not strongly mapped, administrators may see the following event log information recorded on the Network Policy Server (NPS).
Network Policy Server denied access to a user.
The details of the event include the following.
Reason Code: 16 Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.
Obviously, the user does not enter their password when using certificates for authentication. However, the indication of a credential mismatch can be caused by missing strong certificate mapping information when the DC is in full enforcement mode.
Note: There are other causes for reason code 16 failures on NPS. Further investigation may be required to determine the root cause.
With the October 2024 Intune update, Microsoft introduced support for strong certificate mapping for certificates issued by Intune via the Intune Certificate Connector. Enabling strong certificate mapping support in Intune is an important change for those organizations using Microsoft Intune to issue and manage certificates for their users and devices, as it resolves a critical implementation blocker.
Note: This post was updated to clarify that adding the {{OnPremisesSecurityIdentifier}} for PKCS certificates is not required. This variable is only used for SCEP certificates.
Background
In May 2022, Microsoft released security update KB5014754, which added functionality to domain controllers and enterprise issuing certification authority (CA) servers, allowing the Kerberos Key Distribution Center (KDC) to enforce strong certificate mapping. Specifically, with KB5014754 installed, issuing CAs now add the requesting principal’s Security Identifier (SID) to the certificate in a new certificate extension. Domain controllers can be configured to reject authentication requests using certificates that do not include this information.
Today, DCs with KB5014754 installed will still allow authentication without strong certificate mapping. However, Microsoft has stated they will begin enforcing strong certificate mapping in February 2025, with an option to disable it via the registry. Starting in September 2025, full enforcement will be mandatory.
The initial changes in KB5014754 applied only to online certificate templates, meaning those that build the subject name from Active Directory. However, deploying certificates with Intune using either PKCS or SCEP requires using an offline certificate template that allows the requestor to supply the subject name in the request. When using offline templates, a certificate is issued but does not embed the SID in the certificate. Using offline templates presents unique challenges to organizations moving to modern management with Intune and Entra ID.
Intune Changes
The October 2024 Intune update addresses this limitation by providing a method to include SID information in certificates using either SCEP or PKCS.
SCEP
To include the SID information in SCEP certificates, create or edit an existing SCEP device configuration policy and define a URI Subject Alternative Name (SAN) attribute with the value {{OnPremisesSecurityIdentifier}} as shown here.
PKCS
To include SID information in PKCS certificates, administrators must ensure the Intune Certificate Connector is updated to at least version 6.2406.0.1001. In addition, a registry setting must be enabled on the Intune Certificate Connector server.
On the server where the Intune Certificate Connector is installed, open the registry editor, navigate to HKLM\Software\Microsoft\MicrosoftIntune\PFXCertificateConnector, and change the value of EnableSidSecurityExtension to 1.
Optionally, administrators can update this setting at the command line by running the following PowerShell command.
Once complete, restart the Intune Certificate Connector server for the changes to take effect.
Certificates
SID information is added to certificates differently depending on which Intune device configuration policy type is used.
PCKS
PKCS certificates have the SID embedded in the certificate extension 1.3.6.1.4.1.311.25.2, as shown here.
SCEP
SCEP certificates have the SID embedded in the Subject Alternative Name (SAN) field in the format “tag:microsoft.com,2022-09-14:sid:<SID>” as shown here.
Migration
When making these changes to embed the SID in Intune-issued certificates in an existing Intune PKCS or SCEP configuration policy, the change will only affect certificates issued after the change is made. To update all certificate holders, you must create and deploy a new device configuration policy to targeted users or devices. Deleting the old profile (or ensuring it no longer applies) will remove the old certificate from the endpoint. If you’ve configured your Intune Certificate Connector to support revocation, the old certificate will also be revoked.
Entra Conditional Access
Entra Conditional Access certificates have included SID information since July 2023. More details here.
Intune Cloud PKI
The changes above will also work with certificates issued by Cloud PKI for Intune.
Other Cloud PKI Providers
Many other Cloud PKI providers, such as SCEPman and KEYTOS, already include the embedded SID in their certificates. Other cloud PKI providers may also include embedded SID. Consult your provider to confirm.
