DirectAccess to Always On VPN: Plan the Exit From a Deprecated Feature

DirectAccess still connects thousands of domain-joined laptops to corporate networks, but Microsoft has deprecated it and says it will be removed in a future version of Windows Server, so every organisation using it needs an exit plan before the platform makes the decision for them. Deprecation is not an outage: DirectAccess remains supported for the lifecycle of the Windows Server releases that include it, Windows Server 2025 among them. The risk is drifting into an emergency migration when a server refresh, a Windows client change or an audit forces the issue. This guide covers the official status, how to find every DirectAccess client and server, how to design Always On VPN as the like-for-like replacement (device and user tunnels, IKEv2, certificate authentication, NPS and Intune), how to run both side by side, and when to skip VPN and move straight to zero trust network access such as Microsoft Entra Private Access. It is written for network, endpoint and identity engineers who own remote access. General VPN hardening is covered in the VPN Security Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Deprecated, not removed. Microsoft announced the deprecation in June 2024; its support article (KB 5103659) says DirectAccess stays available and supported for each release's lifecycle but is not recommended for new deployments, with no removal date given.
• Always On VPN is Microsoft's named replacement. A device tunnel restores the pre-logon connectivity DirectAccess gave; a user tunnel carries user traffic, with IKEv2 and SSTP fallback.
• Certificates are the real project. Machine certificates for the device tunnel, user certificates for EAP-TLS or PEAP-TLS, and a VPN server that only accepts certificates from your own root CA.
• Run side by side and migrate in rings. Microsoft's migration overview builds a parallel Always On VPN service and removes devices from the DirectAccess security group as each ring moves.
• Decide on ZTNA before you buy VPN capacity. If most access is to a known set of internal apps and devices are moving to Entra join and Intune, per-app access through ZTNA may be a better destination than a new VPN.

What is changing and why

DirectAccess, introduced with Windows 7 and Windows Server 2008 R2, gives domain-joined Windows devices automatic, always-on connectivity to the corporate network without the user starting a VPN. It relies on IPsec over IPv6, IPv6 transition technologies (IP-HTTPS, Teredo, 6to4), a Network Location Server to detect when the device is inside the network, the Name Resolution Policy Table (NRPT) and Group Policy for configuration.

Microsoft's support article explains why it is being retired: DirectAccess was built for on-premises, domain-centric environments and depends on IPv6 transition mechanisms and Group Policy management. Organisations moving to cloud identity, Intune management and Entra-joined devices find those dependencies a poor fit, and Windows' own deprecated features list also includes the IPv6 transition technologies DirectAccess leans on.

Official timeline and current status

Status below is as stated on Microsoft's pages, checked on 8 November 2026.

The support article lists Windows Server 2012 and 2012 R2 (ESU), 2016, 2019, 2022, version 23H2 and 2025 as releases in scope. Because removal has no date, the practical deadlines are your own: the end of support of the Windows Server version hosting DirectAccess, any client build that drops it, and the point at which devices leave the on-premises domain.

Who and what is affected

• DirectAccess servers: Remote Access role servers, load-balanced clusters and multisite deployments, plus their Network Location Server and DNS records.
• Clients: domain-joined Windows devices in the DirectAccess client security group with the DirectAccess client GPO applied.
• Management traffic: manage-out scenarios where helpdesk and patching tools reach remote devices, which DirectAccess provided through its infrastructure tunnel.
• PKI: certificates for IP-HTTPS, Network Location Server and computer authentication, often issued years ago by an AD CS deployment nobody has reviewed since. See the AD CS Security Guide.
• Machine identities: every client authenticates with a computer account and machine certificate. These are non-human identities; their issuance, renewal and revocation process moves to the new design.

Finding affected systems and identities

1. Servers: list servers with the Remote Access role and DirectAccess configured; record Windows Server version, end of support date, multisite and load-balancing setup, and public names.
2. Clients: export members of the DirectAccess client security groups and the computers in scope of the DirectAccess client GPO. Cross-check with Configuration Manager or Intune inventory, and use the Remote Access Management console's client statistics to see which devices actually connect.
3. On a client: the DirectAccess PowerShell cmdlets (for example Get-DAConnectionStatus) and netsh namespace show policy for NRPT entries confirm whether DirectAccess is configured and active.
4. Applications and flows: identify which internal servers remote users and management tools reach, including manage-out targets. This list becomes the route and traffic filter design for the device tunnel, or the app list for ZTNA.
5. Certificates and identities: list certificate templates and CAs used for DirectAccess, auto-enrolment settings and expiry dates, and the computer accounts in scope. Remove stale computer objects before migration so they do not inherit new access.

Migration options

Option 1: Always On VPN

Microsoft's migration overview needs a new Remote Access server on Windows Server 2016 or later (or a compatible third-party IKEv2 gateway) alongside the existing DirectAccess service. The design has two independent profiles that can be connected at the same time.

• Server side: on RRAS, enable "Allow machine certificate authentication for IKEv2" and use Set-VpnAuthProtocol -RootCertificateNameToAccept so only certificates chaining to your private root CA are accepted, or remove public CAs from the server's trusted root store. Otherwise any certificate from a publicly trusted CA with the right usage could authenticate.
• NPS: user tunnel authentication typically goes through Network Policy Server as RADIUS, where network policies restrict access by group and certificate. The NPS extension for Microsoft Entra multifactor authentication adds MFA.
• Conditional Access: Microsoft Entra Conditional Access can require MFA or device compliance and then issues a short-lived certificate (60 minutes by default) for the VPN connection; NPS can require the Conditional Access OID 1.3.6.1.4.1.311.87 in the client certificate so only compliant devices connect.
• Triggers: Always On, trusted network detection (suppresses the VPN on the corporate network, replacing the DirectAccess Network Location Server role), and app or name-based triggers.
• Ports: IKEv2 uses UDP 500 and 4500; SSTP uses TCP 443. Open only these on the edge to the VPN servers.

Deploying with Intune

Intune deploys Always On VPN through a Windows VPN device configuration profile (VPNv2 CSP). Key settings: Connection type IKEv2, Always On Enable, Device tunnel Enable (requires IKEv2, Always On and Machine certificates; assign only one device tunnel profile per device), Authentication method EAP with EAP XML for the user tunnel, the IKE Security Association Parameters and Child Security Association Parameters to match the server (Windows 11 needs all or none configured), Register IP addresses with internal DNS for manage-out, Name Resolution Policy table (NRPT) rules, Split tunneling routes, Trusted network DNS suffixes and Conditional Access for this VPN connection. Without Intune, Microsoft documents deploying ProfileXML with the VPN_Profile.ps1 script, Configuration Manager, or the WMI Bridge provider MDM_VPNv2_01 class; the device tunnel must be configured in the LOCAL SYSTEM context. Certificate profiles (SCEP or PKCS) must deploy before the VPN profile; see the IoT and Device Certificate Provisioning (EST, SCEP) Guide.

Option 2: Go straight to ZTNA

Microsoft Entra Private Access publishes internal FQDNs and IP ranges through private network connectors, reached by the Global Secure Access client, with Conditional Access applied per app. Microsoft describes "Quick Access" as one shared set of tunnelled resources and per-app Global Secure Access apps for resources that need their own policies. Other ZTNA services follow a similar connector model. See the ZTNA Guide and the Secure Remote Access Beyond VPN Guide.

Decision guidance

• Choose Always On VPN when devices stay domain-joined, you rely on pre-logon connectivity and manage-out, many legacy protocols or broad subnets must be reachable, or you need the closest like-for-like replacement quickly.
• Choose ZTNA when devices are Entra-joined and Intune-managed, remote access is mostly to identifiable web and line-of-business apps, and you want per-app Conditional Access rather than network access.
• Combine them as a common middle path: Always On VPN device tunnel or cloud management for device servicing, ZTNA for user access to apps, with the user VPN retired later.
• Small organisations with a single DirectAccess server and few apps often find a ZTNA service simpler to run than new RRAS, NPS and PKI infrastructure.
• Large organisations with multisite DirectAccess usually move to Always On VPN first for continuity, then shift app groups to ZTNA.

Testing and rollback

1. Build the parallel service. Deploy VPN servers, NPS and certificate templates without touching DirectAccess. Test with lab devices outside the DirectAccess group.
2. Pilot ring (IT staff): deploy certificates, then the device tunnel, then the user tunnel. Confirm first logon without cached credentials, Group Policy refresh, patching and access to each critical app from home, hotel and mobile networks.
3. Coexistence check: devices in early rings may still hold DirectAccess policy; Microsoft's process is to remove a device from the DirectAccess security group once its VPN deployment is confirmed, so the two do not compete for name resolution.
4. Expand in rings by department or region, monitoring deployment success in Intune or Configuration Manager and helpdesk call volume.
5. Rollback: for any device, re-add it to the DirectAccess security group and remove the VPN profiles; DirectAccess remains running until the last ring is complete, which is the point of side-by-side.
6. Decommission: after every user has moved, remove the client configuration, DNS records and the Remote Access role, or decommission the servers and remove them from AD DS. Revoke or let expire the DirectAccess-specific certificates and remove their templates.

Risks of doing nothing

• Forced migration: the DirectAccess host OS reaches end of support or a future Windows release removes the feature, leaving a compressed migration with no pilot time.
• Stagnant security: deprecated features are no longer actively developed, and DirectAccess depends on IPv6 transition technologies Microsoft has also deprecated.
• Blocked modernisation: devices cannot move to Entra join and Intune-only management while remote access depends on Group Policy and domain membership.
• Exposed edge: external remote services are a primary initial access route (ATT&CK T1133 External Remote Services); an unloved, unpatched remote access server is exactly the system attackers look for. See the VPN and Firewall Log Detection Guide.

Detection and measurement

• Migration progress: devices with a successful VPN profile deployment versus devices still in the DirectAccess group; target zero remaining.
• Connection success rate: device and user tunnel connection success by network type, from RRAS and client event logs (RasClient events in the Application log).
• Authentication failures on NPS: NPS logs and Security log events 6272 (access granted) and 6273 (access denied) show certificate and policy failures.
• Compliance gating: share of VPN connections using the Conditional Access certificate.
• Helpdesk tickets for remote access per ring, compared with the DirectAccess baseline.
• Certificate health: machine and user certificates expiring in the next 30 days.

Alert on VPN authentication from certificates issued by unexpected CAs, connections from devices not in inventory, and successful logons from unusual countries.

Framework mapping

Practitioner checklist

• DirectAccess servers, client groups, GPOs and certificates are inventoried with owners and end of support dates.
• A target design (Always On VPN, ZTNA or both) is chosen against the decision criteria and approved.
• The VPN server accepts only certificates from your private root CA for IKEv2 machine authentication.
• Device tunnel traffic filters or routes limit it to infrastructure servers, with manage-out needs documented.
• User tunnel authentication uses certificates or Windows Hello for Business with MFA, through NPS policies scoped to groups.
• Conditional Access device compliance is enforced for VPN or per-app access.
• Migration rings are defined, with rollback by re-adding devices to the DirectAccess group.
• Metrics for deployment success, connection success and helpdesk volume are reported per ring.
• DirectAccess servers, DNS records, GPOs, certificate templates and stale computer objects are removed after the final ring.

Standards and references

• Microsoft Support: DirectAccess Deprecation on Future Windows Server Releases
• Microsoft Learn: Deprecated Features for Windows Client
• Microsoft Learn: DirectAccess to Always On VPN Migration Overview
• Microsoft Learn: Always On VPN Overview
• Microsoft Learn: Configure VPN Device Tunnels in Windows Client
• Microsoft Learn: Windows Device Settings to Add VPN Connections Using Intune
• Microsoft Learn: Learn About Microsoft Entra Private Access

Related NHI Mgmt Group resources: VPN Security Guide · ZTNA Guide · Remote Access Identity Guide · Machine Identity, PKI and Certificate Lifecycle Guide