Custom Entra ID roles: least privilege when built-in roles are too broad
To let a team manage a few applications, organisations often grant Application Administrator, or even Global Administrator "just to make it work". Custom roles allow for far finer control, provided you know which permissions are genuinely sensitive.
When built-in roles are no longer enough
Entra ID offers several dozen built-in roles. They cover most needs, but often too broadly. Application Administrator, for example, can manage every app registration and enterprise application in the tenant, including their secrets and certificates. For a team that only looks after one business portal, that is out of proportion.
A custom role makes sense when:
- the need is limited to a few specific actions, for instance updating an application's properties without touching its credentials;
- the scope is limited to an identifiable set of objects;
- the closest built-in role grants dangerous actions unrelated to the need.
Designing the role
A custom role is a set of permissions such as microsoft.directory/applications/basic/update. Not every directory permission is available to custom roles: the supported list covers applications, users, groups and devices among others, and it changes over time. Check Microsoft's documentation for its current state.
The method we recommend:
- Describe the actual tasks, in business terms, with the team concerned.
- Map each task to permissions, starting from scratch rather than from a copied built-in role.
- Systematically leave out sensitive permissions that are not strictly required.
- Test the role on a dedicated account before assigning it.
Permissions that lead further. Updating an application's credentials (microsoft.directory/applications/credentials/update) or its owners lets you authenticate as that application. If the application holds high Microsoft Graph permissions, the custom role becomes a privilege escalation path. Keep these permissions for tightly controlled scopes.
Narrowing the scope
Every role, built-in or custom, is assigned at a scope. There are three levels:
| Scope | Use |
|---|---|
| Tenant | The permission applies to every relevant object. Keep it for genuinely tenant-wide needs. |
| Administrative unit | The permission only covers users, groups or devices in the unit, such as a subsidiary or a country. |
| Resource | The permission only covers one application: an app registration or an enterprise application. |
Resource scope is often the right answer for application teams: a custom application management role assigned on that one application is a far better option than a tenant-wide role. For sensitive objects, restricted management administrative units even prevent tenant administrators from changing them, unless they hold a role on the unit itself.
Licensing and governance
Creating and assigning custom roles requires at least Microsoft Entra ID P1; check the current licensing terms. Once created, these roles need the same governance as any other:
- assignment through PIM, as eligible, when the role includes sensitive permissions;
- a clear description of the role's purpose and owner;
- periodic permission reviews, since roles tend to grow with each new request;
- assignment to role-assignable groups rather than individual users when the team is stable.
What an audit checks
- The list of custom roles, their permissions and their justification.
- Permissions over application credentials or owners, and which applications they reach.
- Assignment scopes: tenant, administrative unit or resource.
- Permanent assignments outside PIM.
- Broad built-in role assignments that could be replaced by a custom role.