About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Confirm the configured authority for each object and attribute before you resume synchronisation, and do not treat "the cloud is up" as "on-premises applications can sign people in". Hybrid identity, in Microsoft's words, is one user identity for authentication and authorisation to resources regardless of location. It is accomplished by provisioning and synchronisation. Provisioning creates an object, keeps it up to date, and deletes it when the conditions are no longer met. Synchronisation is what keeps on-premises users and groups matching the cloud. Those two sentences are the recovery risk. A directory you restored from an older copy no longer matches. The result depends on sync rules, object matching, scope and deletion safeguards. Stale source state can export unwanted changes, including deletions; synchronisation is not a general newest-copy-wins reconciliation.
The sign-in method is a separate choice from the sync, and it decides which side has to be alive for a cloud login. This article stays on that choice. It does not rebuild a domain, restore a directory, or renew a federation certificate.
Why it matters
NIST SP 800-34 Rev. 1 defines a resource's recovery time by the impact on the other resources that need it. Identity is one of those resources for almost every application. In a hybrid estate there is not one identity system. There is a cloud directory, an on-premises directory, a sync engine, and a sign-in method that may call back to the office on every login. They can be restored on different days. Users will try the cloud application first, because that is the one that does not need the office network. If that login secretly depends on an agent in the office, the cloud application is not actually recovered.
Microsoft's hybrid identity page, updated 9 April 2025, states the business shape. Organisations deploy both on-premises and cloud applications. Users need both. Managing users in both places is the hard part, and the hybrid solution is a common identity for every resource, wherever it sits. During a recovery, "wherever it sits" is the problem. The resource in the cloud and the resource in the office do not become available together.
How it works
What is actually being kept in step
Microsoft Entra Connect is the on-premises application Microsoft documents for hybrid identity goals. The page updated 16 September 2026 also says to consider Microsoft Entra Cloud Sync, and it says Cloud Sync is the future of synchronisation and that it replaces Connect. That is a product-direction statement. It is not an instruction to change products while the estate is down. Our recommendation: identify which of the two is installed before you need it, and do not swap them as a recovery step. A swap is a new identity design, and this is the wrong week for one.
Connect's own feature list is the inventory you need in the plan:
- Synchronisation creates users, groups and other objects, and keeps on-premises identity information matching the cloud. The page says this synchronisation also includes password hashes.
- Password hash synchronisation is a sign-in method that synchronises a hash of the on-premises password with Microsoft Entra ID.
- Pass-through authentication is a sign-in method that lets users use the same password on-premises and in the cloud, without the extra infrastructure of a federation.
- Federation is optional. It can configure the hybrid environment using on-premises Active Directory Federation Services, and it includes management such as certificate renewal and adding federation servers.
- Connect Health monitors the on-premises identity infrastructure and puts that health in the Microsoft Entra admin centre. The health feature for sync requires Connect Sync V2. Connect Health for federation services supports specific Windows Server versions and can watch the web application proxy used for access from outside.
Azure AD Connect V1 was retired on 31 August 2022. Microsoft says V1 installations may stop working unexpectedly, and that Health for sync stopped working with V1 in December 2022. If a recovery plan still names V1, the plan is describing software the vendor has already told you may stop. Fix that in ordinary time. Do not make the upgrade the first act of the disaster.
Password hash sign-in does not ask the office on each login
The password hash page, updated 9 April 2025, says Microsoft Entra Connect synchronises a hash of a user's password from an on-premises Active Directory instance to Microsoft Entra ID. You sign in to Entra services such as Microsoft 365 with the same password you use on-premises. The hash is an extension of directory synchronisation.
Read that as a split in time. The moment of synchronisation needs the on-premises directory and the sync engine. The moment of sign-in, as this page describes it, is a sign-in to the cloud service using that password. The page does not say the cloud login places a call to a domain controller. Our reading, labelled as reading and not as a Microsoft outage promise: once a hash has been synchronised, a later cloud sign-in can be checked in the cloud. A password changed after the last successful sync, or an account created after it, is not in that picture. The hybrid page's job for synchronisation is to keep the two sides matching. If sync has been down for days, the cloud hash is the last match, not the password the user set this morning.
Microsoft also says you can set up password hash synchronisation as a backup if federation is your sign-in method. That option is the recovery design. It has to be turned on before the federation service fails. Enabling it during the outage only helps for hashes you can still produce, which means the on-premises directory has to be well enough to sync. It is a seatbelt, not a tow truck.
The documentation describes more than one deployment option. The password hash page's "to use this" list says to install the Microsoft Entra Cloud Sync agent. The Connect page describes password hash synchronisation as a Connect sign-in method. Both pages were opened on 11 November 2026. Both products can participate in password-hash synchronisation; these overview pages do not establish that either is the only supported installer. Our recommendation: record which agent is actually in the estate. Do not follow the other page's install list during an incident because it is the one you found first.
Pass-through password validation asks the on-premises directory
Pass-through authentication, on the page updated 26 May 2026, validates the user's password directly against on-premises Active Directory when the user signs in using Microsoft Entra ID. The pass-through validation mechanism does not require cloud-stored password hashes. A tenant may separately enable password-hash synchronisation, so that statement must not be applied to the entire tenant without checking its configuration. A lightweight agent installed on-premises listens for password validation requests and answers them. The agent only makes outbound connections, so Microsoft says it does not have to sit in a perimeter network. More agents, on more on-premises servers, are how you get high availability of those sign-in requests. The certificates the agent uses to talk to Entra ID are renewed by Microsoft every few months.
That design is the opposite of the hash for recovery purposes. The cloud sign-in is real only while an on-premises agent can reach both Entra ID and the on-premises directory. Our reasoning, from the behaviour the page states: if every agent is off, or the directory those agents validate against is off, the validation step has nowhere to run. High availability here is more agents in the office, not a copy of the password in the cloud. Rebuilding one agent does not help until the directory it validates against is the directory you intend, and until that agent can make its outbound connection. Certificate renewal being automatic is a steady-state feature. It is not a promise that an agent restored onto a new server, months later, still has a certificate Entra ID will accept. Check the vendor's current agent page before you assume it. This article does not include the install.
Microsoft positions pass-through as the choice for organisations that want on-premises password policy enforced, and password hash as the alternative that still gives cloud authentication. The recovery consequence is the reason to have made that choice consciously. Pass-through keeps the on-premises directory on the path of password validations that use it. Existing tokens, cloud-only accounts, passwordless methods and other configured sign-in flows need separate assessment. Password hash moves the password check to the cloud and accepts that the cloud is only as current as the last sync.
Federation puts a service, not only a directory, on the path
Federation, as Connect describes it, uses an on-premises federation infrastructure and brings certificate renewal with it. A cloud application that redirects sign-in to that service cannot finish the login while the service is down, even if both directories look fine. Our recommendation: the recovery plan names the federation service as its own gate, with its certificates, ahead of any application that redirects to it. Enabling hash synchronisation alone does not establish automatic failover; the sign-in method must follow the approved transition procedure. Password hash as a documented backup exists specifically for the case where you do not want that service to be the only way in. If you declined the backup, say so in the plan, so nobody discovers it during the incident.
This article does not describe how to recover a federation farm. Certificate renewal and extra servers are mentioned because Connect lists them as part of the feature. They are a dependency, not a procedure you should invent on the day.
Synchronisation is not a healing action
Connect Health exists so you can see the on-premises identity infrastructure from the admin centre: alerts, sync errors, and the federation and directory experiences. The agents sit on the on-premises identity servers. During a recovery those servers may be the things you have not started, so the health service goes dark for a boring reason. A dark health page is not proof the cloud directory is wrong. It indicates missing health evidence; the cause could be the agent, transport, permissions, service or display. Use it when the agents are back. Do not wait for it before you decide whether sync is safe to start.
The dangerous button is the sync itself. Provisioning, on the hybrid identity page, includes deleting an object when conditions are no longer met. A restored on-premises directory can be missing people who still exist in the cloud, or it can contain people you removed in the cloud last week. Our recommendation: before synchronisation runs, review the configured source of authority and expected exports for affected objects and attributes, including deletions, matching rules and enabled writeback features. Counts and samples are useful clues, not sufficient approval for an export. If the restored directory is behind, do not let it become the source of deletions. Do not assume arbitrary cloud-to-directory overwrite or a whole-tenant point-in-time restore exists: assess only the recovery and writeback mechanisms actually configured and supported. NIST's recovery point and recovery time are different numbers. Hybrid identity makes that concrete: the cloud can be reachable (time) while holding yesterday's passwords (point), or the office directory can be the newer point while the cloud applications are what users can actually open.
On-premises applications that only trust the on-premises directory are not rescued by a healthy cloud tenant. Microsoft's purpose for hybrid identity is a common identity for both. The common identity does not move the application's trust. An application configured to ask the office directory still asks the office directory. Recover that directory, or change the application on purpose. Do not describe a cloud-only login as if it covered both.
A practical order
Our recommendation:
- Name the sign-in method in the first hour, from the tenant's configuration, not from memory. Password hash, pass-through, federation, or federation with password hash as backup. The method is the dependency diagram.
- If the method is pass-through or federation, the on-premises piece is on the critical path of cloud sign-in. Agents or the federation service come before you tell users the cloud applications are open. More than one pass-through agent is Microsoft's availability pattern. One recovered agent is a single point until a second is up.
- If the method is password hash, cloud sign-in can be tested against the hashes already stored. Tell users that passwords changed after the last sync may fail. Do not promise the office applications, which still need the office directory.
- Keep disputed exports paused until the expected changes are reviewed and approved. Preserve unaffected flows where safe. Confirm deletion safeguards and observe the first authorised cycle for unintended changes. Connect Health is useful here, once its agents are on servers you trust.
- Avoid an unplanned identity-platform migration during recovery. The September 2026 page tells you Cloud Sync replaces Connect. That migration is a project with its own prerequisites. A stopped V1 server is a problem you should already have fixed. If the old version is unsupported or cannot run, a controlled move to a supported version may be necessary. Follow the current vendor recovery path rather than attempting to revive an unsupported installation indefinitely.
What to choose and why
These are our recommendations.
| Situation | Reasonable choice |
|---|---|
| You do not know the sign-in method | Find it before choosing the sign-in recovery path. The rest of the order depends on it |
| Password hash, cloud applications are the priority | Test cloud sign-in against the existing hashes. Warn that the last sync wins. Hold office applications until the office directory is back |
| Pass-through, office is down | Do not announce cloud sign-in. The validation runs against the office directory through an on-premises agent |
| Federation, and password hash was enabled as backup | Use the approved procedure to switch authentication to the prepared backup; enabled hash sync alone is not proof that failover is automatic. Do not try to enable it for the first time unless the office directory can still sync |
| Federation, no backup | The federation service is a gate of its own, including certificates. Cloud directories being up is not sufficient |
| Cloud and on-premises identity state disagree | Review object/attribute authority, sync rules and expected exports before resuming disputed changes |
| Connect V1 still in the plan | Plan a supported replacement in ordinary time; if recovery requires it now, use a controlled vendor-supported transition |
Risks and limits
- Password-hash synchronisation is described across Connect and Cloud Sync documentation. Identify the installed product and supported feature set; differing overview emphasis is not proof of an incompatible installer requirement.
- Nothing here is a promise that cloud sign-in survives an office outage. Password hash is described as synchronising a hash and signing in to cloud services with that password. Pass-through is described as validating directly against the office directory. The outage story is our reading of those designs.
- Passwords and accounts newer than the last sync are not covered by a cloud hash. Say that to users. Do not discover it at the helpdesk.
- Automatic certificate renewal is steady-state behaviour. A rebuilt agent or a rebuilt federation server needs its own check. The steps are not in this article.
- Connect V1's retirement date is 31 August 2022. Later pages still have to be read for the version you run. Cloud Sync "replaces" Connect as a direction statement on the 16 September 2026 page, not as a recovery procedure.
- No directory was restored and no sync was run. Forest recovery, account-database repair and federation-farm rebuilds are out of scope on purpose.
- NIST is used only for the idea that a shared service's time limit is set by the systems that need it. NIST does not describe Entra ID.
Research and verification
Drafted with AI assistance on 11 November 2026 and independently source-reviewed on 13 November 2026. No article commands or recovery operations were executed. This is educational source research, not a lab-validated production procedure.
Sources
Independently reopened 13 November 2026.
- Microsoft Learn, What is hybrid identity with Microsoft Entra ID?, updated 9 April 2025. Provisioning and synchronisation.
- Microsoft Learn, What is Microsoft Entra Connect and Connect Health?, updated 16 September 2026. Sign-in methods, Cloud Sync direction, V1 retirement, health monitoring.
- Microsoft Learn, What is password hash synchronisation?, updated 9 April 2025. Hash sync as a sign-in method, including as a backup to federation.
- Microsoft Learn, Pass-through authentication, updated 26 May 2026. Validation against on-premises Active Directory, agents, certificates.
- NIST SP 800-34 Rev. 1, May 2010: PDF. Recovery time as impact on dependent resources.
This article was originally published on .