Identity Federation vs Identity Synchronisation: Choosing a Hybrid Identity Architecture

Every organisation that runs an on-premises directory and a cloud identity provider has to decide where passwords are checked, and that single decision sets the attack surface, the outage behaviour and the blast radius of a compromise for every user. There are three patterns: federation, where an on-premises identity provider authenticates users and the cloud trusts its signed tokens; password hash synchronisation, where a derived hash is copied to the cloud and the cloud authenticates; and pass-through authentication, where the cloud asks an on-premises agent to check the password against the directory. This guide compares them as architectures: threat model, failure modes, availability, MFA enforcement, migration, a worked scenario for each and a decision checklist. It is written for identity architects and security leads, and is vendor-neutral; product names appear only to show how platforms implement each pattern.

Key takeaways

• Federation concentrates trust in one signing key. Whoever holds the on-premises token-signing key, or can add a new federation trust, can mint sign-ins for any federated user and skip cloud MFA.
• Synchronisation concentrates trust in one sync service. The sync server and its connector accounts can read password data from the directory and change cloud identities, so they are Tier 0 assets.
• Pass-through keeps passwords on premises but keeps the dependency too. If the agents or domain controllers are down, cloud sign-in fails.
• Cloud authentication survives on-premises disasters. Organisations with hash sync already enabled recovered from on-premises outages in hours rather than weeks, according to Microsoft's guidance.
• Directory sync is needed in all three. Accounts and groups still have to reach the cloud, so the question is only where the password is verified, not whether you synchronise.

The three patterns in plain terms

MITRE ATT&CK technique T1556.007 Hybrid Identity describes the same three patterns and why attackers target each one: password hash synchronisation, where a privileged on-premises account synchronises password hashes so authentication happens in the cloud; pass-through authentication, where cloud sign-ins are forwarded to an on-premises agent; and federation, where a trust relationship lets an on-premises identity provider vouch for users.

• Federation: the user is redirected to an on-premises identity provider (or a third-party one) that checks the password and MFA and returns a signed SAML assertion or OpenID Connect token. The cloud trusts any token signed by the registered key for that domain.
• Password hash synchronisation (hash sync): a sync service reads password hashes from the directory, derives a further hash and sends it to the cloud provider, which then authenticates users itself. The plaintext password is never sent.
• Pass-through authentication (PTA, also called delegated authentication): the cloud receives the password, sends it over an outbound-initiated channel to agents inside the network, and the agents validate it against domain controllers. No password data is stored in the cloud.

Account and group synchronisation runs alongside all three; the trust question is password verification. For the SAML and OIDC mechanics behind federation, see the Identity Federation Failure Modes guide.

Side-by-side comparison

How platforms implement each pattern

Platforms are listed alphabetically; order is not a ranking. Each row records what that vendor's own documentation describes as of November 2026.

For platform hardening see the Google Workspace Security Guide, the Microsoft Entra Connect and Cloud Sync Hardening Guide and the Okta Security Hardening Guide.

Federation: threat model, failure modes and controls

Architecture in words: the cloud provider holds a federation trust per domain: the issuer, the sign-in URL and the public certificate of the on-premises token-signing key. A user is redirected to the on-premises identity provider, authenticates there, and returns with a signed assertion that the cloud accepts if the signature matches.

Threat model: the token-signing key is the whole trust. ATT&CK T1606.002 SAML Tokens describes adversaries forging SAML tokens with any claims and lifetime once they hold a valid token-signing certificate, or, with enough cloud privilege, establishing a new federation trust with a server they control (T1484.002 Trust Modification). A forged token can assert that MFA was already performed, so cloud MFA may never be prompted. In the SolarWinds SUNBURST and Golden SAML intrusions, attackers with privileged on-premises access took the SAML token-signing certificate and signed in as any user to federated services. Detection and response for this technique are covered in the Golden SAML and Federation Trust Abuse Defence Guide.

Failure modes: token-signing certificate expiry or a missed rollover locks every federated user out at once; the federation farm, its proxies or its load balancer fail, and so does cloud sign-in; MFA is configured on premises but the cloud is not told to require it, or the reverse; and federation servers are administered from ordinary workstations, putting the signing key within reach of a normal domain compromise.

Controls: treat federation servers as Tier 0, keep the signing key in an HSM where the product supports it, restrict who can change domain federation settings in the cloud tenant, alert on any new federated domain or certificate change, and keep hash sync enabled as a documented break-glass path.

Worked scenario: a manufacturer federates because it uses an on-premises MFA product the cloud cannot call directly. Its IdP tenant shows an unexpected federated domain added at 02:00 by a global administrator account that has no MFA. Because the team alerts on federation configuration changes, it removes the domain, resets the administrator and reviews sign-ins asserted by the new issuer, before the trust is used broadly.

Hash sync: threat model, failure modes and controls

Architecture in words: a sync server reads accounts, groups and password hashes from the directory and writes them to the cloud. In Microsoft's implementation, the sync agent adds a 10-byte per-user salt to the directory hash, runs PBKDF2 with 1,000 iterations of HMAC-SHA256, and sends the result over TLS; the original hash is not transmitted, so a hash taken from the cloud cannot be replayed on premises in a pass-the-hash attack. The process runs every two minutes.

Threat model: the sync connector account needs directory replication rights (in Active Directory, Replicate Directory Changes and Replicate Directory Changes All) to read hashes, which are the same rights abused in T1003.006 DCSync. The cloud-side sync identity can typically write to synchronised users. In the Storm-0501 hybrid cloud attack, the group located the sync servers after gaining Domain Admin, extracted the sync account credentials, and used them as a route to change cloud passwords of hybrid accounts. The cloud now also holds a crackable derivative of every password, so password strength still matters.

Failure modes: the sync server is treated as an ordinary application server; connector account credentials are not rotated after a domain compromise; disabled or expired accounts stay usable in the cloud until the next sync, and in Microsoft's implementation the accountExpires attribute is not synchronised, so expired directory accounts stay active in the cloud unless another process disables them; and privileged cloud administrators are synchronised accounts, so an on-premises compromise flows straight up.

Controls: run the sync server as Tier 0 with the same protection as a domain controller, manage the connector accounts as privileged non-human identities, keep cloud administrators cloud-only with phishing-resistant MFA, filter privileged on-premises groups out of sync, and disable leavers through a process that does not depend on account expiry. See How to audit the Entra Connect sync account and the Service Account Security Guide.

Worked scenario: a retailer loses its data centre to ransomware. Because hash sync was enabled, staff keep signing in to email and collaboration tools from personal devices under cloud Conditional Access while the directory is rebuilt. After rebuild, the team rotates the connector credentials and re-registers the sync server before re-enabling synchronisation.

Pass-through: threat model, failure modes and controls

Architecture in words: lightweight agents on internal servers hold outbound connections to the cloud provider. When a user signs in, the cloud encrypts the password for the agents, an agent decrypts it and validates it against a domain controller, and returns the result. Microsoft documents that its agents use only outbound connections on port 443 (port 80 for certificate revocation lists), authenticate with a tenant-scoped RSA 2048 client certificate whose private key stays on the server, and that passwords are never stored in the cloud in any form.

Threat model: the agent sees plaintext passwords in memory as it validates them, and can approve or refuse sign-ins. ATT&CK T1556.007 notes that adversaries may backdoor hybrid authentication components, which for pass-through means the agent host. Microsoft advises treating agent servers as Tier 0 and hardening them as domain controllers.

Failure modes: too few agents, so maintenance or a failure stops sign-in (Microsoft's guidance recommends three agents and notes that a sign-in in flight on a failed agent is dropped, not handed to another); domain controllers unreachable from agent sites; agent certificates that expire after a long outage and must be re-registered; and no fallback configured, because switching to hash sync is a manual change.

Controls: deploy at least three agents across sites, monitor agent health and certificate status, keep hash sync enabled where policy allows as a manual fallback, and include the agent hosts in privileged access tiering.

Worked scenario: a public body is told by its legal team that password data may not leave its network. It uses pass-through authentication with agents in two data centres, documents the outage risk in its risk register, and rehearses the manual failover process annually with a temporary policy exception.

Availability and blast radius compared

The cloud administrator row matters: whichever pattern you choose, a tenant administrator can add a federation trust, so alerting on federation changes is required even if you never federate. For recovery planning see the Active Directory and Entra ID recovery guidance.

MFA and access policy enforcement

• Federation: MFA can be performed by the on-premises provider and asserted to the cloud in a claim. If the cloud accepts that claim, its own MFA is skipped, which is convenient and also what a forged token exploits. Decide which side is authoritative and configure the other to match.
• Hash sync and pass-through: MFA and Conditional Access run in the cloud, so policy is in one place and phishing-resistant methods are available without on-premises integration. See the Conditional Access Guide.
• Legitimate reasons to keep federation: Microsoft's guidance lists needs such as an on-premises third-party MFA product, a third-party authentication solution, or sign-in with the legacy pre-Windows 2000 user name. Smart card sign-in can often move to cloud certificate-based authentication instead.

Decision guidance

Whatever you choose, enable hash sync in the background where policy allows: Microsoft's guidance recommends it alongside any method, both as a fallback and because its leaked credential detection depends on it.

Migration from federation to cloud authentication

1. Inventory: list relying parties, claim rules and any MFA or device logic on the federation side.
2. Enable hash sync first: let hashes populate with no change to sign-in behaviour.
3. Pilot with staged rollout: move a test group to cloud authentication and watch sign-in logs and help desk volume.
4. Move applications: recreate federation-side app trusts as cloud applications.
5. Convert domains: switch each domain from federated to managed during a change window, keeping the farm running for rollback.
6. Remove the trust: after a period of zero traffic, decommission servers and destroy token-signing keys.

Rollback is converting the domain back to federated while the farm still runs. The Microsoft-specific runbook is in the AD FS to Entra ID Migration guide.

Detection and measurement

• Federation: alert on new or changed federated domains, token-signing certificate changes, and cloud sign-ins asserted by federation with no matching on-premises authentication event.
• Hash sync: alert on interactive sign-in by sync accounts, use of sync credentials from any host other than the sync server, configuration changes on the sync server, and directory replication requests from unexpected sources.
• Pass-through: monitor agent registrations, agent health and certificate renewals; alert on new agents registered outside change windows.

Metrics:

• Percentage of users on cloud authentication.
• Number of federated domains and token-signing keys remaining.
• Percentage of privileged cloud roles held by cloud-only accounts.
• Time from on-premises disable to cloud disable.
• Date of the last tested fallback from pass-through or federation to hash sync.

Common failure patterns

• Sync server outside Tier 0: the sync host is patched and administered like a file server, as in the Storm-0501 intrusions.
• Federation kept "just in case": unused farms still hold live signing keys trusted by the cloud.
• No alert on federation changes: a rogue federated domain becomes a silent backdoor.
• Synchronised global administrators: on-premises compromise becomes cloud compromise.
• Untested fallback: the manual switch to hash sync is attempted for the first time during an outage.

Framework mapping

Practitioner checklist

• Record which pattern each domain uses and why.
• Classify sync servers, federation servers and agent hosts as Tier 0.
• Manage sync connector and agent identities as privileged non-human identities.
• Keep cloud administrators cloud-only with phishing-resistant MFA.
• Alert on federation trust, signing certificate and agent registration changes.
• Enable hash sync as a fallback where policy allows and test the switch.
• Close the account-disable gap for synchronised users.
• Set a dated plan to retire federation that no longer has a requirement.

Standards and references

• MITRE ATT&CK: Hybrid Identity (T1556.007)
• MITRE ATT&CK: SAML Tokens (T1606.002)
• NIST: SP 800-53 Rev. 5
• Google: About Google Cloud Directory Sync
• Microsoft: Choose the right authentication method for hybrid identity
• Microsoft: Pass-through authentication security deep dive
• Okta: Enable delegated authentication
• Okta: Active Directory integration

Related NHI Mgmt Group resources: Identity Federation Failure Modes · Microsoft Entra Connect and Cloud Sync Hardening Guide · Golden SAML and Federation Trust Abuse Defence Guide · Identity Provider and SSO Security Guide · Tiered Administration Guide