Application consent in Microsoft Entra ID, and the permissions people over-grant

Illicit consent is one of the more effective attacks against a Microsoft 365 tenant, and it does not involve stealing a password. The attacker registers an application, sends a legitimate-looking consent prompt, and a user grants it access to their mail and files. The resulting access survives a password reset, because it is not a password — it is a consented permission with its own refresh token.

The defence is mostly configuration you can apply this week, plus an understanding of the two permission models that is worth getting precisely right.

The threat model

An application in Entra ID can obtain access in two fundamentally different ways.

Delegated permissions act on behalf of a signed-in user. The effective access is the intersection of what the permission allows and what the user can already do. An application with Mail.Read delegated, used by an ordinary employee, can read that employee’s mail — not everyone’s.

Application permissions act as the application itself, with no user in the picture. There is no intersection and no user to bound it. An application with Mail.Read as an application permission can read every mailbox in the tenant, for as long as the grant exists.

Same permission name. Radically different exposure. This is the single most important distinction in the whole subject, and it is the one that gets missed when somebody approves a consent request by reading the permission name alone.

Application permissions always require administrator consent. Delegated permissions may or may not, depending on the permission and your consent policy — and that is where the attack gets its foothold.

Exposure: what to check in your own tenant

Before changing anything, find out what has already been granted. Three questions, in order of how much they should worry you.

Which applications hold application permissions, and which ones? These are your tenant-wide grants. Anything with .ReadWrite.All against mail, files, or directory objects is effectively a second administrator. Expect to find applications nobody can identify.

Which applications hold Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, or AppRoleAssignment.ReadWrite.All? These are privilege-escalation permissions. An application that can assign app role assignments can grant itself anything else. Treat them as Tier 0.

Who has consented to what, individually? User consent grants accumulate silently. A single user granting Files.ReadWrite to an unknown application is a small exposure; five hundred such grants across the tenant is a governance failure.

You can read all of this from the enterprise applications view in the admin centre, or query it with Microsoft Graph, which is the practical route for anything beyond a small tenant. Whichever you use, export the result and keep it — the value is in comparing this month’s list against last month’s, not in reading it once.

Assessment: reading a consent request properly

When a request reaches you for approval, four questions decide it.

1. Delegated or application permission? Application permissions need a much higher bar and a named owner.
2. What is the actual scope of the permission? .All means the tenant. Mail.Read delegated is one user’s mail; Mail.Read as an application permission is all of it. Microsoft Graph offers Mail.ReadBasic and resource-specific consent in some scenarios — the narrower option frequently does the job.
3. Who is the publisher, and are they verified? Publisher verification is a real signal. Its absence is not proof of malice, but it changes the burden of proof.
4. Is the permission proportionate to what the application does? A meeting-scheduling tool asking to read all files in the tenant is not a configuration question. It is an answer.

The most common over-grant I see is .ReadWrite.All where .Read.All would do, and tenant-wide application permissions where delegated permissions scoped to a small group would do. Both usually happen because the vendor’s setup guide asks for the broadest option and nobody pushed back.

Hardening: the configuration that closes the gap

Restrict user consent. The default position in many tenants allows users to consent to applications for permissions classified as low impact. Tightening this to “do not allow user consent”, or to a restricted set of permissions from verified publishers, removes the illicit consent attack in its usual form. This is the highest-value change in the article.

Enable the admin consent workflow. If you block user consent and provide no route, people route around you — usually by asking an administrator to click the button without context. The workflow gives users a way to request, gives reviewers the request in a queue with the permissions visible, and produces a record. Blocking consent without enabling the workflow generates exactly the rushed approvals you were trying to prevent.

Name the reviewers, and give them the four questions above. The workflow is only as good as the person reading the request. A reviewer who approves everything has added latency, not control.

Use application-specific assignment. Where an application only needs to serve one department, require user assignment and assign the group. Combined with delegated permissions this bounds exposure twice over.

Review consent grants on a schedule, and revoke what is unused. Grants are permanent until removed, and applications outlive the projects that introduced them.

Restrict who can register applications. By default, users can register applications in many tenants. That is a reasonable developer convenience and a poor default for most organisations. If you leave it on, understand that any user can create the application half of a consent attack from inside.

Detection

Alert on new application permission grants. These should be rare and always deliberate. Every one is a tenant-wide capability being created.

Alert on additions to privileged permissions — anything that can write directory objects, assign roles or grant app role assignments.

Watch for consent grants to newly registered applications, particularly ones registered recently and consented to by several users in a short window. That pattern is close to a signature for a consent phishing campaign.

The audit logs record consent operations with the application, the permissions and the principal who consented. Route the high-impact subset somewhere a person reads, rather than relying on a periodic review to notice something that happened in March.

Validation

Confirm the controls do what you think:

• Sign in as an ordinary test user and attempt to consent to an application requiring a permission outside your allowed set. It should be refused and should offer the request path.
• Submit a request through the admin consent workflow and confirm it reaches a reviewer.
• Revoke a test grant and confirm access actually stops. Token lifetime means this is not always instant, and knowing the delay matters during an incident.
• Re-run your inventory of application permissions and confirm the list matches what you expect, with a named owner for each.

Responding to a bad grant

If you find a malicious or mistaken consent, the sequence is: revoke the grant, disable the service principal, revoke the affected users’ refresh tokens, and then establish what was accessed while the grant existed. Revoking the grant alone does not end sessions that are already running.

Then treat it as an incident rather than a tidy-up. A consent grant is an access path, and the question of what was read while it existed is a real one — particularly for mail and files.

Honest limits

Consent controls do not help against an application you approved and should not have. Review quality is the control there, and no configuration substitutes for it.

They also do not cover the credentials held by legitimate applications. A service principal’s client secret or certificate is a credential with the application’s full permissions, and its expiry, storage and rotation are a separate problem — one that intersects directly with administrative tiering, because an application with directory write permissions belongs in Tier 0 whatever the diagram says.

Verification and limits

The delegated versus application permission model, administrator consent requirements, the admin consent workflow, user consent settings and consent audit logging were checked against current Microsoft documentation on 20 September 2026. The review questions and the assessment order are my own practice.

No tenant configuration was performed for this article. Restricting user consent changes what your users can do and will generate requests immediately — enable the admin consent workflow in the same change, and communicate it. Revoking an existing grant can break a working integration, so identify the owner before revoking anything you did not create.

References

• Configure how users consent to applications
• Configure the admin consent workflow
• Microsoft Graph permissions reference
• Investigate and remediate risky OAuth apps