Independent analysis by NHI Mgmt GroupSource article: WorkOS, “Azure Entra nested groups and Directory Sync: Limitations and workarounds” (March 20, 2026)

TL;DR: Azure Entra ID does not expand nested group membership over SCIM, so users inside child groups can disappear from app provisioning and login paths unless teams flatten membership, assign child groups directly, or reconcile through Microsoft Graph, according to WorkOS. The real issue is that authorization models often assume hierarchy will survive sync, but SCIM only carries what Entra explicitly sends.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Azure Entra nested groups do not expand through SCIM, so directory sync can leave child-group users out of app provisioning.

Why it matters: IAM and NHI teams need to treat SCIM scoping, group structure, and connector behavior as separate controls, or inherited access assumptions will fail at provisioning time.


Context

Azure Entra nested groups create a mismatch between how access is organised inside Microsoft Entra and what SCIM provisioning can actually transmit. The problem is not that SCIM is broken, but that the connector only sees direct membership on the group assigned to the application, so inherited access is not preserved across sync.

For identity governance, that means Directory Sync cannot be treated as a faithful mirror of an Entra hierarchy. If an application expects nested groups to resolve into user-level entitlements, the receiving system may see only a child-group reference, leaving users unprovisioned or unable to log in.

This is a common integration failure in enterprise IAM because teams often assume one directory model will survive every downstream connector. In practice, Entra nested groups work inside Microsoft-controlled access paths, but SCIM-based app provisioning follows a flatter data model.


Key questions

Q: What breaks when Azure Entra nested groups are synced through SCIM?

A: Inherited memberships do not survive the SCIM boundary, so users inside child groups may not be provisioned into the target application. The app receives the direct group membership Entra sends, not a recursive expansion of the directory tree. That can leave users visible in the source directory but absent from access decisions downstream.

Q: Why do nested groups create access problems in Entra Directory Sync?

A: Because the provisioning model assumes the receiving app can act on a flat membership set, while the source directory may be expressing access through inherited relationships. When that hierarchy is compressed, the application sees less than the administrator intended. The risk is not a protocol failure, but a mismatch between directory design and connector behaviour.

Q: How should teams handle nested groups when SCIM cannot expand them?

A: Either flatten the membership for the app, assign each child group directly, or use a separate reconciliation process that computes transitive members from Microsoft Graph. The right choice depends on scale, ownership, and whether the application actually needs to preserve hierarchy. If it does, SCIM alone is not enough.

Q: What should identity teams check first when users are missing after Entra sync?

A: Start with the group assignment in the enterprise app, then verify whether the assigned group contains child groups, and finally inspect the provisioning logs for skipped descendants. If the logs show only direct members, the problem is usually nested membership rather than a login issue. That sequence separates connector scope from downstream access errors.


Technical breakdown

Why nested groups are lost in SCIM provisioning

SCIM transmits the membership data the identity provider sends, not the identity provider's internal relationship graph. In Azure Entra, a parent group can contain child groups, but the SCIM provisioning flow only includes immediate members of the group assigned to the enterprise application. That means the application receives a child-group reference instead of a recursively expanded user list. The limitation is in Entra's provisioning implementation, not in the SCIM specification itself. For downstream apps, the result is a flattened payload that no longer reflects the directory hierarchy administrators expected to preserve.

Practical implication: Design your provisioning model around direct membership, not inherited group structure.

Why authorization breaks when hierarchy is assumed

Many SaaS applications translate synced groups into roles, organisations, or entitlements. If the provisioning feed omits users who live inside nested child groups, the application still creates the top-level group but never assigns the intended users. That breaks role mapping silently because the group object exists while the user array is incomplete or empty. The failure is especially hard to spot in large tenants where nested groups are used to model regions, teams, or business units. The receiving app is not making a bad authorisation decision; it is acting on incomplete membership data.

Practical implication: Validate group-to-role mappings with nested structures before relying on SCIM for access control.

When Microsoft Graph becomes the reconciliation layer

Microsoft Graph can return transitive members, which means it can recursively resolve the full nested membership tree that SCIM will not expose. Teams sometimes use SCIM for baseline provisioning and Graph for reconciliation, then compare the two views to restore the intended access set. That pattern works, but it introduces a second integration, more authentication surface, and schedule-based latency between the sync feed and the reconciled view. It is a compensating design, not a native feature of SCIM provisioning.

Practical implication: Use Graph reconciliation only where the organisation can operate a second membership source with clear ownership.


Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

SCIM inheritance breaks at the connector boundary: Entra nested groups are a directory convenience, not a provisioning guarantee. The application only receives what Entra explicitly sends, so hierarchical access disappears the moment the sync payload is flattened. That means downstream entitlement logic must be designed for direct membership only, not assumed inheritance.

Nested-group sync failure is a governance problem, not a protocol problem: The SCIM spec does not promise recursive expansion, and Entra's implementation reflects that boundary. The broken premise is that enterprise directory structure will remain intact across provisioning layers. Practitioners need to treat group hierarchy as local to the source directory unless a connector explicitly preserves it.

Transitive membership requires an explicit reconciliation design: When organisations need true nested-group resolution, they are no longer doing ordinary SCIM provisioning; they are operating a membership reconciliation process. That shifts responsibility for ownership, timing, and conflict resolution from the connector to the IAM programme. The practical implication is that identity governance must distinguish source-of-truth membership from app-facing entitlement shape.

Azure Entra nested groups are a classic example of entitlement compression: A parent group can imply many users inside Microsoft Entra, but SCIM compresses that structure into the immediate members only. The result is a smaller, less expressive entitlement payload than the source directory intended. Teams should assume every flattened connector can silently narrow access unless nested membership is tested end to end.

Directory Sync onboarding needs a hierarchy test, not just a connector test: The issue does not show up when flat groups are used, which is why it survives initial QA. Nested-group validation must be part of integration readiness, because the first real failure often appears only after a production tenant uses inherited membership. The lesson for identity programmes is simple: test the data model you actually deploy, not the one the connector makes easy.

What this signals

Entitlement compression: Nested-directory structures often lose meaning when they cross a provisioning boundary, and the application inherits a narrower access model than the source directory intended. Identity teams should treat every connector as a translation layer that can change semantics, not just transport objects.

SCIM-based provisioning works best when source and target share the same membership shape. Once a directory depends on inherited membership, practitioners need explicit validation, because the absence of a user in the target app is often a data-model issue rather than an authentication issue.


For practitioners

  • Test nested-group provisioning explicitly Include child-group scenarios in every Directory Sync validation so you can confirm what Entra sends and what the application actually receives.
  • Flatten app-scoped group membership Create dedicated direct-membership groups for app provisioning when the application cannot safely interpret inherited group structure.
  • Assign child groups directly where scale demands it Map each relevant child group to the enterprise application when the tenant structure is already organised by region, business unit, or team.
  • Reconcile transitive members with Microsoft Graph Use transitive membership lookups when you must preserve a nested hierarchy outside SCIM and can support a separate scheduled reconciliation flow.
  • Inspect provisioning logs for missing descendants Compare expected child-group members against the Entra provisioning log so you can identify whether the sync feed lost inherited membership or the app misread it.

Key takeaways

  • Azure Entra nested groups can disappear from downstream entitlement logic when SCIM provisioning only transmits direct membership.
  • The failure is common because the directory model looks correct in Entra while the app receives a flattened membership view.
  • Teams need direct-membership groups, child-group assignment, or Graph-based reconciliation when nested hierarchy must survive provisioning.

Key terms

  • Dynamic Group Membership: Dynamic group membership is a rule based way to keep group membership aligned with identity attributes or relationships. In Entra ID, the platform evaluates the rule and updates the group automatically. This reduces manual administration, but also creates dependency on the platform’s rule engine, supported operators, and scaling limits.
  • Transitive Membership: Transitive membership means all users who belong to a parent group directly or through one or more nested child groups. It is essential when access depends on inherited structure, but it requires a retrieval method that explicitly computes recursion rather than relying on a flat sync payload.
  • SCIM Provisioning: SCIM provisioning is a standardized way to sync identity information between systems. It helps automate account creation, updates, and removal across connected applications. Its main value is interoperability, but it still depends on accurate upstream data and governance over what access should actually be issued.
  • Entitlement Compression: Entitlement compression is the loss of access meaning when a rich directory structure is reduced to a flatter representation in a downstream system. The source may imply inherited access, but the target only receives a simplified membership set, which can silently narrow who is authorised.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org