Entra Hard Match Blocking for MSPs: Preflight Privileged Cloud Accounts Before You Sync
Microsoft closed a dangerous hybrid identity shortcut. MSPs should stop treating an Entra sync as a harmless directory chore.
Since June 1, 2026, Microsoft Entra ID blocks Entra Connect Sync and Cloud Sync from hard-matching a new Active Directory user to an existing cloud-managed Entra user that holds a Microsoft Entra role. That means an old cloud-only admin, a break-glass account, or another privileged identity can no longer be casually taken over by an incoming on-premises object.
Quick answer: before an MSP runs Entra Connect or Cloud Sync cleanup, inventory cloud-managed privileged accounts, inspect onPremisesImmutableId and sourceAnchor history, confirm sync scope, name the approval owner, and write the rollback and validation plan. The change is a security safeguard, not a reason to start guessing at account matching.
Microsoft's Entra release note is clear about the reason: hard matching can let an attacker take over a privileged cloud-managed user by manipulating attributes in Active Directory. The block removes that path for users with Entra roles.
What Microsoft changed, and what it did not
Hard match is the process where Entra Connect Sync or Cloud Sync sees a new Active Directory object, compares its sourceAnchor with the onPremisesImmutableId on an existing cloud-managed Entra object, then takes over that object's source of authority when they match.
That can be useful during a legitimate hybrid identity project. It can also be a very bad day when the target is a cloud-only Global Administrator and the match was never reviewed.
Microsoft now blocks that take-over when all three conditions apply:
- The incoming object is a new user from Active Directory.
- The target is an existing cloud-managed Entra user.
- The target holds a Microsoft Entra role.
The guardrail does not stop every sync. Microsoft says hard-match operations for cloud users without Entra roles are unaffected. Soft matching is unaffected too. Ongoing sync for objects that were already hard-matched is also unaffected.
That distinction matters. Do not tell a client that Entra Connect is broken. Tell them the risky account-conversion path now needs proper identity work.
The MSP preflight before Entra Connect or Cloud Sync work
Run this before enabling a connector, widening an OU filter, cleaning up ImmutableId values, or trying to merge duplicate identities. A ticket that says "sync this user" is not a plan.
1. Find cloud-only and privileged accounts
Export or review every account with a Microsoft Entra role. Start with Global Administrator, Privileged Role Administrator, Authentication Administrator, Exchange Administrator, SharePoint Administrator, Conditional Access Administrator, and any custom roles with meaningful control.
Then flag which of those are cloud-managed, cloud-only, break-glass, emergency access, service-related, or named in a client runbook. These are the accounts that should not be swept into a sync project because somebody saw a matching UPN.
Your Conditional Access baseline should already identify break-glass accounts and admin exclusions. If it does not, fix that evidence gap before touching source of authority.
2. Inspect ImmutableId and sourceAnchor history
For each risky identity, record the current onPremisesImmutableId, whether it already has a hybrid source, its UPN, proxy addresses, role assignments, and the proposed Active Directory object that might match it.
This is where a harmless-looking cleanup turns weird. Old migration work can leave sourceAnchor values behind. A former employee can have a reused UPN. A cloud-only admin can share a naming pattern with a new on-premises hire. Nobody wins a prize for discovering that after a production sync.
Treat any existing ImmutableId on a privileged cloud-managed user as a review item. Microsoft specifically calls out that case in its change notice.
3. Review sync scope before the first run
Document the connector, Active Directory forest, OU filters, group filters, attribute filters, and whether the change is Entra Connect Sync or Cloud Sync. Include the exact users expected to enter scope.
The useful question is not "does sync work?" It is "which objects can this configuration introduce, and which cloud identities can they collide with?"
Keep a narrow first wave. Start with a small, known set of ordinary users. Do not use privileged users, break-glass accounts, or mystery duplicates as your smoke test. That is how a routine identity change turns into an after-hours recovery project.
4. Check partner and delegated access too
MSPs need to look past the client's internal admin list. Review GDAP relationships, partner access, delegated admin runbooks, service accounts, and any identities used by monitoring, backup, PSA integrations, or migration tooling.
The hard-match block is about Microsoft Entra roles. The operational risk is wider. If a sync changes the wrong identity's authority, it can still break delegated access assumptions, automation ownership, or the runbook someone needs during an incident.
Use the Microsoft Entra ID licensing guide for MSPs when the review exposes Conditional Access, P1, P2, or role-governance gaps. License rights and identity control are separate checks. Both need an owner.
5. Write the approval, rollback, and validation plan
Every client should get a short decision record before the change:
- Which identities are in scope and explicitly out of scope.
- Which privileged cloud-managed accounts were reviewed.
- Who approves changing source of authority.
- What to do if a hard-match error appears.
- How the MSP will validate sign-in, MFA, role access, mail, Teams, and critical app access after sync.
- Who owns the client communication if a user needs remediation.
The rollback line cannot be "we will undo it." Name the backup of the configuration, the person with break-glass access, the test account, and the stop condition. Identity work gets expensive when the plan exists only as optimism in a Teams thread.
Put the work in a client scope, not free support
This change is not a reason to bill a client for fear. It is a clean reason to separate discovery, remediation, and approval.
| Work item | What the MSP does | Client-facing output |
|---|---|---|
| Identity preflight | Review privileged cloud-managed accounts, role assignments, sourceAnchor history, and sync scope | Risk register with in-scope and protected identities |
| Sync design | Define connector filters, pilot users, rollback, and validation | Change plan and approval record |
| Remediation | Resolve duplicate identities, stale ImmutableId values, or source-of-authority conflicts | Tested remediation notes and exceptions |
| Validation | Test sign-in, MFA, role access, mail, Teams, and key apps after the change | Completion evidence and follow-up list |
That lets the client choose. A clean tenant may only need a short preflight and a controlled sync. A tenant with old migrations, duplicate admins, or unknown emergency accounts may need a real identity remediation project. Pretending those are the same job is how MSPs donate margin to Microsoft change notices.
Where Scopable fits
An Entra hard-match finding should not disappear into a spreadsheet after the technician closes the ticket. It belongs in an assessment, then a roadmap decision, budgeted remediation quote, approval record, and QBR follow-up.
Scopable gives MSPs one place to turn the identity preflight into client-ready scope and tracked decisions. If your team is tired of rebuilding that trail between an assessment, a quote, and a client meeting, start a Scopable free trial.
FAQ
What is Entra hard matching?
Entra hard matching is when Entra Connect Sync or Cloud Sync matches a new Active Directory user to an existing cloud-managed Entra user using sourceAnchor and onPremisesImmutableId, then changes the target's source of authority.
Who is affected by the June 1, 2026 hard-match block?
The block applies when a new Active Directory user would hard-match to an existing cloud-managed Entra user that holds a Microsoft Entra role. Cloud users without Entra roles are not affected by this specific block.
Are existing hard-matched users affected?
No. Microsoft says ongoing sync from Active Directory to Entra ID for previously hard-matched objects is not affected. The change targets new hard-match attempts involving privileged cloud-managed users.
Should MSPs sync break-glass accounts?
Usually no, not casually. Break-glass accounts should be explicitly documented, reviewed for roles and source of authority, and excluded from ordinary sync cleanup unless the client approved a specific identity design and rollback plan.
What should an MSP check before Entra Connect or Cloud Sync cleanup?
Check cloud-only admins, break-glass accounts, Entra role assignments, onPremisesImmutableId and sourceAnchor history, sync filters, delegated access, the approval owner, rollback steps, and post-sync validation.
