Purpose
Consent phishing is an OAuth/OIDC attack pattern where a user is tricked into granting a malicious or untrusted application access to organisational data such as email, files, Teams data, SharePoint, OneDrive, or Microsoft Graph resources.
The attacker may not need the user's password. If the user grants consent, the malicious application can receive tokens and may continue accessing data through delegated permissions and refresh tokens, depending on the permissions granted.
The objective of this control set is to reduce the risk of users granting unsafe application permissions and to establish a governed process for approving, monitoring, and removing OAuth application access.
1. Lock Down User Consent in Microsoft Entra ID
The most important control is to stop ordinary users from granting risky permissions to third-party applications.
Configure this in:
Microsoft Entra admin center → Enterprise applications → Consent and permissions → User consent settings
Recommended baseline:
| Setting | Recommendation |
|---|---|
| User consent | Do not allow unrestricted user consent |
| Safer alternative | Allow user consent only for apps from verified publishers and only for selected low-risk permissions |
| High-risk permissions | Require admin approval |
| Unknown or unverified publishers | Require admin approval |
| Tenant-wide consent | Restrict to trusted admin roles only |
Recommended position:
Users should only be allowed to consent to low-risk permissions for verified applications. Anything outside that pattern should go through an admin consent workflow.
2. Enable Admin Consent Workflow
Blocking all user consent without an approval route will frustrate business users and create pressure for exceptions.
Enable:
Microsoft Entra admin center → Enterprise applications → Consent and permissions → Admin consent settings
Turn on Admin consent workflow so that users can request approval for applications that require permissions they cannot approve themselves.
Recommended reviewer model:
| Reviewer | Responsibility |
|---|---|
| Identity or security team | Permission risk, publisher trust, application review, redirect URI review |
| Application owner | Business justification and application usage |
| Data owner | Approval for access to sensitive business data |
| Legal or privacy team, where needed | POPIA, GDPR, regulatory, or data-sharing implications |
The approval process should be documented and repeatable. Do not rely on informal Teams messages or ad hoc approval by Global Administrators.
3. Define a Consent Risk Model
OAuth permissions should be treated like privileged access. Some permissions are low risk, while others can expose significant organisational data.
A practical permission risk model:
| Risk Level | Example Permissions | Recommended Decision |
|---|---|---|
| Low | User.Read, basic sign-in and profile access |
User consent may be allowed if the publisher is verified |
| Medium | Calendar read, basic SharePoint or OneDrive read, Teams read permissions | Admin review required |
| High | Mail.Read, Mail.ReadWrite, Files.Read.All, Sites.Read.All, offline_access combined with data permissions |
Security and data-owner approval required |
| Critical | Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, Application.ReadWrite.All, broad Microsoft Graph application permissions |
Highly restricted; usually only approved for trusted internal or strategic applications |
The dangerous pattern is not only a single permission. The highest-risk combination is usually:
Broad data access + offline access + external publisher + many users.
4. Restrict Tenant-Wide Admin Consent
Tenant-wide admin consent is powerful because it grants an application access across the tenant, rather than only for one user.
Recommended controls:
| Control | Recommendation |
|---|---|
| Admin consent rights | Limit to specific trusted admin roles |
| Privileged role activation | Use Privileged Identity Management where available |
| Approval justification | Require documented reason for approval |
| Review frequency | Review tenant-wide consent grants regularly |
| Emergency approvals | Time-bound and reviewed after the fact |
Avoid allowing Global Administrators to casually approve app consent as part of normal operations.
Where possible, delegate consent review to appropriate roles such as:
- Cloud Application Administrator
- Application Administrator
- Privileged Role Administrator, where required
- Security Administrator or Security Reader for review and monitoring
5. Monitor OAuth Applications Continuously
Consent phishing protection is not a one-time configuration exercise. OAuth app permissions need continuous monitoring.
Monitor the following:
| What to Monitor | Why It Matters |
|---|---|
| Newly consented applications | Early detection of malicious or risky grants |
| Applications with high-privilege Graph permissions | Potential data exposure |
Applications with offline_access |
Risk of long-lived access |
| Applications consented by many users | Possible phishing campaign |
| Applications from unverified publishers | Higher trust risk |
| Unused applications with active permissions | Dormant attack surface |
| Applications with anomalous activity | Possible abuse after consent |
If licensed, use:
- Microsoft Defender for Cloud Apps
- App governance in Microsoft Defender for Cloud Apps
- Microsoft Entra audit logs
- Microsoft Entra sign-in logs
- Microsoft Sentinel, if available
6. Create Detection Rules and Alerts
At a minimum, alert on high-risk OAuth consent activity.
Recommended alert conditions:
| Alert Condition | Severity |
|---|---|
New application granted Mail.Read, Files.Read.All, Sites.Read.All, Directory.Read.All, or similar permissions |
High |
New application granted offline_access plus mail or file permissions |
High |
| Consent granted by a privileged user | High |
| Admin consent granted to an external application | High |
| Application from an unverified publisher receives consent | Medium to High |
| Spike in users consenting to the same application | High |
| Application accesses large volumes of email or files shortly after consent | Critical |
Recommended response actions:
| Action | Purpose |
|---|---|
| Suspend or disable the service principal | Stop further access |
| Revoke OAuth permission grants | Remove granted permissions |
| Revoke refresh tokens | Prevent continued token use |
| Review sign-in and audit logs | Determine scope and timeline |
| Identify affected users | Understand user exposure |
| Review data accessed | Assess business and privacy impact |
| Notify security, privacy, and business owners | Coordinate response |
7. Review and Clean Up Existing Consent Grants
Before changing policy, perform a tenant clean-up. Otherwise, new risk may be blocked while old risky grants remain active.
Review the following:
| Area | Action |
|---|---|
| Enterprise applications | Export applications, owners, publishers, permissions, and sign-in activity |
| OAuth permission grants | Identify delegated permissions granted by users |
| Admin consent grants | Identify tenant-wide grants |
| App registrations | Find ownerless, unused, or over-permissioned apps |
| Service principals | Remove stale applications and credentials |
| High-risk permissions | Revoke or reduce scope where possible |
Suggested clean-up categories:
| Category | Action |
|---|---|
| Unused applications | Remove or disable |
| Ownerless applications | Assign owner or remove |
| Unverified publishers | Review and restrict |
| High-risk permissions | Re-approve or revoke |
| Applications with no recent sign-ins | Remove unless business justification exists |
| Applications with broad Graph permissions | Review with data owner and security |
8. Educate Users on the Consent Screen
Users need to understand that the consent screen is an authorisation decision, not just a normal login prompt.
Train users to stop and report prompts that ask for permissions such as:
| Warning Sign | Why It Matters |
|---|---|
| “Read your mail” | The application may access mailbox content |
| “Read and write access to your files” | The application may access or modify OneDrive or SharePoint files |
| “Maintain access to data you have given it access to” | Usually indicates long-lived or offline access |
| Unknown publisher | Publisher trust is weak |
| Odd application name or logo | Common phishing tactic |
| Consent prompt appears after clicking an email or Teams link | Possible phishing lure |
Key user message:
If an application asks for access to your mailbox, files, or company data and you were not expecting it, stop and report it.
9. Protect Against Related OAuth Abuse Patterns
Consent phishing often overlaps with other OAuth abuse techniques.
| Threat | Control |
|---|---|
| Device-code phishing | Restrict or monitor device code flow where possible; alert on unusual device-code sign-ins |
| OAuth redirect abuse | Validate redirect URIs for internal apps and monitor suspicious consent prompts |
| Malicious links | Use Defender for Office 365 Safe Links and anti-phishing policies |
| Token replay | Use Conditional Access, sign-in risk policies, and token protection where available |
| Long-lived access | Revoke refresh tokens and app grants during incident response |
Also consider:
- Blocking legacy authentication
- Enforcing MFA
- Using Conditional Access
- Monitoring suspicious sign-ins
- Applying session controls for risky access
- Reviewing external SaaS integrations
10. Recommended Target-State Policy
For a typical Microsoft 365 and Entra ID tenant, the recommended target state is:
| Control | Recommended Setting |
|---|---|
| User consent | Restricted, not open |
| Verified publishers | Allow only for low-risk permissions |
| Admin consent workflow | Enabled |
| Admin consent reviewers | Identity or security-owned |
| Tenant-wide consent | Privileged and PIM-controlled |
| App governance | Enabled if licensed |
| Risky OAuth app alerts | Enabled |
| App inventory review | Monthly initially, then quarterly |
| High-risk permissions | Require formal approval |
| Existing grants | Baseline and clean up |
| User training | Focus on consent screen risk, not only password phishing |
Design principle:
Users should not be making unsupervised decisions that grant third-party applications persistent access to business data.
Practical Work Package
Work Package Name
Consent Phishing Protection Baseline
Objective
Implement a governed consent model for Microsoft Entra ID to reduce the risk of malicious OAuth application grants, improve visibility of third-party application access, and establish an operational process for reviewing and approving application consent.
Scope
In scope:
- Microsoft Entra ID user consent settings
- Admin consent workflow
- Enterprise applications
- OAuth permission grants
- Admin consent grants
- High-risk Microsoft Graph permissions
- App governance and monitoring
- Existing application consent clean-up
- User awareness guidance
Out of scope, unless explicitly added:
- Full SaaS security posture management rollout
- Full Microsoft Sentinel deployment
- Full Conditional Access redesign
- Full Microsoft Defender for Cloud Apps implementation
- Application development changes
Work Package Tasks
| Task | Description | Output |
|---|---|---|
| Assess current consent posture | Review current user consent, admin consent, and tenant-wide consent settings | Current-state assessment |
| Export application inventory | Export Enterprise Applications, app registrations, service principals, publishers, permissions, owners, and sign-in activity | Application inventory |
| Identify risky consent grants | Identify apps with high-risk delegated and application permissions | Risk register |
| Define permission risk tiers | Create low, medium, high, and critical permission categories | Permission risk model |
| Configure user consent settings | Restrict user consent to low-risk permissions and verified publishers, or disable user consent completely | Updated tenant configuration |
| Enable admin consent workflow | Configure reviewers, request expiry, notifications, and process ownership | Admin consent workflow |
| Restrict tenant-wide consent | Limit who can grant admin consent and use PIM where available | Privileged consent control |
| Configure monitoring | Create alerts for risky OAuth grants and suspicious consent activity | Detection rules |
| Enable App governance | Enable Microsoft Defender app governance where licensing allows | App governance dashboard |
| Clean up stale or risky apps | Remove unused, ownerless, over-permissioned, or unverified applications | Reduced attack surface |
| Create operating procedure | Document how consent requests are reviewed, approved, rejected, and audited | Consent review SOP |
| Create user awareness guidance | Provide short user guidance on consent phishing warning signs | Awareness material |
Suggested Implementation Sequence
- Inventory existing OAuth grants.
- Identify high-risk applications and permissions.
- Revoke obvious stale or risky grants.
- Define the permission risk model.
- Configure user consent restrictions.
- Enable admin consent workflow.
- Restrict tenant-wide admin consent.
- Enable monitoring and alerting.
- Enable Defender for Cloud Apps app governance, if licensed.
- Implement monthly OAuth application reviews.
- Publish user awareness guidance.
Deliverables
| Deliverable | Description |
|---|---|
| Current-state consent assessment | Summary of current Entra consent posture |
| Enterprise application inventory | List of apps, owners, publishers, permissions, and usage |
| Risky OAuth grant report | List of high-risk grants requiring action |
| Permission risk model | Categorised list of low, medium, high, and critical permissions |
| Updated consent configuration | Implemented Entra user consent and admin consent settings |
| Admin consent workflow | Configured request and approval process |
| Consent review SOP | Operational process for reviewing and approving consent |
| Monitoring and alert rules | Alerts for risky OAuth activity |
| Clean-up report | Record of revoked, disabled, or remediated applications |
| User awareness material | Guidance for users on identifying suspicious consent prompts |
Acceptance Criteria
The work package can be considered complete when:
- User consent is no longer unrestricted.
- Admin consent workflow is enabled.
- High-risk OAuth permissions require formal review.
- Tenant-wide admin consent is restricted to appropriate privileged roles.
- Existing high-risk OAuth grants have been reviewed.
- Stale, unused, or ownerless applications have been removed or remediated.
- Monitoring is in place for risky application consent activity.
- A documented consent review process exists.
- Users have been provided with clear consent phishing guidance.
- A recurring review process has been agreed.
Operational Review Cadence
| Review Activity | Frequency |
|---|---|
| Review new OAuth consent grants | Weekly during initial rollout, then monthly |
| Review high-risk permissions | Monthly |
| Review tenant-wide admin consent grants | Monthly |
| Review unused or stale applications | Quarterly |
| Review ownerless applications | Quarterly |
| Review consent policy settings | Quarterly |
| User awareness refresh | Every 6 to 12 months |
Key Risks and Mitigations
| Risk | Mitigation |
|---|---|
| Business disruption from blocking legitimate apps | Enable admin consent workflow before enforcing strict controls |
| Admin approval bottleneck | Define clear permission tiers and reviewer responsibilities |
| Existing risky grants remain active | Perform clean-up before or during policy rollout |
| Users do not understand consent prompts | Provide focused awareness material |
| Over-reliance on Global Administrators | Use least-privilege roles and PIM |
| Lack of monitoring | Enable Defender for Cloud Apps, App governance, Entra logs, or Sentinel detections |
| No application ownership | Require application owners for approved apps |
Recommended Policy Statement
The organisation should implement the following policy position:
Users may only consent to applications from verified publishers requesting approved low-risk permissions. Applications requesting access to sensitive data, broad Microsoft Graph permissions, offline access, directory permissions, mailbox data, files, SharePoint sites, Teams data, or tenant-wide access must go through the admin consent workflow and receive approval from the appropriate security, application, and data owners.
Summary
Consent phishing is dangerous because it bypasses traditional password-focused thinking. A user can give a malicious application access to company data without revealing their password.
The strongest defence is a combination of:
- Restricted user consent
- Admin consent workflow
- High-risk permission review
- Tenant-wide consent control
- Continuous OAuth app monitoring
- Existing grant clean-up
- User awareness
- Recurring operational reviews
The key principle is simple:
Do not allow users to make unsupervised decisions that grant third-party applications persistent access to business data.
