Our hybrid setup creates and terminates accounts in on-premises Active Directory, then syncs them to Entra ID. SaaS access has usually been managed through AD security groups synced to Entra and assigned to enterprise apps.
There's a proposal to make SSO groups cloud-only because AD is considered legacy. Is that a sound reason on its own, and what should we check before changing the pattern?
Calling AD legacy isn't much of a technical justification by itself. The group location matters less than whether the access process works and can be managed consistently.
Ask for a documented decision covering who owns each group, how access is requested and approved, how membership is reviewed, and what happens when someone leaves. Also check that each group is actually assigned to the enterprise app and that the app grants the intended access or license. A group with SSO in its name doesn't establish any of that.
Cloud-only groups can be a perfectly reasonable choice, but changing the standard without explaining how those controls work makes support and audit work harder.
For an app that only lives in the cloud, a cloud group is a reasonable default. It avoids creating an on-prem group just to sync it upward, and may let you use Entra access packages or privileged access management for membership workflows.
Keep on-prem groups where a workload actually needs them. That doesn't mean migrate everything tomorrow, though. Check the existing provisioning and review processes first, and make sure the people supporting the app know which system manages membership.
Watch the sync direction. With the setup described, an AD group can sync to Entra, but a cloud-only group won't appear in AD because group writeback isn't in place. That matters if anything on premises relies on the group.
Also, the account lifecycle starting in AD doesn't automatically answer how cloud group membership is governed. Map the joiner, mover and leaver workflows for the proposed design rather than assuming the existing group process carries over unchanged.
I'd favor keeping the current pattern until there's an agreed replacement. One predictable place to manage access groups makes ownership and troubleshooting easier, especially when the team is still getting its bearings.
That doesn't make cloud-only groups wrong. It just means the exception should come with a clear owner and support procedure, not a vague claim that everyone is moving away from AD.
Raise it as a process question with your manager or whoever owns identity architecture. A short comparison of the current and proposed workflows is more useful than an argument over whether AD is old.
Point out the missing app assignment and ask who will own the standard. Then let the decision-makers decide. You can flag a support risk without taking responsibility for the whole strategy.
Answers are reviewed before publication.
Related Discussions