Dynamic groups, an IGA platform, or ServiceChanger: when to choose what

Granting access in a Microsoft environment can be done three ways that often get conflated: with native dynamic groups in Entra ID, with a full IGA platform, or with a rules layer on top of your existing structure like ServiceChanger. They do not all solve the same problem. This article puts the three approaches side by side: what they do well, where they stop, and when to choose which.

Approach 1: native Entra dynamic groups

A dynamic group is a group in Entra ID with a membership rule. You write one rule, for example on department or job title, and Entra fills the group automatically. It is built in, it needs Microsoft Entra ID P1, and for a single, well-bounded group it works fine.

You notice the limits as soon as you use it more broadly:

• One rule per group. Ten groups means ten separate rules, with no central view of which attribute grants which access.
• Cloud only. Dynamic groups manage your Entra groups, not your on-prem Active Directory groups. In a hybrid environment your AD side stays out of view.
• A group is either dynamic or manual. You cannot partly automate and partly assign by hand within the same group.
• No history. You see the current state, not who got access when and why.

For a few groups it is enough. The moment rule management becomes your main task, you hit the ceiling. We work out the difference between static and dynamic groups in Dynamic groups vs static groups in Entra ID.

Approach 2: a full IGA platform

IGA stands for Identity Governance and Administration. An IGA platform is built for governance at scale: access reviews and recertification, attestation, connectors to dozens of source systems, and a complete audit trail. For large, regulated organisations with many different applications, that is exactly what you need.

The trade-off is weight. An IGA rollout is usually a large project: configuring connectors, modelling roles, bringing in an implementation partner, and a price tag to match enterprise. For a Microsoft-centric IT organisation in the SMB or mid-market, that is often more than required. You end up paying for governance depth and connectors you do not use.

Approach 3: a rules layer like ServiceChanger

ServiceChanger sits between the two. It is not a replacement for Entra and not a heavy IGA platform, but a rules layer that drives access from your users' attributes, across Entra ID and your on-prem Active Directory, from a single rule set.

What that gives you in practice:

• One place where you see which attribute grants which set of groups and roles, with history.
• Cloud and on-prem in the same model. A PowerShell runbook applies the changes in AD, which sync back through your existing Entra Connect.
• Rules instead of scripts. You manage policy, not loose PowerShell.
• No shadow structure. Everything is applied directly in your tenant. Turn it off and everything stays as it is at that moment.

Where it deliberately stops: ServiceChanger is not a full governance suite with certification campaigns, and it does not integrate with your HR system for onboarding and offboarding as standard. That last part is available as custom work, built with automation accounts and runbooks in Azure. The underlying choice, rules on roles versus rules on attributes, is covered in RBAC vs ABAC.

When to choose what

• A handful of groups, cloud only, no need for an overview or history: native dynamic groups are enough.
• A large, regulated organisation with many different source systems and formal recertification: an IGA platform.
• A Microsoft-centric IT organisation that wants attribute-driven access across cloud and on-prem, with an overview and without a heavy IGA project: a rules layer like ServiceChanger.

The three are not mutually exclusive. Many organisations start with a few dynamic groups, run into the limits, and then choose a rules layer before a full IGA platform comes into play. The question is not which approach is best, but which one fits the scale and the type of management you have today.