Directory.ReadWrite.All

What Directory.ReadWrite.All Actually Grants

Directory.ReadWrite.All is a broad application permission, so the core issue is not simple read access but tenant-wide directory modification authority. In practice, it can let an app enumerate and change directory objects that underpin access, collaboration, and administration.

Because the permission applies at the application layer, the main security question is whether the app truly needs directory-wide authority or can be redesigned around a narrower permission set. The larger the scope of directory objects, the more careful the approval and review process should be.

Why This Permission Is So Sensitive

This permission is sensitive because directory data is a control plane for identity and access. If abused, it can be used to change users, groups, service principals, app role assignments, or related settings that affect who can get in and what they can do.

That makes it materially different from ordinary data access. A compromised app with this entitlement can become a pathway to privilege escalation, persistence, or broad administrative disruption rather than just data exposure.

NHIMG’s how to find high-privilege Microsoft Graph application permissions is useful here because this permission belongs in the same class of high-impact Graph entitlements that deserve active review and tiering.

How Organisations Should Evaluate Exposure

Exposure review starts with inventory. Teams should know which enterprise applications, service principals, and automation jobs hold this permission, then determine whether those apps are internet-facing, externally callable, or integrated into critical workflows.

The next question is consent provenance. If the permission was granted through admin consent, inherited through a platform integration, or added long ago and forgotten, the organisation should treat that as a review trigger. Vendor documentation and Microsoft Graph permission references should be used to confirm exactly what the app can do before any change is made.

Review should also consider whether the app’s actual behaviour matches the entitlement. A low-function automation task with directory-wide write access is a common sign of overpermissioned design rather than legitimate need.

Containment, Monitoring, and Cleanup

When the permission cannot be removed immediately, the safest response is to reduce the blast radius around the application itself. That usually means limiting who can administer the app, constraining where it can run, and enforcing strong secret or certificate hygiene around the credentials it uses.

Monitoring should focus on directory mutations that should be rare, such as sudden changes to groups, service principals, app registrations, or user properties. If suspicious activity is detected, review the app’s recent sign-ins, consent changes, token use, and any new role or ownership assignments tied to it.

After remediation, organisations should verify that no persistence was established through newly created credentials, delegated ownership, or backdoor directory objects. For a permission this powerful, post-change review matters almost as much as the permission removal itself.

Risk and Threat Considerations

Directory.ReadWrite.All is attractive to attackers because it can turn one compromised application into a tenant-level modification path. The danger is not only data theft, but also the ability to alter directory state in ways that support persistence, privilege escalation, or follow-on access.

Failure mechanism: If an app credential, token, or deployment pipeline is compromised, the attacker may use the permission to create or modify directory objects, add privileged assignments, or weaken identity controls without needing a user’s interactive session.

Impact: The result can be broad identity compromise, altered access paths, and difficult-to-detect administrative tampering across the directory.

Practitioner Guidance

Why practitioners should care: Treat this permission as a privileged application entitlement, not as a routine integration setting. Its approval should require a clear business case, explicit ownership, and periodic review against actual app behaviour.

What to watch for: Pay close attention to apps with this permission that are rarely used, externally managed, or able to act without human oversight. Those are the cases most likely to become orphaned, overtrusted, or abused.

Practitioner takeaway: If the app does not truly need directory-wide write capability, remove the permission and replace it with the narrowest viable alternative.

Related resources from NHI Mgmt Group

• Why do Active Directory service accounts complicate zero trust programs?
• How should security teams govern Active Directory service accounts?
• What is the difference between direct access and effective access in Active Directory?
• Why do Active Directory service accounts create more risk than their labels suggest?