With public TLS certificate lifetimes set to drop to 200 days soon (next week!), Always On VPN and DirectAccess administrators face an increased risk of service disruption if certificates aren’t renewed on time. These shorter certificate lifetimes require more frequent renewals, substantially increasing management overhead. Although 200 days equate to roughly a twice-a-year renewal, lifetimes will decrease further to 100 days next year and eventually to just 47 days in 2029. SSTP and IP-HTTPS are TLS-based tunneling protocols used by Always On VPN and DirectAccess, respectively, tying their certificate health directly to remote access availability. Now is the time to automate the enrollment and renewal of Always On VPN SSTP and DirectAccess IP-HTTPS/TLS certificates to ensure reliable operation in the future.
Always On VPN
Previously, I wrote about using CertKit.io to automate the enrollment and renewal of public TLS certificates for Always On VPN. CertKit is an online service that administrators can use to delegate the task of enrolling for short-lived certificates from Let’s Encrypt. In that post, I shared some sample code to retrieve the certificate from CertKit and assign it to the SSTP listener for the Routing and Remote Access Service (RRAS). However, CertKit added new features to its solution, eliminating the need for additional code.
CertKit Agents
Recently, CertKit introduced CertKit Agents. These lightweight software agents are installed on Windows Servers (other operating systems are supported as well) to automate the process of downloading CertKit certificates and installing them in the local computer certificate store. Importantly, they now specifically support both the Always On VPN (SSTP) and DirectAccess (IP-HTTPS) workloads natively.
Always On VPN
The CertKit agent automatically detects the Routing and Remote Access (RRAS) workload and updates the certificate binding for the SSTP listener accordingly. Since this process requires a service restart, which terminates all current VPN connections, CertKit allows you to select an outage window for certificate updates.
Here, administrators can define the day(s) and time window during which the agent is authorized to restart the RemoteAccess service when updating the TLS certificate for SSTP. The day and time are based on the server’s configured time zone settings.
DirectAccess
Beginning with CertKit agent v1.6.2, the agent automatically detects whether DirectAccess is configured, enabling IP-HTTPS TLS certificates to be automatically enrolled and renewed. However, additional configuration is required. The following changes must be made to support CertKit for DirectAccess.
Service Account – Administrators must configure a service account in Active Directory for the CertKit agent. A Group Managed Service Account (gMSA) is preferred, but a standard domain service account is also supported.
GPO Delegation – CertKit service account must be delegated the ‘Edit settings, delete, and modify security’ permission on the DirectAccess server and client settings GPOs.
Log On as a Service – When using a domain service account, administrators must grant the CertKit service the ‘Log on as a service’ right on the DirectAccess server. However, when using gMSA, the ‘Log on as a service’ right is not required.
Local Administrator – Administrators must also add the CertKit agent service account to the Local Administrators group on the server.
Configuration Script
I have published a PowerShell script to simplify configuring the CertKit agent on DirectAccess servers. The script automatically performs all required tasks for the CertKit agent to work with DirectAccess. You will find the Enable-DACertKit.ps1 PowerShell script on GitHub. Alternatively, you can install the script directly from the PowerShell Gallery.
After installing the CertKit agent, run the PowerShell script to complete the configuration. Next, authorize the agent in the CertKit management portal and assign a certificate. Once complete, CertKit can fully manage the IP-HTTPS TLS certificate for DirectAccess.
Note: Like Always On VPN, changes to the DirectAccess IP-HTTPS certificate require a service restart, which is disruptive. Be sure to define a maintenance window (as shown previously) to ensure the change is made during non-peak times.
Summary
As TLS certificate lifecycles continue to shrink, automating certificate enrollment and renewal has become essential for both Always On VPN and DirectAccess environments. CertKit agents streamline this process by automatically retrieving, installing, and binding certificates for SSTP and IP-HTTPS, all while supporting scheduled outage windows to minimize disruption. With these new capabilities, administrators can significantly reduce operational overhead and ensure consistent, reliable remote access services without manual intervention. Visit CertKit.io to get started today.
More Information
If you would like to learn more about CertKit or see a demonstration with Always On VPN or DirectAccess, fill out the form below, and I’ll provide you with more details.
Certificate templates in Microsoft Active Directory Certificate Services (AD CS) provide powerful, preconfigured settings that enable administrators to issue certificates tailored for specific purposes. For example, a certificate template could allow a user to authenticate to a Wi-Fi network or VPN gateway. Another template might control policies for enrolling for web server certificates in the enterprise. Templates define settings such as cryptographic parameters (key algorithm and length), validity period, application policies, enrollment requirements, and more. While there are myriad settings to choose from, one in particular is often enabled unnecessarily. And while it works without issue, there can be some hidden downsides to enabling this setting.
Publish Certificate in Active Directory
When creating a certificate template, there’s an option on the General tab called Publish certificate in Active Directory. From experience, this is one of the most misunderstood settings for certificate templates.
Intuitively, it would make sense to check this box on all published certificate templates. After all, I want the users or devices targeted by this certificate template to find them in Active Directory (AD) so they can enroll. Many administrators believe that enabling this setting is required to ‘see’ the published certificate template on the endpoint, as shown here.
However, enabling the Publish certificate in Active Directory option is not required for enrollment. To ‘see’ certificates available for enrollment, the user or device must only have the Enroll permission on the template.
What Is It For?
So, what does the Publish certificate in Active Directory setting do? When this option is enabled, the issuing CA adds the certificate to the requesting principal’s Active Directory account. There are two common scenarios where this is required.
S/MIME
Adding a user’s certificate to their AD account makes the public key centrally discoverable, allowing Outlook and other S/MIME-enabled clients to automatically find recipients’ certificates for secure email encryption and signature validation. Without the certificate published in AD, users must manually exchange certificates, breaking seamless S/MIME encryption in most enterprise environments.
Encrypting File System (EFS)
Publishing a user’s EFS certificate to their Active Directory account allows Windows to locate the correct public key automatically when encrypting files. It ensures recovery agents and key archival processes function properly. Without the certificate in AD, EFS can fail to encrypt data consistently across machines or prevent access to encrypted files when users roam or recover profiles.
Drawbacks
There are very few scenarios outside of S/MIME and EFS that require the Publish certificate in Active Directory option to be enabled. However, enabling it doesn’t necessarily break anything, and this setting is often enabled by default (or carried over from the source template when duplicating), so administrators may miss this option. Issuing certificates in this way introduces some potential problems.
AD Database Bloat
Adding a certificate to each principal’s AD object increases the size of each object, thereby increasing the total size of the AD database. For organizations with large directories with hundreds of thousands or even millions of accounts, adding unnecessary data to each account can be very expensive in terms of database size, replication traffic, backup storage, and overall domain performance. Making matters worse, certificates published to AD live perpetually. They are not removed automatically when certificates are revoked or expire.
Service Accounts
Service accounts used for certificate enrollment, such as the Microsoft Intune Certificate connector, can be especially challenging. Here, if the Publish certificate in Active Directory setting is enabled on the Intune certificate template, the CA will add a certificate to the service account for every certificate it issues. While you can have many certificates associated with a single account, there is an upper limit, approximately 1250, based on my testing. After that, certificates will continue to be issued, but adding them to AD will fail.
Remediation
The following recommendations can help administrators correct this misconfiguration and limit its impact in their environment.
Disable Unnecessary Certificate Publishing
Administrators should clear the Publish certificate in Active Directory setting on all certificate templates that do not explicitly require it, such as those used for S/MIME or Encrypting File System (EFS). This prevents new certificates from being written to user or computer objects and does not require certificates to be reissued.
Remove Published Certificates
Administrators can remove unnecessary certificates from user, computer, and service account objects in AD to reduce object and overall AD database sizes. Perform the following steps to remove unneeded certificates.
Open the Active Directory Users and Computers management console (dsa.msc) and double-click the target principal.
Select the Published Certificates tab.
Select a certificate (or all certificates) and click Remove.
Important Note: Use extreme caution when deleting certificates! Do not delete any certificates unless you are certain they are not required.
Managed Service Accounts
Managed Service Accounts in AD do not have a Published Certificates tab. Administrators can use the Attribute Editor to remove individual certificates from the userCertificate attribute on the account.
Managed Service Account Attribute Editor
Managed Service Account userCertificate Entries
Unfortunately, there is no option to view the certificate in the UI for Managed Service Accounts. To view detailed certificate information, see the PowerShell section below.
Existing Certificates Are Not Removed Automatically
Disabling the Publish certificate in Active Directory setting only stops future certificates from being published in AD. Certificates already written to Active Directory are never removed automatically, even after they expire or are revoked. In environments where this setting has been enabled for an extended period, large numbers of stale certificates often accumulate and continue to increase the AD database size.
Intune Certificate Connector Considerations
This issue is especially problematic for high-volume enrollment scenarios that use service accounts, such as the Microsoft Intune Certificate Connector. When publishing is enabled for Intune certificate templates, certificates issued on behalf of users are added to the service account, quickly leading to excessive certificate accumulation and potential attribute limits.
ADPrincipalCertificate PowerShell Module
Manually performing this cleanup at scale is impractical. To assist administrators with cleaning up unnecessarily published certificates, I’ve created the ADPrincipalCertificate PowerShell module. This module includes functions to enumerate AD accounts that include certificates, show and optionally export certificates for AD accounts, and remove published certificates. The module also includes a function to enumerate published certificate templates that include the Publish certificate in Active Directory option enabled. You can install the ADPrincipalCertificate PowerShell module from the PowerShell gallery by running the following command.
While the Publish certificate in Active Directory option is helpful for S/MIME and EFS deployments, it is unnecessary for most other scenarios and is often enabled when it isn’t needed. This results in the unnecessary addition of certificates to AD accounts, causing individual objects and the entire AD database to grow without benefit. Sadly, many vendor guides indicate that this setting is required when it often isn’t, so many environments suffer from this misconfiguration. Administrators should review the certificate template configuration and disable this setting when it isn’t needed. Additionally, use the ADPrincipalCertificate PowerShell module to perform cleanup, if required.
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.
