Implementing ABAC in Entra ID: a step-by-step with dynamic groups

You know what ABAC is and want it working in Entra ID. This is the step-by-step. (New to the concept? Read What is ABAC in Microsoft Entra ID? first.) The practical engine behind ABAC in Entra ID is the dynamic group. This article shows, step by step, how to make ABAC concrete with membership rules, where the limits are, and how to build a working model without tearing down your existing structure.

TL;DR

• ABAC = access based on attributes like department, job title, location, and contract type.
• In Entra ID you implement ABAC with dynamic groups and their membership rules.
• Dynamic groups require Microsoft Entra ID P1.
• The rules are powerful, but there are limits: no nested groups for licensing, and attribute quality decides everything.
• Start with three to five rules and expand, not the other way around.

What ABAC means in practice

With RBAC you put someone in a group by hand. With ABAC you write a rule that says who belongs in the group, and Entra ID fills the group itself. When an attribute changes, membership adjusts.

An example. Instead of putting every new controller into the Finance-Reporting group by hand, you write:

user.department -eq "Finance" and user.jobTitle -contains "Controller"

Anyone who matches that rule now or later is in the group. When someone's job title changes, the membership appears or disappears on its own. No ticket, no manual work.

The building blocks in Entra ID

Entra ID gives you three mechanisms to build attribute-based access:

Mechanism	What for
Dynamic groups	Automatic membership based on membership rules. The backbone of ABAC in Entra.
Conditional access	Runtime decisions: only grant access if the device is compliant and the location checks out.
Custom claims	Application-specific logic that passes attributes to an app at sign-in.

For automating access and membership, the dynamic group is the most important. Conditional access and custom claims sit on top, for runtime control and app integration respectively.

Common membership rules

The membership rule is an expression over user attributes. A few patterns you will need often:

# Everyone in one department
user.department -eq "Sales"

# By department and job title
user.department -eq "IT" and user.jobTitle -contains "Engineer"

# By location
user.city -eq "Enschede"

# By contract type, permanent staff
user.employeeType -eq "Employee"

# Exclude all accounts without a department
user.department -ne null

The operators you use most are -eq, -ne, -contains, -startsWith, and the combinations with and and or. Keep the rules as simple as you can. A rule you no longer understand a year from now is a risk.

Where ABAC in Entra hits its limits

ABAC in Entra is strong, but it is not magic. Three limits to know up front:

1. Dynamic groups require P1. Without Microsoft Entra ID P1, dynamic membership rules are not available. Factor this into your business case.
2. No nested groups with group-based licensing. If you assign licenses through a group, members of a nested group do not count. The license applies only to direct members. This surprises many admins.
3. Attribute quality decides everything. Inconsistent job titles (Developer, Dev, Software Engineer) break your rules silently. A user falls outside the group without anyone noticing. Clean up your attributes before you roll out rules.

How to start

Not everything at once. A workable approach:

1. Pick three to five groups that cost the most manual work today (often department-wide access).
2. Check the underlying attributes for that population. Are department and job title correct?
3. Write the membership rules and place them alongside your existing manual groups first, not in place of them.
4. Compare for a few weeks who the rule picks up versus who was in the group manually.
5. Fix the differences, then expand to more groups.

Your existing manual groups keep working. ABAC is a layer on top, not a one-shot replacement.

FAQ

Does ABAC also work for my on-prem Active Directory? Through Entra Connect you sync attributes from AD to Entra ID. ServiceChanger applies the right set of groups and roles to both Entra ID and on-prem AD, so a hybrid environment falls under one model.

How many dynamic groups can I create? The practical limit is around 15,000 dynamic groups per tenant. For almost any organization that is more than enough.

How do I resolve conflicting rules? Two rules that touch the same user differently are resolved by making rules more specific, or by testing them on a small test group before you roll them out broadly. One source of truth per type of access keeps it manageable.

What does ServiceChanger do here exactly? ServiceChanger builds and maintains the ABAC model: it manages group and role memberships in Entra ID and on-prem AD based on your users' attributes. By default it reacts to the attributes already in your directory. If you want to connect your HR system for onboarding and offboarding, we build that as custom work using automation accounts and runbooks in Azure.

Further reading

• What is ABAC in Microsoft Entra ID? for the basics of the model.
• RBAC vs ABAC: when do you choose what? for the decision point between the two.
• Dynamic groups vs static groups for the engine behind ABAC.
• Automate Entra ID groups with attributes for a concrete step-by-step plan.
• Entra ID vs Active Directory in 2026 for how this works in a hybrid environment.

Next step

Want to roll out ABAC without drawing every membership by hand? ServiceChanger builds and maintains your ABAC model on Entra ID and on-prem AD. Book a demo or read the ABAC docs.