Directory.ReadWrite.All is an application permission that allows an app to read and modify directory data through Microsoft Graph or a similar directory API. It can cover users, groups, and other directory objects, so access should be tightly governed, consented, and reviewed as a privileged application entitlement.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Directory-wide write access should be minimized to only what the app needs. |
| IA-5 — Authenticator Management | Compromise of app secrets or tokens turns this permission into a powerful abuse path. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Directory mutations and consent changes need review because they can indicate misuse of this permission. | |
| Recommendation — Limit the application to the narrowest directory permissions required for its function. Manage application credentials tightly and rotate or revoke them when abuse is suspected. Review directory and consent audit events for unexpected modifications tied to the app. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Application permissions with excessive directory authority are a direct overprivilege risk. |
| Recommendation — Reduce app permissions to the minimum viable directory scope. | ||
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?