Not every phishing attack wants your password. OAuth consent phishing in Microsoft 365 tricks a user into clicking Accept on a genuine Microsoft sign-in prompt that grants a malicious app access to their mail, files or calendar. No password is stolen, MFA is satisfied, and the access keeps working after a password reset.
The good news is that this is one of the easiest attacks to shut down. A handful of settings in Microsoft Entra ID decide who can approve apps, and most small business tenants have never looked at them.
How a consent phishing attack works
The attacker registers an app in their own Microsoft Entra tenant, gives it a convincing name and logo, such as “Secure Document Viewer” or something that looks like a known PDF tool, and sends a link. The link goes to a real Microsoft login page. After the user signs in, they see a consent screen listing the permissions the app wants.
If the user clicks Accept, the app receives tokens that let it act on the user’s behalf. Typical permissions requested are:
Mail.Read or Mail.ReadWrite: read or change every message in the mailbox.
Mail.Send: send mail as the user, perfect for invoice fraud.
Files.Read.All: read every file the user can reach in OneDrive and SharePoint.
offline_access: keep access without the user signing in again.
Because the user really did sign in to Microsoft, the sign-in looks normal. Because the access lives in an app consent rather than a session, revoking sessions and resetting the password does not remove it. You have to find and remove the consent itself.
Step 1: restrict who can consent to apps
By default, Microsoft Entra ID has historically allowed users to consent to apps for any permission that does not require an admin. Microsoft now recommends restricting that. Check what your tenant is set to.
Sign in to the Microsoft Entra admin center as at least a Privileged Role Administrator.
Go to Entra ID > Enterprise apps > Consent and permissions > User consent settings.
Choose one of the options below, then select Save.
Option
What it means
When to use it
Do not allow user consent
Every app needs an admin to approve it
Regulated businesses, or any tenant with a responsive IT team
Allow user consent for apps from verified publishers, for selected permissions
Users can approve only apps from verified publishers or your own tenant, and only for permissions you classify as low impact
Microsoft’s recommended option for most organizations
Allow user consent for apps
Users can approve any app for any permission that does not need an admin
Not recommended
For most of the businesses we support, I recommend the verified publisher option combined with the admin consent workflow below. Healthcare, legal and finance clients often go straight to “Do not allow user consent”.
Classify your low-impact permissions
The verified publisher option only works well if you tell Entra which permissions count as low impact. Under Consent and permissions > Permission classifications, add basic sign-in permissions such as openid, profile, email, offline_access and User.Read. Leave anything touching mail, files or the directory off the list.
Step 2: turn on the admin consent workflow
If users cannot consent, they need a way to ask. The admin consent workflow replaces the dead end with a Request approval button.
Go to Entra ID > Enterprise apps > Consent and permissions > Admin consent settings.
Set Users can request admin consent to apps they are unable to consent to to Yes.
Choose reviewers. Pick at least two people with the right admin roles.
Turn on email notifications and request expiry reminders, then save.
When a request arrives, the reviewer sees the app, the publisher and the permissions. A simple rule of thumb: if you have not heard of the publisher, the app is asking for mail or file access, and the user cannot explain the business need, deny it.
Step 3: find and remove consents that already exist
Changing the settings only affects future consent. Anything users approved in the past is still there. In the tenants I review, there is usually a long tail of forgotten apps: browser extensions, scheduling tools, free PDF converters and the occasional app nobody can identify.
Go to Entra ID > Enterprise apps > All applications and set the application type filter to show all apps, not just enterprise apps.
Sort by creation date and look for apps you do not recognize.
Open each unfamiliar app, select Permissions, and review both admin consent and user consent tabs.
Pay special attention to apps with mail, file or directory permissions, and to apps that only one or two users have consented to.
For anything suspicious, revoke the permissions, or delete the enterprise app from the tenant. Then check the Entra audit log for when consent was granted and by whom.
Microsoft Defender for Cloud Apps includes app governance, which flags overprivileged and unusual OAuth apps automatically. It is included in Microsoft 365 E5 and is worth turning on if you have it.
Step 4: teach users what a consent screen looks like
Settings do most of the work, but users should still recognize the warning signs. Add a short section to your security awareness training covering:
A Microsoft permissions screen appearing after clicking an email link is a red flag, especially for an app you have never used.
Check the app name and publisher. An unverified publisher is a reason to stop.
Any request to “read your mail” or “access all files” from an unfamiliar app should go to IT.
If you clicked Accept by mistake, report it right away. It can be undone quickly if IT knows.
A quick consent security checklist
User consent is restricted to verified publishers and low-impact permissions, or disabled.
Low-impact permission classifications are defined.
The admin consent workflow is on, with at least two reviewers.
Existing app consents have been reviewed in the last quarter.
Your incident runbook includes “check app consents” for every compromised account.
App governance is enabled if you have Defender for Cloud Apps.
No. The user signs in to the real Microsoft login page and completes MFA themselves. The attack works by getting them to grant permissions, not by stealing credentials. Restricting user consent is the control that stops it.
Does resetting the password remove a malicious app’s access?
No. App consents are independent of the password. You need to revoke the app’s permissions or remove the enterprise app from your tenant, then review what it accessed.
Will restricting user consent break apps people already use?
No. Changes to user consent settings only affect future consent. Existing grants keep working until you remove them, which gives you time to review the list and approve the legitimate ones properly.
Not sure which apps your users have already approved? Book a free Microsoft 365 security assessment and we will review your app consents and lock down the settings.
Not every phishing attack wants your password. OAuth consent phishing in Microsoft 365 tricks a user into clicking Accept on a genuine Microsoft sign-in prompt that grants a malicious app access to their mail, files or calendar. No password is stolen, MFA is satisfied, and the access keeps working after a password reset.
The good news is that this is one of the easiest attacks to shut down. A handful of settings in Microsoft Entra ID decide who can approve apps, and most small business tenants have never looked at them.
How a consent phishing attack works
The attacker registers an app in their own Microsoft Entra tenant, gives it a convincing name and logo, such as “Secure Document Viewer” or something that looks like a known PDF tool, and sends a link. The link goes to a real Microsoft login page. After the user signs in, they see a consent screen listing the permissions the app wants.
If the user clicks Accept, the app receives tokens that let it act on the user’s behalf. Typical permissions requested are:
Mail.ReadorMail.ReadWrite: read or change every message in the mailbox.Mail.Send: send mail as the user, perfect for invoice fraud.Files.Read.All: read every file the user can reach in OneDrive and SharePoint.offline_access: keep access without the user signing in again.Because the user really did sign in to Microsoft, the sign-in looks normal. Because the access lives in an app consent rather than a session, revoking sessions and resetting the password does not remove it. You have to find and remove the consent itself.
Step 1: restrict who can consent to apps
By default, Microsoft Entra ID has historically allowed users to consent to apps for any permission that does not require an admin. Microsoft now recommends restricting that. Check what your tenant is set to.
Entra ID > Enterprise apps > Consent and permissions > User consent settings.For most of the businesses we support, I recommend the verified publisher option combined with the admin consent workflow below. Healthcare, legal and finance clients often go straight to “Do not allow user consent”.
Classify your low-impact permissions
The verified publisher option only works well if you tell Entra which permissions count as low impact. Under
Consent and permissions > Permission classifications, add basic sign-in permissions such asopenid,profile,email,offline_accessandUser.Read. Leave anything touching mail, files or the directory off the list.Step 2: turn on the admin consent workflow
If users cannot consent, they need a way to ask. The admin consent workflow replaces the dead end with a Request approval button.
Entra ID > Enterprise apps > Consent and permissions > Admin consent settings.When a request arrives, the reviewer sees the app, the publisher and the permissions. A simple rule of thumb: if you have not heard of the publisher, the app is asking for mail or file access, and the user cannot explain the business need, deny it.
Step 3: find and remove consents that already exist
Changing the settings only affects future consent. Anything users approved in the past is still there. In the tenants I review, there is usually a long tail of forgotten apps: browser extensions, scheduling tools, free PDF converters and the occasional app nobody can identify.
Entra ID > Enterprise apps > All applicationsand set the application type filter to show all apps, not just enterprise apps.Microsoft Defender for Cloud Apps includes app governance, which flags overprivileged and unusual OAuth apps automatically. It is included in Microsoft 365 E5 and is worth turning on if you have it.
Step 4: teach users what a consent screen looks like
Settings do most of the work, but users should still recognize the warning signs. Add a short section to your security awareness training covering:
A quick consent security checklist
Microsoft’s reference for these settings is Configure how users consent to applications.
App consent is one of the areas we check in every Microsoft 365 security assessment. To build user awareness, see our security awareness training, and for ongoing review of app permissions, our managed security service.
Frequently asked questions
Does MFA stop OAuth consent phishing?
No. The user signs in to the real Microsoft login page and completes MFA themselves. The attack works by getting them to grant permissions, not by stealing credentials. Restricting user consent is the control that stops it.
Does resetting the password remove a malicious app’s access?
No. App consents are independent of the password. You need to revoke the app’s permissions or remove the enterprise app from your tenant, then review what it accessed.
Will restricting user consent break apps people already use?
No. Changes to user consent settings only affect future consent. Existing grants keep working until you remove them, which gives you time to review the list and approve the legitimate ones properly.
Not sure which apps your users have already approved? Book a free Microsoft 365 security assessment and we will review your app consents and lock down the settings.