Federating identities across on-prem Active Directory and cloud directories like Microsoft Entra ID requires three things working together: directory synchronization (Entra Connect or an equivalent sync agent), a trust protocol for authentication handoff (SAML 2.0, WS-Federation, or OIDC), and a governance layer that maps group memberships and conditional access policies consistently across both environments. Skip any one of the three and you get partial federation — users who can authenticate in one directory but hit broken permissions or stale group assignments in the other. The cost most teams underestimate in 2026: federation doesn't just connect two directories, it extends the on-prem attack surface directly into the cloud tenant, so a single compromised AD credential can now reach cloud admin roles unless something segments that path.
- Federating on-prem AD and Entra ID needs directory sync, a trust protocol (SAML/OIDC/WS-Fed), and consistent group-to-role mapping — not just a sync tool.
- Password hash sync carries less attack surface than pass-through auth or ADFS federation, but all three extend on-prem risk into the cloud tenant.
- A federated credential is a credential with two attack surfaces, not one — segment it or a single AD compromise reaches cloud admin roles.
- Passwordless authentication removes the reusable credential that federation would otherwise carry across environments.
- Test break-glass and failover access separately from the federated path before go-live.
Why this matters
Most enterprises running hybrid identity in 2026 still treat federation as a plumbing project — get Entra Connect syncing, stand up the trust, ship it. That's how attack paths get built into the architecture on day one.
Federation was never designed as a security control. It's a convenience layer that lets one identity work in two places. Every convenience layer that spans on-prem and cloud is also a lateral movement path, and identity providers rarely flag that trade-off during setup.
How do you federate identities across on-prem and cloud directories?
The process breaks into six steps. Skipping the ordering — especially jumping to sync before classification — is the most common cause of failed federation rollouts.
- Inventory and classify on-prem AD objects — users, groups, and service accounts — before touching sync. You can't federate what you haven't mapped.
- Deploy directory synchronization using Entra Connect (or your platform's equivalent) with either password hash sync or pass-through authentication.
- Establish the trust relationship between the on-prem identity provider and the cloud directory using SAML 2.0, WS-Federation, or OIDC.
- Map AD groups to cloud roles and conditional access policies explicitly — assume nothing carries over 1:1.
- Segment the federated identity path so a compromised on-prem credential can't traverse laterally into cloud admin roles. This is where attack path management for hybrid Active Directory and Entra ID becomes the control that federation itself doesn't provide.
- Test break-glass and emergency access separately from the federated path, since a federation outage shouldn't lock out your recovery accounts.
Password hash sync vs. pass-through authentication vs. ADFS federation
All three connect on-prem AD to a cloud directory. They don't carry the same attack surface.
| Method | How it works | Attack surface added |
|---|---|---|
| Password hash sync | Hashes sync to the cloud directory; cloud authenticates independently | Lowest — cloud can authenticate even if on-prem is down |
| Pass-through authentication | Cloud passes login attempts back to on-prem agents for validation | Medium — depends on on-prem availability and agent security |
| ADFS federation | On-prem ADFS servers issue the tokens the cloud directory trusts | Highest — ADFS server compromise gives an attacker cloud-wide token forgery |
Password hash sync is the default recommendation for most enterprises in 2026 unless a specific compliance requirement mandates on-prem-only authentication. ADFS federation, while still common in regulated industries, concentrates risk in the federation server itself — a single ADFS compromise can forge tokens for every federated cloud application.
Why federated identity paths vary in risk
Not every federation setup carries the same exposure. The factors that determine how much attack surface a given federation design adds:
- Sync method chosen — ADFS federation concentrates risk in a token-issuing server; password hash sync distributes it.
- Group mapping precision — broad group-to-role mappings (mapping "Domain Admins" to a cloud admin role, for example) hand an attacker a shortcut.
- Service account federation — non-human identities federated without the same scrutiny as user accounts are a common blind spot.
- Conditional access parity — cloud MFA policies that don't mirror on-prem access controls leave a weaker path open.
- Legacy protocol support — NTLM and Kerberos fallback paths left active on-prem give attackers a route around the federated trust entirely, which is why eliminating NTLM authentication risk in enterprise networks matters as a companion project, not an afterthought.
- Standing credential reuse — a federated identity that still relies on a password rather than a passwordless factor is a credential an attacker can steal once and use in both directories.
Does federation actually create a lateral movement path?
Yes — a federated identity that authenticates once and reaches resources in both on-prem AD and the cloud tenant is, by definition, a single credential with two attack surfaces. Pass-the-hash and credential relay techniques that work against on-prem AD don't stop at the federation boundary; they follow the trust relationship into the cloud tenant unless the identity path is segmented. Reviewing how pass-the-hash attacks work in hybrid environments is a useful gut-check before finalizing any federation design.
How does identity microsegmentation change federated identity risk?
Identity microsegmentation contains a compromised federated credential to the segment it was authorized for, rather than letting it traverse from an on-prem workstation to a cloud admin console in one hop. Instead of trusting the federation trust relationship as the only control, microsegmentation adds a second checkpoint that blocks lateral movement even after a credential is stolen. Secfolio's identity microsegmentation for hybrid cloud environments applies this directly to federated AD-to-Entra ID paths, which is exactly the gap most federation projects leave open in 2026.
“A federated credential is a credential with two attack surfaces, not one.”
Does federation replace Active Directory?
No — federation extends Active Directory into the cloud, it doesn't replace it. On-prem AD typically remains the authoritative source for identity in a federated hybrid setup, with the cloud directory (Entra ID, for example) consuming synced accounts and honoring the federation trust for authentication.
Is Entra ID Connect the same as federation?
No — Entra ID Connect (formerly Azure AD Connect) handles directory synchronization, while federation refers specifically to the trust relationship (SAML, OIDC, or WS-Federation) that governs how authentication is handed off between the two directories. You can sync without federating, and in most 2026 deployments, password hash sync with cloud-native authentication is used instead of a full federation trust.
How long does it take to federate on-prem AD with Entra ID?
Timeline depends entirely on directory size, group mapping complexity, and which sync method is chosen, and no fixed industry benchmark applies across every environment. What consistently extends the timeline is skipping the classification step (step one above) and having to redo group mappings after the fact.
Map your hybrid identity attack paths
See where federated AD and Entra ID identities can move laterally before an attacker finds it.
FAQ
What’s the best sync method for federating on-prem AD with the cloud?
Password hash sync is the best default for most enterprises in 2026 because it carries the lowest attack surface and lets the cloud directory authenticate independently if on-prem goes down. ADFS federation concentrates more risk in a single token-issuing server.
Is ADFS federation more secure than password hash sync?
No — ADFS federation typically carries higher risk because a compromised ADFS server can forge authentication tokens for every federated application. Password hash sync distributes that risk instead of concentrating it in one server.
How much does identity federation increase attack surface?
Federation extends whatever attack surface exists on-prem directly into the cloud tenant, so the increase depends on how well the federated identity path is segmented. Unsegmented federation lets a single on-prem credential compromise reach cloud admin roles.
Do service accounts need to be federated the same way as user accounts?
Yes, and this is the most commonly missed step — service accounts federated without the same group-mapping scrutiny as user accounts become a lateral movement shortcut. Review non-human identities separately during federation planning.
Can you federate identities without exposing on-prem AD to the cloud?
Not entirely — any federation design creates some connection between the two environments by design. What you can control is how much of that connection is segmented, which is why identity microsegmentation is typically layered on top of the federation trust, not skipped.
Does passwordless authentication work with federated identities?
Yes — passwordless authentication removes the reusable password that a federated identity would otherwise carry across both on-prem and cloud directories, closing the credential-theft path federation opens.
What happens to federated identities during an Entra ID outage?
Password hash sync lets users authenticate to the cloud directory independently during an on-prem or Entra Connect outage, while ADFS federation and pass-through authentication both depend on on-prem infrastructure staying available.
Should break-glass accounts be federated?
No — break-glass and emergency access accounts should bypass the federated path entirely so a federation failure or compromise doesn’t lock out recovery access. Test this path separately before go-live.
One last thing
Most federation failures in 2026 aren't authentication failures — they're group-mapping failures discovered months after go-live, when a broadly mapped AD group quietly hands cloud admin rights to accounts nobody meant to elevate. Audit group-to-role mappings on a fixed schedule, not just at initial rollout, and treat every federated identity as a lateral movement candidate until it's segmented.
Related guides
- How to implement passwordless authentication at enterprise scale
- How to eliminate NTLM authentication risk in enterprise networks
