Directory.ReadWrite.All is a Microsoft Graph permission that lets an application read and write directory data in Microsoft Entra ID: users, groups, devices, and other directory objects. Microsoft's short description is "Read and write directory data". It comes in two forms, an application permission that works with no user present and a delegated permission that acts on behalf of a logged-in user, and admin consent is required for both. Whoever holds it can change the directory itself, so a lean security team should be able to list every holder on demand.
What Directory.ReadWrite.All grants, and what it does not
According to the Microsoft Graph permissions reference, the application permission (id 19dbc75e-c2e2-444c-a770-ec69d8559fc7) lets the app read and write directory data such as users and groups without any user session. Microsoft's Caution note on the directory permissions says they grant broad access to Entra ID resources (users, groups, devices), that resource-specific permissions should be chosen where possible, and that directory permissions might be deprecated in the future.
The limits matter as much as the scope. Microsoft states that the application variant does not allow user or group deletion, and that the delegated variant (id c5366453-9fb0-48a5-a156-24f0c49a4b84) does not allow deleting users or groups or resetting user passwords. An app holding this permission cannot delete users or groups, and the delegated variant cannot reset passwords either. It can create and modify users and groups, which is enough to change who belongs to a privileged group or to plant an account that looks routine.
Delegated versus application scope
- Delegated: the app acts on behalf of the user who is logged in and can only do what that user could do. A grant used by a helpdesk technician is bounded by the technician's rights; a grant used by a Global Administrator is not.
- Application: the app acts as itself with no user present, and the access applies to the whole directory rather than to one person's rights. This is the variant held by a service principal running unattended.
Admin consent is required for both. Under the built-in microsoft-user-default-legacy consent policy, users can consent to any permission that does not require admin consent, but Directory.ReadWrite.All is never in that set. Every grant of it in your tenant was approved by an administrator, so every grant has an audit trail worth reading.
Why attackers want it
A permission granted to a service principal is durable and non-interactive. Microsoft's guidance on illicit consent grants describes the pattern: the attacker registers an application that requests access, tricks someone into granting consent, and from then on the application has account-level access without needing an account in the organization. Microsoft is explicit that the normal remediation steps, resetting passwords or requiring MFA, are not effective because the malicious app is external to the organization. Directory.ReadWrite.All is the write-capable version of that problem: an attacker who obtains it through a phished admin consent or a leaked client secret on a legitimate app can add group members, modify user attributes, and register new objects with no user sign-in for your user-focused controls to catch. The access persists until the grant itself is revoked.
There is also a legacy trap. Before December 3, 2020, granting the Directory.ReadWrite.All application permission also granted the Directory Writers directory role to the app, and revoking the permission does not remove that role. Microsoft says that to remove such an app's directory access completely, customers must also remove any directory roles granted to it. The service update that ended this behaviour completed for all customers on January 11, 2021. If your tenant has apps consented before then, check their role assignments, not just their permissions.
How it compares with neighbouring permissions
Microsoft's permissions reference does not rank permissions by risk tier, but its descriptions and Caution notes draw the lines.
| Permission | What Microsoft says it grants | Admin consent | Microsoft's Caution |
|---|---|---|---|
| Directory.ReadWrite.All | Read and write directory data (users, groups, devices); no user or group deletion | Required, both variants | Broad access; choose resource-specific permissions where possible |
| RoleManagement.ReadWrite.Directory | Read and manage directory RBAC settings, including adding and removing members of Entra roles and the PIM for Entra roles APIs | Required, both variants | Allows granting authorization: the app can grant additional privileges to itself, other apps, or any user |
| AppRoleAssignment.ReadWrite.All | Manage permission grants for application permissions to any API, including Microsoft Graph, and app assignments for any app | Required, both variants | Allows granting authorization, same as above |
| Application.ReadWrite.All | Create, read, update, and delete applications and service principals; manage app role assignments except those exposed by Microsoft Graph; no management of delegated grants | Required, both variants | None quoted |
| Mail.ReadWrite | Create, read, update, and delete mail (all mailboxes for the application variant, the user's own mailbox for delegated); no permission to send | Required for the application variant only | None quoted |
Directory.ReadWrite.All is described in terms of directory data. RoleManagement.ReadWrite.Directory and AppRoleAssignment.ReadWrite.All are described as permissions that allow granting authorization, which puts them on the escalation side of an attack path. Directory.Read.All is the read-only form of the same directory scope, and resource-specific permissions such as User.ReadWrite.All or Group.ReadWrite.All confine an app to one object type, which is the direction Microsoft's Caution points. Mail.ReadWrite is on the list for a different reason: its delegated variant needs no admin consent, so under the legacy consent policy an ordinary user can hand an app read and write access to their own mailbox.
How to find every app that holds it
Application permission grants to Microsoft Graph are stored as app role assignments on the Microsoft Graph service principal in your tenant. Microsoft's permissions reference notes that all Graph permissions can be enumerated from that service principal, whose appId is 00000003-0000-0000-c000-000000000000, using an account with at least Application.Read.All. The same object lists who holds each app role. In Microsoft Graph PowerShell:
Connect-MgGraph -Scopes "Application.Read.All", "Directory.Read.All"
# The Microsoft Graph service principal in your tenant
$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
# Application permission: Directory.ReadWrite.All
$roleId = "19dbc75e-c2e2-444c-a770-ec69d8559fc7"
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $graph.Id -All |
Where-Object { $_.AppRoleId -eq $roleId } |
Select-Object PrincipalDisplayName, PrincipalId, CreatedDateTimeEach row is a service principal that can write to your directory with no user present. Confirm the GUID against the permissions reference before you rely on the output. Delegated grants live in a different object, the OAuth2 permission grant, and are matched by scope name:
# Delegated permission: Directory.ReadWrite.All
Get-MgOauth2PermissionGrant -All |
Where-Object { $_.Scope -match "Directory\.ReadWrite\.All" } |
Select-Object ClientId, ConsentType, PrincipalId, ScopeMicrosoft's illicit consent grant guidance explains the result: a ConsentType of AllPrincipals means the client app can access everyone's content in the tenant. Native Microsoft 365 apps need it; every non-Microsoft app with it deserves a close review. Microsoft's triage cues are permissions containing "Read", "Write", or "All", consents granted by high-value users, and client display names that are misspelled, very bland, or hacker-sounding. For organizations with many registered apps, Microsoft's stated best practice is to review consent grants weekly.
What to do when you find one you did not expect
- Investigate the permissions the app requested, then review Entra audit logs for the app's activity and for sign-ins by users authorized to use it (Microsoft's recommended first step in its consent phishing guidance).
- Revoke the grant itself. Microsoft's options are to remove the app assignment for the user in the Entra admin center, revoke the OAuth consent grant with
Remove-MgOauth2PermissionGrant, revoke the app role assignment withRemove-MgServicePrincipalAppRoleAssignment, or disable sign-in for the affected account as a short-term measure. - For apps consented before December 3, 2020, also look for and remove the Directory Writers role.
- Do not stop at a password reset or MFA enforcement; Microsoft states that neither remediates an illicit consent grant. Do not turn off integrated applications tenant-wide either; Microsoft explicitly does not recommend it because it blocks all users from consenting to any app.
The broader runbook is in our illicit consent grant entry and in OAuth consent response. If the holder is a legitimate app with a leaked credential, see how to find expiring client secrets in Entra ID. If it also carries a directory role, see service principals with Global Administrator.
Where Orbitra fits
Orbitra maps human and non-human identities (service principals, app registrations, OAuth grants, managed identities) in one graph with blast radius traversal, so a service principal holding Directory.ReadWrite.All appears beside the users and groups it can reach, and roughly 40 percent of its deterministic detection rules target applications, service principals, consent grants, and app credentials. When a grant has to go, the response comes from an allowlisted catalog of more than two dozen governed response actions, and Orbitra independently re-reads Microsoft after supported response actions to verify the final state. In Recommend mode, your team executes the response; in Approve mode, a named person signs off before Orbitra executes. Connect Microsoft in minutes and start read-only.
Related terms
Sources
- Microsoft Graph permissions reference (Microsoft Learn, checked September 2026)
- Detect and remediate illicit consent grants (Microsoft Learn, checked September 2026)
- Protect against consent phishing (Microsoft Learn, checked September 2026)
- Configure how users consent to applications (Microsoft Learn, checked September 2026)