Someone in your tenant consented to an application you do not recognize, or a legitimate app turned out to hold far more than it needs: Directory.ReadWrite.All, mailbox read and write across the organization, or the right to grant itself more permissions. The account fixes you reach for first will not help. This page is the response sequence for that moment, written for a small security team on Microsoft 365 Business Premium or E3. Every Microsoft behavior it relies on is listed under Sources; terms are defined in our glossary and the wider playbooks live in the guides.
Why a password reset and MFA do not fix it
In an illicit consent grant attack, the attacker registers an application in Microsoft Entra ID that asks for access to data such as contacts, email, or documents, then tricks a user into granting it consent, by phishing or by injecting code into a trusted website. Once consent is granted, the application has account-level access to that data without needing an account in your organization. That is why Microsoft states that normal remediation steps such as resetting passwords or requiring MFA are not effective against this attack: the application is external to the organization, so nothing you do to the user's credentials touches it.
Consent phishing works because the Microsoft identity platform hosts the consent screen. The prompt lists every permission the app will receive, but a legitimate provider hosts it, so people accept. The grant is the compromise, and the grant, or the app role assignment behind it, is what has to be removed.
Which permissions make a consent urgent
Microsoft's Graph permissions reference does not assign risk tiers. What it does publish is which permissions require admin consent and, for a few, a Caution callout. Three permissions belong at the top of your list.
| Permission | What the application can do | Admin consent | Why it matters |
|---|---|---|---|
Directory.ReadWrite.All | Read and write directory data such as users and groups; the application variant works without a signed-in user. Does not allow deleting users or groups. | Required for both variants | Microsoft's Caution: directory permissions grant broad access to Entra ID resources (users, groups, devices), and resource-specific permissions should be chosen where possible. |
AppRoleAssignment.ReadWrite.All | Manage permission grants for application permissions to any API, including Microsoft Graph, and application assignments for any app. | Required for both variants | Microsoft's Caution: it allows granting authorization, so an application holding it can grant additional privileges to itself, other applications, or any user. |
Mail.ReadWrite | Application variant: create, read, update, and delete mail in all mailboxes. Delegated variant: the same in the signed-in user's mailbox. Neither includes sending mail. | Required for the application variant only | The delegated variant needs no admin consent, so under the built-in microsoft-user-default-legacy policy an ordinary user can hand an app read and write access to their own mailbox. |
RoleManagement.ReadWrite.Directory, which lets an application add and remove members of Microsoft Entra roles, carries the same Caution about granting authorization. An app holding any of these is a service principal with privileged reach, whether the consent was malicious or merely careless. One historical wrinkle: before December 3, 2020, granting the Directory.ReadWrite.All application permission also assigned the Directory Writers directory role, which is not removed when the permission is revoked, so for an older app remove any directory roles it holds as well.
Step 1: confirm what was granted, to whom, and by whom
The indicator of compromise is a questionable "Consent to application" activity in the Microsoft Purview audit log, searched from the Microsoft Defender portal. Check whether IsAdminConsent is True: that means someone with Global Administrator access may have granted broad, tenant-wide access. Two cautions from Microsoft: entries can take from 30 minutes up to 24 hours to appear in search results, and determining the full scope (affected users, time window, permissions held) relies on mailbox and activity auditing having been turned on before the attack.
Microsoft lists three ways to inventory consents: per user in the Entra admin center, a PowerShell script that dumps all OAuth consent grants and apps for all users to a CSV (fastest; requires the Microsoft Graph PowerShell SDK and Global Administrator), or asking users to check their own apps at My Apps. In the export, a ConsentType of AllPrincipals means the app can access everyone's content in the tenant; native Microsoft 365 apps need it, and every non-Microsoft app with it should be reviewed carefully. Microsoft's triage cues are "Read", "Write", or "All" permissions, consents granted by high-value users, and display names that are misspelled, very bland, or hacker-sounding. Before you revoke, record the permissions the app requested and review the Entra audit logs for the app's activity and for sign-ins by users authorized to use it. That record is your scope.
Step 2: revoke the grant, the app role assignment, or both
Microsoft lists these remediation options for an illicit consent grant:
- Remove the app assignment for the user in the Entra admin center (Users, then the user, then Applications, then the app, then Remove).
- Revoke the OAuth consent grant, which holds delegated permissions, with
Remove-MgOauth2PermissionGrant. - Revoke the app role assignment, which holds application permissions granted to the service principal, with
Remove-MgServicePrincipalAppRoleAssignment. - Disable sign-in for the affected account as a short-term measure.
- Turn off integrated applications tenant-wide, which Microsoft explicitly does not recommend because it blocks all users from consenting to any app and severely impairs productivity with non-Microsoft applications.
Match the removal to the grant type: a user who consented for themselves created a delegated grant scoped to that user, an administrator who consented for the organization created an AllPrincipals grant, and an application permission created an app role assignment on the service principal. A risky app often has more than one, so revoke each and check for directory roles too. If the consenting account was itself an administrator, run it through the compromised admin account sequence as well; the consent may be the persistence rather than the entry point.
Step 3: verify it is gone
A command that returned without error is not proof. Read the state back: list the service principal's oauth2PermissionGrants and appRoleAssignments again and confirm the removed entries are absent and the app holds no directory roles. Then watch the Entra audit and sign-in logs for the application after your revocation timestamp. Microsoft's description of what happens when it disables a flagged app is the pattern to plan for: new token and refresh token requests are denied, but existing access tokens remain valid until they expire. Treat your own revocation the same way: the grant is gone the moment you remove it, the access it already issued winds down over the token lifetime, and only the logs tell you when it stopped.
Capture the evidence while it is there: the consent audit entry, the permissions the app held, the users affected, the removal commands with timestamps, and the read-back showing the grant absent. An insurer or auditor will ask for exactly this sequence; see privileged access evidence for cyber insurance and containment verification.
Where Orbitra fits
Orbitra puts human and non-human identities (service principals, app registrations, OAuth grants, managed identities) in one graph with blast radius traversal, so a consent grant appears next to the roles, groups, and Azure resources the application can reach. Revoking an OAuth grant or an app role assignment is one of more than two dozen governed response actions; every response comes from an allowlisted catalog and is pre-authorized by tenant policy, not decided by a model. In Recommend mode, Orbitra proposes the response and your team executes it. In Approve mode, a named person signs off before Orbitra executes. Orbitra independently re-reads Microsoft after supported response actions to verify the final state, and every response produces an attributable evidence receipt with a SHA-256 content fingerprint.
Roughly 40 percent of Orbitra's detection rules target applications, service principals, consent grants, and app credentials. Orbitra tells you which steps are permanent before you approve them; a revoked OAuth grant or app role assignment can be restored within the undo window (24 hours by default), and the restore creates a new grant object with a new id. Every customer tenant uses Recommend or Approve today, and Autonomous mode has never executed in a customer tenant. Orbitra works alongside Microsoft native controls and at any Microsoft license level. See identity response on Business Premium and E3 and lean security teams.
Close the door afterwards
Microsoft recommends configuring user consent so users can only consent to apps from verified publishers or developed by the organization, and only for low-risk permissions the admin selects. The admin consent workflow gives users who cannot consent a way to request approval: the request is emailed to designated reviewers, who act on it, and the user is notified of the outcome. Designation does not elevate a reviewer's privileges, and only Global Administrators can approve requests for apps requesting Microsoft Graph application permissions. Turning the workflow on requires the Global Administrator role. Beyond that: routinely audit apps and consented permissions for least privilege, do not trust app names or domain URLs as proof of authenticity, review consent grants weekly in tenants with many apps and users, and remind users they can report a suspicious prompt with the "Report it here" link on the prompt itself.
Related reading: when a service principal holds Global Administrator, finding expiring client secrets, app registration, non-human identity, and identity blast radius.
Sources
- Detect and remediate illicit consent grants (Microsoft Defender for Office 365), checked September 2026
- Protect against consent phishing, checked September 2026
- Microsoft Graph permissions reference, checked September 2026
- Configure the admin consent workflow, checked September 2026
- Configure how users consent to applications, checked September 2026
Frequently asked questions
Does resetting the user's password remove the app's access?
No. Microsoft states that normal remediation steps such as resetting passwords or requiring MFA are not effective against an illicit consent grant, because the malicious application is external to the organization. The consent grant or the app role assignment itself has to be revoked, with Remove-MgOauth2PermissionGrant, Remove-MgServicePrincipalAppRoleAssignment, or by removing the assignment in the Entra admin center.
What is the difference between an OAuth consent grant and an app role assignment?
A delegated permission that a user or an administrator consented to is stored as an OAuth2 permission grant; a ConsentType of AllPrincipals means the app can act for everyone in the tenant. An application permission, which works without a signed-in user, is stored as an app role assignment on the app's service principal. Microsoft lists a separate removal command for each, and a risky app often has both.
Can an ordinary user give an app read and write access to their mailbox without an admin?
Yes, under the built-in microsoft-user-default-legacy policy. The delegated Mail.ReadWrite permission does not require admin consent, and that policy lets any user consent to any permission that does not require admin consent, for any application. Only a stricter user consent setting changes that.
Should I turn off integrated applications to stop this?
Microsoft lists it as an option and explicitly does not recommend it: it blocks all users from consenting to any app and severely impairs productivity with non-Microsoft applications. Revoke the specific grant, then tighten user consent so users can only consent to apps from verified publishers or your own organization, and only for low-risk permissions you select.
How do I know the app's access has actually stopped?
Read the state back rather than trusting the command: list the service principal's OAuth2 permission grants and app role assignments again and confirm the removed entries are absent, then watch the Entra audit and sign-in logs for the application after your revocation timestamp. Microsoft's own description of disabling a flagged app notes that new token requests are denied but existing access tokens remain valid until they expire, so plan on a wind-down rather than a hard stop.