Blog
Entra joined vs hybrid joined: what actually blocks the move
Most Windows estates are hybrid joined out of caution, not need. The real list of things that still require Active Directory is shorter than most organisations believe, and it can be evidenced rather than assumed.
A default, not a decision
When Intune adoption took off, hybrid join was the sensible bridge: devices stayed in Active Directory, picked up an Entra identity alongside it, and nothing broke. The trouble is that the bridge became the destination. We still meet estates in 2026 where every new laptop is hybrid joined because that is what the Autopilot profile has always said, not because anyone has tested what would break without it.
Hybrid join is not free. It ties provisioning to domain connectivity, adds a synchronisation dependency that regularly causes enrolment failures, and keeps two management planes alive with two sets of policy, two credential models and two attack surfaces. Microsoft's own guidance has pointed at Entra join for new devices for years, and its deprecation of NTLM in June 2024 signalled clearly where the platform is going. The question is no longer whether to move, but what genuinely stands in the way.
What still needs line of sight to AD
Some dependencies are real, and pretending otherwise causes the failed pilots that give Entra join a bad name. The honest list looks like this. Applications that authenticate the computer account rather than the user, or that rely on Kerberos delegation configured against machine objects. Anything performing an LDAP bind from the device. NTLM-only line-of-business applications that cannot be reconfigured. Print deployments driven by per-machine Group Policy rather than shared queues. And some VPN or NAC products that gate access on domain membership or on certificates enrolled against the AD computer object.
Each of these has a modern answer, but each needs engineering work, not just a toggle. That is precisely why they must be identified per application and per device population before anyone commits a migration date.
What only looks like a blocker
The larger list is the one that evaporates under scrutiny. File shares are the classic example. The received wisdom says an Entra-joined device cannot reach on-premises shares, and it has been wrong since late 2022, when Windows Hello for Business cloud Kerberos trust became generally available. A synced user on an Entra-joined device with network reach to a domain controller gets Kerberos tickets and single sign-on to shares and shared printers, with no PKI build-out required.
The received wisdom says an Entra-joined device cannot reach on-premises file shares. It has been wrong since late 2022.
The same is true elsewhere. Most modern applications already authenticate against Entra and never notice the join type. Local admin password management moved to the cloud when Windows LAPS gained Entra backup in 2023. Remote access to remaining on-premises applications is served by Entra Private Access, generally available since 2024, or by any conventional VPN that does not insist on domain membership. Certificate needs are met from Intune with cloud PKI or SCEP. None of these requires the device object to live in Active Directory.
Evidence the blockers, per population
The difference between the two lists is not opinion, it is data, and every estate already generates it. Enable NTLM auditing on domain controllers and see which devices and applications actually negotiate it. Review Kerberos service ticket requests to find what the machine accounts are really used for. Mine sign-in and application telemetry to establish which populations touch legacy authentication at all.
In our experience the results are consistently lopsided: a large majority of devices, typically knowledge-worker populations, have no genuine AD dependency at all, while a small number of populations carry nearly all of the real blockers. Our Scout discovery tool captures per-device application usage precisely so these populations can be separated with evidence rather than assumption. One stubborn warehouse application should delay one device population, not the whole estate.
The staged path
There is no supported in-place conversion from hybrid joined to Entra joined, so the move rides on re-provisioning, which makes staging natural. Switch Autopilot to Entra join for new and rebuilt devices first, starting with the populations your evidence has cleared. Enable cloud Kerberos trust and Windows LAPS ahead of the first cohort so on-premises access and credential management work from day one. Convert the remainder at natural refresh points, and run the genuinely blocked populations as a managed exception list with a remediation owner per application.
Handled this way, Entra join is not a leap of faith. It is a sequence of small, reversible steps, each backed by data, and at the end of it you retire an entire management plane.
Ready to prove what actually blocks Entra join?
Our discovery tooling evidences the real AD dependencies per device population, so your migration plan rests on data, not folklore.