Entra Hybrid Identity Sync Cloud Only Privileged Orphaned Accounts: The Hybrid Audit Blind Spot

Entra Hybrid Identity Sync Cloud Only Privileged Orphaned Accounts Explained

Entra hybrid identity sync cloud only privileged orphaned accounts are the two blind spots this article covers: cloud-only accounts holding privileged Microsoft Entra roles that never touch on-premises Tier 0 governance, and orphaned synced users that Entra Connect leaves behind after their on-premises account is deleted. Both fall through the cracks of the sync pipeline that keeps most objects flowing cleanly between on-premises Active Directory and Microsoft Entra ID, and both are audit blind spots specific to hybrid estates rather than either side alone.

The first is the cloud-only privileged account: a user that was created directly in Entra ID, was never synced from on-premises AD, and holds an active or PIM-eligible Microsoft Entra role. The second is the orphaned synced user: an object that Entra Connect once synchronized from AD, whose on-premises source account has since been deleted or excluded from sync scope, but whose Entra ID object never gets cleanly removed. Neither shows up in the audits most hybrid organizations already run, because those audits are built around one side of the sync boundary — an on-premises tiering review scans AD, and even a broad Entra ID security audit usually assumes every identity still has a live on-premises counterpart.

Cloud-Only Privileged Accounts: A Deliberate Gap On-Prem Audits Don't See

Keeping Tier 0 accounts out of directory sync is not a mistake — it is Microsoft's documented recommendation. Microsoft's own guidance states plainly that "Tier 0 administrator accounts are used only for on-premises AD accounts. Such accounts aren't typically synchronized with Microsoft Entra ID in the cloud," and separately that "Global Administrator (and other privileged groups) accounts should be cloud-only accounts with no ties to on-premises Active Directory" (Secure access practices for administrators in Microsoft Entra ID).

The blind spot isn't the architecture — it's the governance gap that opens up around it. An on-premises tiering review (whether it's a manual audit against a model like ANSSI's tier model, or a tool such as PingCastle scanning AD) has no visibility into Entra ID role assignments at all, because a cloud-only account never existed on-premises in the first place. If the cloud-side governance program hasn't been built out to the same rigor — PIM eligible assignment instead of standing access, Conditional Access requiring MFA and a compliant device on activation, and periodic access reviews — a cloud-only Global Administrator can sit with a permanent active assignment, no MFA enforcement, and no activation logging, invisible to both halves of the audit program at once.

That gap has a concrete attack surface attached to it. SyncJacking is a hard-match takeover technique, confirmed by the Microsoft Security Response Center as an Important-severity privilege escalation issue, in which an attacker who controls attributes on an on-premises AD object can force Entra Connect to hard-match that object onto an existing cloud-managed user — including a privileged one — and take over its source of authority. The technique "leaves no trace in on-premises AD logs and only minimal trace in Entra ID logs" (Semperis: Syncjacking Could Enable Entra ID Account Takeover).

Microsoft has since shipped a platform-level mitigation. Per Microsoft's own troubleshooting documentation: "Beginning July 1, 2026, Microsoft Entra ID enforces hard match security hardening automatically," blocking a hard match whenever the target cloud account already has onPremisesObjectIdentifier set, holds an active privileged Entra role, or is eligible for one (Microsoft Entra Connect: Troubleshoot errors during synchronization — InvalidHardMatch). That hardening protects the takeover path — it does nothing to close the governance gap that let an unmonitored cloud-only admin exist in the first place, which is the piece this article's detection and remediation sections target. It's also worth pairing that access-side review with the emergency-access accounts every tenant keeps for a true break-glass scenario — see Entra ID break-glass account hygiene for how those specifically should (and shouldn't) be scoped.

Orphaned Synced Users: What Happens When Entra Connect Fails to Remove a Deleted On-Prem Account

On the other side of the boundary, deleting a user in on-premises AD does not guarantee its Entra ID twin disappears. Two documented mechanisms leave synced objects behind:

Accidental deletion prevention. Microsoft Entra Connect ships with deletion protection enabled by default, capped at 500 object deletions per export cycle. If a bulk on-prem cleanup, an OU move, or a broken sync filter causes more than the threshold to be deleted in one run, export simply stops — the Synchronization Service Manager reports stopped-deletion-threshold-exceeded on the Export step, and every one of those deletions stays unapplied in Entra ID until an admin reviews and resumes the job (Microsoft Entra Connect Sync: Prevent accidental deletes). In practice this means a single unnoticed threshold breach can leave dozens of deleted on-prem accounts still fully live and synced-looking in the cloud.

Scope exclusion without conversion. When an object is moved out of sync scope (an OU/group filter change, for example) rather than deleted outright, Entra Connect soft-deletes the Entra ID object and flips DirSyncEnabled to False — but, per Microsoft's own documentation, "this process however doesn't convert the object to cloud managed, it's still considered an object synchronized from on-premises Active Directory," and remains eligible to be hard-matched again later (Microsoft Entra Connect: Troubleshoot errors during synchronization). A user in this state is neither cleanly deleted nor genuinely cloud-native — it's a half-migrated object that most access reviews don't have a clean bucket for, similar in spirit to the stale privileged accounts that on-prem audits already flag, except this one is invisible from the AD side because the source object is already gone.

Detection: Finding Cloud-Only Privileged and Orphaned Synced Accounts

The onPremisesSyncEnabled property on the Microsoft Graph user resource is the anchor for both checks: it returns true for an actively synced object, false for an object that was synced but no longer is, and null for an object that has never been synced — i.e., genuinely cloud-native.

Query Microsoft Graph for Orphan Candidates

To pull the reverted-SOA / orphan candidate list directly, Microsoft documents this Graph query:

GET https://graph.microsoft.com/v1.0/users?$count=true&$filter=OnPremisesSyncEnabled ne true and OnPremisesImmutableId ne null

(Source: How to audit and monitor User Source of Authority (SOA) in Microsoft Entra ID.) Advanced filters on onPremisesSyncEnabled may require the ConsistencyLevel: eventual header and $count=true to return reliably.

Cross-Reference Privileged Roles Against Sync State

For the cloud-only privileged side, cross-reference role assignments (PIM eligible and active) against sync state:

# Users with an active or eligible Entra role that were never synced from on-prem
Get-MgUser -Filter "onPremisesSyncEnabled eq null" -ConsistencyLevel eventual -CountVariable c -All |
    Where-Object { (Get-MgUserMemberOf -UserId $_.Id) -match "RoleAssignable" }

Remediation

Close the Cloud-Only Privileged Gap

1. Extend Tier 0 governance to cloud-only privileged accounts. Every cloud-only account with an active or eligible Entra role should carry: PIM eligible (not standing) assignment, a Conditional Access policy requiring MFA and a compliant/managed device on activation (many tenants have gaps here — see Conditional Access baseline coverage gaps), and inclusion in the same periodic access review as on-premises Tier 0 — see nested and role-assignable group hygiene for the group-side equivalent of this same gap.
2. Keep the exception narrow. The only accounts that should sit outside PIM and CA scrutiny entirely are true break-glass emergency-access accounts — two, cloud-only, monitored, per Microsoft's guidance (see break-glass account hygiene). Everything else labeled "cloud-only because Tier 0 shouldn't sync" still needs an owner and a review cadence.

Clean Up Orphaned Synced Users

3. Tune accidental deletion protection instead of raising it blindly. Confirm the export deletion threshold (Enable-ADSyncExportDeletionThreshold) is set deliberately for your environment, route the stop notification to a monitored mailbox, and treat every stopped-deletion-threshold-exceeded event as an investigation trigger before resuming the export — resuming without review is what turns a config change into dozens of live orphans.
4. Reconcile stale sync state on a schedule. Query onPremisesSyncEnabled = false with an old onPremisesLastSyncDateTime, confirm against on-premises AD whether the source object still exists, and either restore the mapping or formally deprovision the cloud object — don't leave it in the half-migrated state.
5. Wire deletions into a governed leaver process. Microsoft Entra ID Governance Lifecycle Workflows can trigger disable/remove-access/schedule-deletion tasks off an authoritative signal (HR feed or AD attribute) rather than relying solely on sync export to propagate an offboarding — this catches the case where export silently fails.

Prepare for Hard-Match Hardening

6. Plan for hard-match hardening now, not on July 1, 2026. Any process that depends on re-matching a privileged or PIM-eligible cloud account to an on-premises object (forest recovery, tenant migration runbooks) will be blocked by default once Microsoft's hardening takes effect. Test your recovery runbooks against the documented workaround — temporarily removing the role or eligibility, completing the hard match, then restoring it — before you need it under incident pressure.

How EtcSec Detects This

EtcSec's Entra ID checks flag both sides of this gap directly: HYBRID_CLOUD_ONLY_PRIVILEGED surfaces cloud-only users holding a privileged role, and HYBRID_ORPHANED_CLOUD_USER surfaces objects whose sync state indicates a likely orphan. These are paired with UNRESOLVED_PRIVILEGED_MEMBERS (privileged role assignments referencing a principal that no longer resolves), PA_ADMIN_STALE_ACCOUNT (administrative accounts with no recent activity), and PA_GLOBAL_ADMIN_NOT_MFA (Global Administrators without enforced MFA) so that a cloud-only privileged account isn't just spotted, but checked against the same access hygiene bar as any other Tier 0 identity.