Hybrid identity strategy for Microsoft 365

Most organisations with existing on-premises Active Directory can't migrate to Entra ID-only overnight. Hybrid identity — AD and Entra synchronised — is the multi-year transition state most enterprises live in. Designing it well makes the journey tractable; designing it badly creates years of operational debt.

The hybrid identity stack

The components, simplified:

On-premises AD DS — the legacy directory. Authenticates Windows endpoints, network resources, line-of-business apps.
Microsoft Entra Connect or Cloud Sync — synchronises users, groups, and (optionally) devices from AD to Entra ID.
Microsoft Entra ID — the cloud identity provider for Microsoft 365 and SaaS apps.
Authentication method — Password Hash Sync, Pass-Through Authentication, or Federation (AD FS).

The hybrid identity components. The sync engine (Entra Connect or Cloud Sync) is the backbone: on-prem AD flows into Entra ID, which is what Microsoft 365 and SaaS apps actually authenticate against. Authentication method and device join state are separate choices layered on top, not later steps in the same pipeline — an estate can be, for example, Password Hash Sync with Entra-joined devices, or Pass-Through Authentication with hybrid-joined devices, and every other combination the guide’s decision sections walk through.

The strategic choices

Sync engine: Entra Connect or Cloud Sync

Entra Connect — mature, supports complex scenarios (multiple forests, complex transformations, Exchange hybrid writebacks). Heavyweight, single-server bottleneck unless you stand up staging.
Entra Cloud Sync — lightweight, cloud-managed, active-active agents, simpler. Doesn't yet cover every edge case (some Exchange hybrid writebacks).

For new deployments, start with Cloud Sync. For existing Entra Connect, migrate when Exchange hybrid is decommissioned.

Authentication: PHS, PTA, or Federation

Password Hash Sync (PHS) — synchronise password hashes to Entra; auth happens in the cloud. Resilient, simple, supports Identity Protection's leaked-credential detection. Microsoft's recommended default.
Pass-Through Authentication (PTA) — auth happens against on-prem AD via agents. Required if policy says password hashes can't leave on-prem. Adds an agent dependency.
Federation (AD FS) — auth redirects to your AD FS farm. Heavyweight, harder to operate, the historical legacy option. Migrate off this unless you have specific requirements.

For new deployments, PHS by default. PTA only if regulatory policy requires. Federation: actively migrate away.

Device join: Entra-joined, Hybrid-joined, Domain-joined

Entra-joined — Windows devices joined to Entra ID, no on-prem AD dependency. The modern default; supports Intune, Conditional Access compliance, simpler operation.
Entra Hybrid-joined — joined to both AD and Entra. Bridge state during migration; useful for accessing on-prem resources while benefiting from cloud management.
Domain-joined only — legacy state. Limits cloud-side capabilities.

For new deployments, Entra-joined. For existing fleets, migrate to Entra-joined over time.

The journey

A realistic multi-year journey:

Stand up Entra Connect / Cloud Sync with PHS. Users have one identity.
Migrate to Entra-joined or Hybrid-joined devices. Adopt Intune.
Enable Conditional Access with compliance signals.
Migrate AD FS to PHS if you're on federation. Decommission AD FS.
Reduce on-prem AD scope — migrate line-of-business apps to Entra SSO, retire AD-dependent services.
Cloud-only end state — eventually, AD has only the residual roles it can't escape (file servers, some legacy apps).

Each step is months. The end state is cloud-only identity with no production AD; many organisations are 5–10 years into this journey and still have AD.

What to do today

If you're at the start: aim for Cloud Sync + PHS + Entra-joined as the destination. Migrate progressively. Resist adding new on-prem AD dependencies — anything new should be designed cloud-first.

The hybrid period isn't a bug; it's a feature of being a real organisation with legacy assets. Manage it deliberately, with a clear destination, and the journey gets shorter year by year.

Where organisations actually get stuck

Most hybrid-identity projects stall at the same handful of blockers. Naming them early lets the roadmap plan around them rather than discover them at year three:

Kerberos-only line-of-business apps. SAP GUI, some ERP fat clients, some manufacturing MES systems. Cloud Kerberos Trust and Entra Kerberos for hybrid users cover many cases, but every app is its own investigation. Inventory these first.
File servers with NTFS ACLs and Group-Policy-mapped drives. Moving the files to SharePoint / OneDrive is straightforward; moving the usage patterns (mapped drives, VBA that assumes \\server\share) is not. Either accept a permanent file-server tier or budget a real migration project.
Print. Universal Print covers most modern printers with the right agent, but old queue drivers and industry-specific print (label printers, cheque printers, MFP account codes) can pin a print server to on-prem AD indefinitely.
On-prem MFA / RADIUS / VPN infrastructure that authenticates against AD. Migration path is Conditional Access, NPS Extension, or Global Secure Access Private Access — each requires an in-flight project.
Certificate services. AD CS is often issuing Wi-Fi, VPN, and SCEP certificates driven by GPO. Intune SCEP or Cloud PKI needs to be in place before AD CS goes.
Applications hard-coded to LDAP. Ldap.corp and legacy printers point at domain controllers. Entra Domain Services or an authoritative sunset of the app is the usual answer; neither is quick.

Building a per-blocker owner list and a retirement date, even a soft one, is what turns "we still have AD" from a permanent state into a project.

Choose the destination shape early

Two shapes of "cloud-only" are both viable — the choice affects several years of design decisions:

True cloud-only. No on-prem AD at all. Devices Entra-joined, apps on Entra SSO or Kerberos through Cloud Trust, files in SharePoint / OneDrive, printers on Universal Print. Practical for organisations under a few thousand seats with no heavy legacy apps.
AD survives in a fenced role. A small AD forest continues to serve a narrow set of legacy systems (a couple of file servers, a Kerberos-only ERP, print). Entra ID is the primary identity; AD is a downstream consumer, not the source of truth. Practical for larger enterprises and manufacturers where full retirement is a 10-year rather than 3-year project.

Design the sync topology, admin RBAC, and joiner-mover-leaver flow for one of the two. Trying to keep both options open produces the worst of each.

Mergers, acquisitions, and divestitures

A common trigger for revisiting hybrid identity is M&A. Two patterns worth knowing:

Cross-tenant synchronization plus a Multi-Tenant Organisation lets the two Entra tenants operate as one for people-search, Teams, and SharePoint from day one — often faster than a directory merge and reversible if the deal changes.
Directory merges (source-of-authority moves, UPN changes, mailbox migrations) are the traditional path and take 12–24 months for anything above small. Only worth committing to when the tenant consolidation is strategic, not tactical.

Cross-tenant sync is not a replacement for eventual consolidation in most cases, but it is a very effective interim state that avoids painting the roadmap into a corner during the first 100 days.

Signals worth watching

Entra Connect Health — sync agents, sync errors, AD FS latency (until AD FS is gone).
Entra ID sign-in logs, filtered by Authentication requirement: multifactor and Client app: legacy authentication — legacy auth counts are the retirement signal for federated services.
Devices → All devices filtered by Join type — the shift from Hybrid Entra joined to Entra joined over time is the destination indicator.
On-prem-only groups still used by cloud apps — surfaces the last dependencies on AD as the source of authority for group membership.

Frequently asked questions

What is hybrid identity in Microsoft 365?

An identity model where user accounts are created and managed in on-premises Active Directory and synchronised to Entra ID (with password hash sync, pass-through authentication, or federation), so users have one identity for on-premises and cloud resources.

Password hash sync or pass-through authentication?

Password hash sync for almost everyone: no on-premises dependency at sign-in time, leaked-credential detection, and it works as a backup for federation. Pass-through authentication only when policy forbids storing password hashes in the cloud, accepting that an on-premises outage stops cloud sign-in.

When can we stop using on-premises Active Directory?

When nothing depends on it: Kerberos-only applications, file servers with NTFS permissions, Group Policy, RADIUS, and legacy printing are the usual blockers. Move devices to Entra join with Intune, apps to Entra authentication, and files to SharePoint, and the directory can be retired.