The first and most critical decision in hybrid identity isn’t the sync tool — it’s the authentication method. Because this decision is the layer that controls a user’s access to everything in the cloud; whatever you build on top — Conditional Access, MFA, leaked-credential detection, disaster recovery — rests on this choice. In Microsoft’s own words: "not a decision to take lightly."
There are three options: Password Hash Synchronization (PHS), Pass-through Authentication (PTA) and Federation (AD FS). Most guides list "pros and cons" and leave you undecided. I’ll go the other way: give the clear answer first, then show why it’s the answer — through account-state enforcement, security features and the disaster scenario.
Short answer
Whichever method you pick, enable Password Hash Sync (PHS). This is Microsoft’s clear recommendation and it has been proven in the field again and again.
- New or standard environment: start with PHS + Seamless SSO. Least infrastructure, highest resilience.
- You have a security requirement to enforce on-prem account state (lockout, expiry, sign-in hours) at sign-in time: PTA — but enable PHS alongside it as a backup.
- You have a specific need Entra can’t meet natively (third-party MFA that requires federation, sign-in with
sAMAccountName, a third-party identity provider): Federation — and again enable PHS as a backup.
As you can see, every path ends with PHS. You’ll see why in three sections below.
The three methods, briefly
Password Hash Synchronization (PHS) — a hash of the user’s password hash is synced to Entra (the password is never stored in clear text or a reversible form). Validation happens in the cloud. It depends on on-prem only during sync (default ~2 minutes), not at sign-in. Least effort, least infrastructure.
Pass-through Authentication (PTA) — password validation happens on-prem via a lightweight agent; the password hash is not stored in the cloud. Sign-in depends on on-prem AD being up. Requires an agent.
Federation (AD FS) — Entra delegates validation to a separate, trusted system (AD FS). Validation happens entirely on-prem. The largest infrastructure footprint; the most complex to operate and troubleshoot.
Comparison table
| Criterion | PHS | PTA | Federation (AD FS) |
|---|---|---|---|
| Where does validation happen? | In the cloud (hash comparison) | In the cloud, after secure validation via on-prem agent | On-prem |
| Extra servers beyond Connect? | None | One server per extra agent (3 agents recommended) | 2+ AD FS + 2+ WAP (DMZ) |
| TLS/SSL certificate? | No | No | Yes |
| Cloud sign-in if on-prem is down? | Works | Stops | Stops |
| Account state applied instantly? | Disable only (~30 min delay) | Yes: disable, lockout, expiry, sign-in hours | Yes (same as PTA) |
| Leaked-credential report (ID Protection) | Yes (P2) | Requires PHS | Requires PHS |
| Smart lockout | Yes | Yes | AD FS extranet lockout |
| Setup/operations overhead | Lowest | Medium | Highest |
Critical difference #1: when is account state applied?
What happens when you disable a user on-prem?
- PHS: the change isn’t reflected immediately. The user can keep accessing cloud apps until the state syncs to Entra (a delay of up to ~30 minutes for disable). Also, password expiry and account lockout states are not synced to Entra. If you did a bulk disable, triggering a manual sync cycle is a good habit.
- PTA and Federation: enforce on-prem account policy at sign-in time. A disabled, locked, or expired account, or a sign-in outside allowed hours, is rejected instantly.
So if you have a strict requirement like "a departing user’s cloud access is cut within seconds," that alone can justify PTA (or Federation). Otherwise PHS’s delay is acceptable for most environments — and you compensate with a manual sync for bulk operations.
Critical difference #2: some security features don’t work without PHS
- Microsoft Entra ID Protection — the leaked-credentials report requires PHS (and Entra ID P2), whatever method you choose. Microsoft continuously scans user/password lists sold on the dark web; it can only catch one of your users on such a list if PHS is enabled.
- Smart password lockout ships with PHS and PTA.
- Microsoft Entra Domain Services also requires PHS.
The upshot: even if you use Federation or PTA, you need PHS enabled as a backup so you don’t lose part of modern threat protection. It’s not "either/or"; PHS usually runs alongside the other.
Critical difference #3: what happens if on-prem goes down?
When a ransomware attack or disaster takes down your on-prem servers:
- Organizations on PTA/Federation only that never enabled PHS: cloud sign-in is also tied to on-prem, so access is cut. Microsoft’s field observation is clear — such organizations were forced onto untrusted external email systems for communication, and restoring on-prem identity infrastructure took weeks.
- Organizations that had enabled PHS alongside PTA/Federation: when the primary method went down they switched to PHS (manually via Connect) and were back online within hours, able to reach Microsoft 365 email and manage the crisis.
The lesson in one sentence: PHS isn’t just an authentication method, it’s your disaster insurance. It’s free, simple, and a matter of minutes to enable. There’s no valid reason not to.
Note: failover to PHS isn’t automatic; you change the sign-in method manually via Connect. Rehearse it once before you’re in a crisis.
Which to choose, and when
Choose PHS if: you’re a new/standard environment, you want the least infrastructure and highest resilience, and ID Protection leaked-password detection matters to you (it should be on regardless).
Choose PTA if: you must enforce on-prem account state at sign-in time, or you don’t want the password hash in the cloud at all — but still deploy with 3 agents and PHS as backup.
Choose Federation if: you have a specific need Entra can’t meet natively (third-party MFA that requires federation, a third-party IdP, sign-in with sAMAccountName), or you already have a mature AD FS investment. For new deployments it’s usually unjustified: the cost, complexity and troubleshooting burden are high. Microsoft recommends cloud authentication (PHS/PTA); you can pilot the move from federation with Staged Rollout.
Field notes
- Don’t deploy "PTA first, no PHS." PTA with no backup takes you out of the cloud too at the first serious on-prem failure.
- Don’t run a single PTA agent. Agent on the Connect server + 2 extra = 3. One down for maintenance and another failing still leaves you up.
- Don’t put agents in the DMZ. PTA agents need unrestricted network access to DCs; installing them in a perimeter network is unsupported.
- Compensate PHS’s delay with process. A manual sync cycle after bulk disables.
- Note: the authentication method is independent of the sync tool (Connect Sync or Cloud Sync); the Connect Sync setup doesn’t change this decision.
Conclusion
All three methods are valid but not equal. PHS gives the highest resilience for the lowest overhead and unlocks modern security features; PTA steps in when you must enforce on-prem account policy instantly; Federation makes sense only when a specific need Entra can’t meet natively exists. Their common denominator: always enable PHS — as your primary method or at least as disaster backup. After choosing the method, the next step is to condition access with MFA and Conditional Access.
