Notifications
Clear all
Topic starter
06/06/2026 11:24 am
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.
NHIMG editorial — based on content published by WorkOS: Azure Entra nested groups and Directory Sync limitations and workarounds
Questions worth separating out
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.
Q: Why do nested groups complicate enterprise access governance?
A: They complicate governance because the source directory and the target application may not share the same membership model.
Q: How can security teams tell whether missing access is caused by nested groups or something else?
A: Start by checking whether the group assigned to the Enterprise App contains child groups, then inspect Entra provisioning logs for the skipped users.
Practitioner guidance
- Map every SCIM-assigned group for nesting depth Review whether the group assigned to the Enterprise App contains child groups, and document where inherited membership is expected to survive.
- Flatten application-facing groups where role mapping is simple Create dedicated provisioning groups for app access and add users directly when the hierarchy is only serving organisational convenience.
- Use Microsoft Graph only as an explicit reconciliation layer When you cannot flatten hierarchy, build a separate process that queries transitiveMembers and reconciles it against SCIM output on a defined schedule.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step patterns for flattening nested memberships without breaking existing enterprise group models
- Comparison of direct child-group assignment versus Graph API reconciliation for larger tenants
- Admin checklist items for diagnosing missing users in Entra provisioning logs and Enterprise App assignments
- Guidance on how Google Workspace differs when nested group expansion is required
👉 Read WorkOS's analysis of Azure Entra nested groups and Directory Sync limitations →
Azure Entra nested groups and SCIM sync: what breaks in practice?
Explore further
06/06/2026 12:11 pm
Nested group expansion is a governance assumption, not just a connector feature. Entra-to-SCIM provisioning works only when teams assume group membership is already flat enough to transport. That assumption fails when access is inherited through child groups because the sync boundary strips the hierarchy away. The implication is that identity governance must distinguish between source-directory structure and provisioned entitlement state before it relies on either for access decisions.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- Another finding from the same research is that organisations maintain an average of 6 distinct secrets manager instances, which fragments control and makes policy consistency harder to prove.
A question worth separating out:
Q: What is the best way to handle nested groups in Directory Sync?
A: Use the simplest model that matches your operating reality. Flatten group membership when possible, assign child groups directly when hierarchy is limited, and use Microsoft Graph reconciliation only when you can support a second identity pipeline. The right choice depends on how much hierarchy the application truly needs.
👉 Read our full editorial: Azure Entra nested groups break SCIM provisioning expectations
