Being in consulting, I continue to see a lot of organizations that are still configuring their endpoints the same way they did 20+ years ago. They join the device to their on-prem domain. They deploy group policies. They utilize a VPN so group policies work when users are remote. And then IT admins pray that the hybrid device touches a domain controller often enough to not fall out of sync.

Now here’s the fun part:

You don’t need your devices bound to on-prem Active Directory anymore — even if you still rely on legacy applications and resources. Modern identity has evolved. Most devices haven’t.

With today’s Microsoft identity architecture, you can utilize pure Entra Joined devices, fully Intune-managed, cloud-native endpoints, while still maintaining seamless access to on-premises resources. This allows your organization to take advantage of all of the native device deployment and management capabilities using Autopilot and Intune, while still accessing legacy resources. It also creates a better end user experience! And perhaps, you can even move away from VPN too!

Let’s walk through how this works.

The status quo: hybrid joined devices

For years, and even still today, this is the common deployment model when organizations get a new device.

Join device to on-prem domain (AD DS)
Sync the identity and device objects to Entra ID via Entra ID Connect (EIDC)
Layer Intune on top, maybe with some compliance policies and a conditional access policy

But hybrid join comes with major drawbacks:

Devices still require line-of-sight to domain controllers
Split-brain management (GPO + Intune)
Domain join = larger attack surface and more lateral movement paths
VPN becomes a crutch to keep the device “in the domain”
Remote/hybrid work becomes unnecessarily complex

Hybrid join solved a past problem. However, it is not the architecture modern organizations should carry forward.

Pure Entra Join: the cloud-native endpoint

A pure Entra Joined device:

Joins only to Entra ID
Uses Intune as the authoritative management platform
Does not rely on domain controllers for authentication or policy
Eliminates the need for VPN for device management
Reduces attack surface and centralizes identity governance

The pushback is always the same:

“If my devices aren’t domain joined, how do they access file servers, legacy apps, and Kerberos-protected resources?”

Here is the answer:

Microsoft Entra ID Connect + Entra Kerberos gives Entra Joined devices the ability to request and use Kerberos tickets.

Which brings us to the technical walkthrough. Let’s take a look!

How Pure Entra Joined Devices Access AD DS Resources (Technical Walkthrough)

Here is a breakdown of the authentication flow.

Warning: This section is a bit technical.

Step 1: User signs in to a pure Entra Joined device

When the user logs into Windows using Entra ID credentials, the device receives:

A Primary Refresh Token (PRT) tied to the user
- The primary refresh token is the token for Entra ID that holds all the authorizations for that user and which applications it can access
A device-bound session key
Claims identifying device state, compliance, and user identity

This establishes cloud identity — not on-prem identity.

Step 2: Entra Kerberos issues a Cloud Ticket Granting Ticket (Cloud TGT)

Once authenticated, the device uses the PRT to request a Cloud TGT from Entra ID.

This Cloud TGT:

Is cryptographically mapped to the on-prem AD DS Kerberos realm
Identifies the user in a way AD DS trusts
Is signed using keys synchronized via Entra ID Connect

No domain join required.
No Group Policy required.

Step 3: The device redeems the Cloud TGT with the on-prem domain controller

This is the key part.

The device presents the Cloud TGT to an on-prem AD DS Domain Controller.
The Domain Controller validates the ticket using keys synchronized by Entra ID Connect.

If it checks out, the DC issues a traditional Kerberos Ticket Granting Ticket (TGT) for the user — the same TGT the user would have received if they were on a domain-joined machine.

This allows the user to authenticate to:

File servers
SQL servers
Print servers
On-prem applications using Kerberos
Anything relying on AD DS integrated auth

Step 4: User accesses legacy on-prem resources

Once the device holds a valid AD DS Kerberos TGT, it can obtain service tickets (TGS) from the domain controller for the resource the user is trying to reach.

From there, everything works exactly as if the user were on a domain-joined machine.

The only requirement:
The device must have network connectivity to the resource or a secure tunnel that reaches it.

This is the part many organizations overlook:

You may still need VPN or secure network path for the resource — but you no longer need VPN for device management or identity.

Domain join becomes unnecessary.
VPN becomes optional instead of mandatory.

Read more here: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune

VPN is no longer required for management — only for resource access

So now that we have the device setup to access on-prem resources using Kerberos, let’s take a look at VPN.

With a pure Entra Joined model, devices no longer depend on domain controllers to stay healthy, receive policies, or validate trust. Intune becomes the single source of truth for configuration, compliance, and application deployment. This means a device can be fully managed, secured, updated, and governed from anywhere in the world with an internet connection—no VPN required.

However, depending on the environment, users may still need a network path to reach certain legacy resources. A Windows file server sitting behind a firewall or a custom on-premises application protected by Kerberos still requires line-of-sight from the device. In these cases, a VPN or private access mechanism is still necessary, but only for actual resource access—not for ongoing device management or authentication to Entra ID.

This distinction becomes a major turning point for organizations. The VPN shifts from a permanent requirement (“I need VPN so Group Policy works”) to an occasional tool used only when a user needs to access something that hasn’t moved to the cloud yet. It significantly reduces operational friction and greatly improves the remote user experience.

With pure Entra Join:

Intune manages the device anywhere
Conditional Access governs the trust of identity + device
Policies, apps, and configurations flow over the internet
WHfB delivers phishing-resistant authentication
No DC line-of-sight is required for the device to remain functional

A VPN may still be required temporarily for:

Accessing on-prem file servers
Reaching legacy application endpoints
Connecting to resources behind firewalls

But VPN is no longer required to maintain domain membership or apply device policy — because domain join is gone.

Read more here: https://learn.microsoft.com/en-us/entra/identity/devices/device-join-plan

Global Secure Access as a VPN alternative

This is where things become truly modern and Zero Trust aligned. Instead of using a legacy VPN, organizations should start to adopt Global Secure Access, Microsoft’s Security Service Edge (SSE) solution.

For organizations looking to modernize beyond traditional VPNs, Microsoft Global Secure Access introduces a Zero Trust approach to reaching internal applications. Instead of tunneling devices directly onto the internal network, GSA provides application-level connectivity that is identity-aware, device-aware, and conditional-access-driven.

This means access is granted based on who the user is, whether the device is compliant, what the risk level is, and what specific resource the user is allowed to reach. There is no broad network exposure, no implicit trust, and no reliance on old perimeter-based connectivity. For many organizations, GSA becomes the long-term replacement for VPN infrastructure, reducing dependency on legacy appliances and aligning endpoint access with modern Zero Trust principles.

So the net-net is that GSA is providing similar functionality of a VPN, but it is aligning to Zero Trust principles. That is the key difference between GSA and VPN.

GSA provides:

Zero Trust Network Access (ZTNA)
Private access to on-prem apps without exposing your network
Device compliance checks before granting access
Identity-based segmentation
Application-level connectivity, not network-level tunnels

This means:

Moving away from “Trusted Locations” in Conditional Access
No full-tunnel VPN
No flat network exposure
No device-level implicit trust
Better security + better user experience

It aligns perfectly with a pure Entra Join strategy.

Read more here: https://learn.microsoft.com/en-us/entra/architecture/gsa-deployment-guide-intro

Why organizations are making this move now

As environments become more cloud-centric, the case for hybrid join is rapidly diminishing. Organizations adopting pure Entra Join experience a significant simplification of their operational model. Intune delivers a consistent, cloud-based management experience without competing with local Group Policy. Authentication becomes cleaner as devices rely on Entra ID, Conditional Access, and Windows Hello for Business—not periodic communication with domain controllers.

Security also sees a measurable improvement. By removing the domain join, organizations reduce machine-based trust relationships that often serve as lateral movement opportunities for attackers. Device identity becomes cloud-bound and policy-driven, backed by risk signals, compliance evaluation, and strong authentication. Even when legacy applications remain on-premises, Entra Kerberos ensures users can still authenticate seamlessly without requiring domain-joined machines.

This shift is not only technical—it’s architectural. Pure Entra Join aligns devices with Zero Trust, cloud-first identity, and modern endpoint governance, all while maintaining compatibility with traditional resources during the transition period.

✔ Intune becomes your single management plane

✔ Security posture improves dramatically

No more Group Policy vs Intune conflicts.
No more hybrid confusion.
One consistent policy framework.

Removing domain join removes:

Machine accounts with privileges
Lateral movement paths
Service tickets tied to vulnerable devices
Old NTLM/GPO dependencies

✔ Zero Trust becomes real, not theoretical

Device compliance + Conditional Access + WHfB + Global Secure Access =
Identity and device-driven access to everything.

✔ Remote work becomes effortless

No more domain join drift.
No more VPN dependence for “being on the domain.”

✔ You reduce legacy dependencies without breaking legacy apps

You modernize device trust, not necessarily every application on day one.

Reducing dependencies without breaking legacy applications

Moving to pure Entra Join is not an all-or-nothing exercise. Most organizations still have a mix of cloud and on-prem technologies, and many line-of-business applications continue to rely on AD DS authentication. The advantage of the Entra Join model is that it supports both worlds simultaneously.

A pure cloud-joined device can authenticate to Entra ID for cloud access while also obtaining Kerberos tickets for on-premises systems through the Entra Kerberos trust mechanism. This allows organizations to modernize the device trust layer without immediately modernizing every application. Over time, as more workloads shift to SaaS, Azure-hosted services, or modern authentication models, the dependency on on-prem resources naturally shrinks—enabling incremental transformation instead of disruptive overhauls.

The result is a smoother modernization journey that keeps users productive and secure regardless of where the application lives.

Things To Consider

As always, we need to think through things and do proper planning. Let’s take a look at some of the items you will want to consider.

One of the biggest planning challenges is migrating Group Policy configurations into Intune. Many organizations assume they rely on GPO too heavily to move to a cloud-native endpoint model. In reality, Intune has significantly matured and now includes hundreds of native settings that map directly to traditional GPO templates. Administrative templates in Intune cover most of the common Windows configuration scenarios organizations use today.

For policies not included out of the box, Intune supports importing custom ADMX templates. This makes it possible to re-create nearly any GPO—especially those tied to specific enterprise applications or device restrictions—directly in the cloud. It’s important to inventory existing GPOs and categorize them into: policies that map to native Intune settings, policies that can be recreated with custom ADMX files, and policies that are no longer needed due to modern security controls or platform changes.

Organizations should also consider user experience during the transition. Features like Windows Hello for Business (check out my blog post here), Conditional Access, Intune compliance policies, and application deployment workflows may require communication and training. Mapping out identity flows, resource access paths, and authentication scenarios will ensure user productivity remains uninterrupted.

A structured migration plan, combined with a pilot group and thorough testing, helps validate that applications, authentication, and resource access behave as expected. Most environments find that the actual complexity is significantly lower than anticipated once GPO dependencies are evaluated.

Summary

As we wrap up this post, I want to revisit all the items we discussed.

Transitioning from hybrid joined devices to pure Entra Joined endpoints represents a major step toward a modern, cloud-native identity and device ecosystem. Devices no longer need periodic communication with domain controllers, and VPN is no longer necessary for management or authentication. Instead, Intune becomes the unified policy engine, Conditional Access enforces trust decisions, and Entra Kerberos bridges the gap to on-premises resources when needed.

Organizations also gain the option to replace traditional VPN solutions with Global Secure Access, which provides a Zero Trust approach to application access without exposing the internal network. The move to pure Entra Join simplifies endpoint management, reduces attack surface, improves security posture, and supports both modern and legacy applications during the transition. With thoughtful planning—especially around migrating Group Policy into Intune—organizations can modernize their device strategy while keeping users productive and connected throughout the journey.