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.
In early December 2025, Microsoft announced an update for the Entra Global Secure Access client. This latest release, v2.24.117, includes important changes that administrators will find helpful for efficient connectivity and enhanced troubleshooting.
Intelligent Local Access
The latest release of the Microsoft Entra Global Secure Access client adds support for Intelligent Local Access (ILA). ILA ensures optimal network connectivity when accessing published resources. ILA can detect when it is on a trusted network and send traffic directly to the resource, bypassing the cloud gateway to improve performance. Authentication and authorization are still required for application access regardless of location.
B2B Guest Access
B2B Guest Access, now in public preview, enables external partners to securely access an organization’s private resources using their own devices and home Microsoft Entra ID credentials, without credential duplication. Partners install the Global Secure Access client, sign in, and switch to the resource tenant, routing traffic via Private Access profiles for Conditional Access, MFA, and continuous evaluation. It supports BYOD and multitenant switching, requires guest user setup and specific client configurations in the resource tenant, and needs licensing only in the resource tenant. However, B2B Guest Access does not support Kerberos-based on-premises resources. More details here.
Traceroute
This latest release of the Entra Global Secure Access client also includes a new traceroute tool. GsaTracert.exe, located in the C:\Program Files\Global Secure Access Client\GSATracert\ folder, allows administrators to test connectivity to published resources and evaluate network response time and performance.
FQDN
Administrators can use GsaTracert.exe to validate connectivity to a resource using its fully qualified domain name (FQDN). When running the command, GsaTracert.exe reports the round-trip time (RTT) in milliseconds for each hop along the path, including the target resource. It will also indicate which point of presence (PoP) the client is currently connected to. The syntax to perform this test is:
In addition to testing an FQDN, administrators can test individual resources using a combination of IP address and port number. The syntax to perform this test is:
.\GsaTracert.exe --host <ip:port>
For example:
.\GsaTracert.exe --host 172.16.0.254:22
Application ID
In addition to FQDN and IP:Port, administrators can also supply the application ID to test. However, since an application can include multiple IP addresses and/or ports, the measurement for backend resources is omitted when using this option. The syntax to perform this test is:
Note: You can find the application ID for a published application by opening the Entra admin center and navigating to Global Secure Access > Applications > Enterprise Applications. The application ID will be displayed on the Overview page of the published Enterprise application.
Speedtest
Administrators can use the –speedtest switch with any of the combinations above to test the endpoint’s Internet performance. The results are for the connection to the public Internet, not to the published resource.
Additional Features
The following new features are designed to improve the user experience for Global Secure Access users.
Disable Private Access
Administrators can now use a registry setting to show the Disable button, allowing users to disable Entra Private Access. Disabling Private Access is helpful when a device is on the internal network, and the user prefers to access resources directly rather than through Global Secure Access.
View Account
The new Global Secure Access client now includes a View Account link to the user’s Microsoft Entra My Account website.
Summary
The Microsoft Entra Global Secure Access Client v2.24.117 introduces several valuable enhancements for administrators and users alike. Key highlights include Intelligent Local Access for optimized performance on trusted networks, public preview support for B2B Guest Access enabling secure external collaboration without credential duplication, and the new GsaTracert.exe traceroute tool for detailed network diagnostics. Additional improvements, such as the ability to disable Private Access via registry settings and quick access to the My Account portal, further streamline management and troubleshooting. These updates reinforce Microsoft Entra Global Secure Access as a robust solution for secure, efficient resource connectivity.
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.
