Entra ID Built-in Roles
Every Microsoft Entra ID built-in directory role with its template ID, privileged classification and the description Microsoft gives each allowed resource action, from the official built-in roles reference.
| Role ▲ | Permissions ▲ | Template ID ▲ |
|---|
About Microsoft Entra ID built-in roles
Entra ID roles govern the directory itself - users, groups, applications, devices, authentication methods and the Microsoft 365 services that trust it. They are a different system from Azure RBAC: an Entra role never grants access to a subscription or a resource group, and an Azure role never lets you reset a password or consent to an application. The one bridge between them is the Global Administrator's ability to elevate access to User Access Administrator at the root management group, which is a deliberate, auditable action.
Template ID, not role ID
Each built-in role has a template ID that is identical in every tenant, and a role definition ID that is only stable within one tenant. Automation should reference the template ID - that is the GUID listed here - so the same script works against any directory.
Roles are not Graph API permissions
The microsoft.directory/... strings listed against each role are Entra RBAC resource actions, not Microsoft Graph scopes such as Directory.Read.All. The two models are parallel and Microsoft publishes no mapping between them: a Graph permission decides what an application's token may attempt, while the role decides what the identity may do in the directory, and many operations need both. A call that fails with Authorization_RequestDenied despite the correct scope is almost always missing the role. The full scope catalog is on the Microsoft Graph permissions page.
Privileged roles
Microsoft flags a role as privileged when it can manage access to the directory or to Microsoft 365 services, directly or by proxy: creating credentials on an application, resetting an administrator's password, or assigning other roles. Those roles are the ones worth putting behind Privileged Identity Management with approval and time limits, and worth alerting on when assigned permanently.
Practical guidance
- Prefer a narrow role over Global Administrator; most day-to-day tasks are covered by a specific administrator role listed here.
- Scope role assignments to an administrative unit when the role supports it, so a helpdesk role does not reach the whole directory.
- Keep at least two, and no more than a handful, of permanent Global Administrators, and exclude a break-glass account from Conditional Access.
- Read the permissions rather than the name: several reader-sounding roles can read sensitive data, and some administrator roles are narrower than they sound.
Where this data comes from
The dataset is rebuilt several times a day from Microsoft's generated Entra ID roles reference, so a role or permission added upstream appears here without anyone editing this page.