15.7 Preventive Controls

Preventive Controls

Consent phishing succeeds because users can consent to any application without approval. These controls restrict or eliminate user self-service consent.

Recommendation 1: Disable User Consent — Require Admin Approval

What it does: Users cannot consent to applications. All consent requests are routed to an admin approval workflow. An administrator reviews the application, its permissions, and its publisher before approving or denying.

Execute: Entra ID → Enterprise Applications → Consent and permissions → User consent settings → “Do not allow user consent.” Configure the admin consent request workflow: Entra ID → Enterprise Applications → Admin consent settings → Enable admin consent requests → Select reviewers.

Blast radius: No user can consent to any new application. Existing consents are not affected. Users who need a new application must submit a request and wait for admin approval. Tenant-wide. Significant workflow change.

Before enabling: Communicate to all users: “Starting [date], new application access requests require IT approval. Submit requests via [process]. Existing applications continue to work.” Ensure the admin consent workflow has reviewers assigned and a defined SLA (e.g., 24-hour review for standard requests, 4-hour review for urgent business needs).

Cost impact: £0. Included in Entra ID.

Rollback: Change user consent settings back to “Allow user consent for apps from verified publishers” or “Allow user consent for all apps.”

Compliance mapping: NIST CSF PR.AC-4 (Access permissions managed). ISO 27001 A.8.9 (Configuration management). SOC 2 CC6.1 (Logical access controls), CC6.3 (Segregation of duties — separating the consent decision from the user’s access grant).

Recommendation 2: Allow Consent Only from Verified Publishers

What it does: Users can consent to applications from verified publishers only. Unverified applications require admin consent.

This is the middle ground if fully disabling user consent is too disruptive. It allows users to adopt verified third-party tools (Zoom, Slack, Adobe) while blocking malicious applications from unverified attackers.

Blast radius: Users can still consent to verified-publisher apps. Only unverified apps are blocked. Lower workflow disruption than full disable. Tenant-wide.

Execute: Entra ID → Enterprise Applications → Consent and permissions → User consent settings → “Allow user consent for apps from verified publishers, for selected permissions.”

Recommendation 3: Deploy Defender for Cloud Apps App Governance

What it does: Monitors OAuth applications for anomalous behaviour: unusual data access patterns, high-privilege permission usage, and applications that access more data than expected.

Blast radius: Monitoring only — does not block applications unless policies are configured to do so. Tenant-wide monitoring.

Cost impact: Included in Defender for Cloud Apps (E5 or standalone licence).

What it provides: Automated alerts when an application: accesses an unusual number of mailboxes, consents to high-risk permissions, comes from an unverified publisher, or shows anomalous API call patterns. These alerts feed the Sentinel incident queue — enabling automated detection of consent phishing that the user-side controls miss.

Recommendation 4: Quarterly Consent Audit

Mandate a quarterly review of all consented applications using the queries from subsection 15.6. Remove dormant, unrecognised, and over-permissioned applications. Document the review for compliance purposes.

Compliance mapping: NIST CSF PR.AC-4 (Access permissions managed — periodic review). ISO 27001 A.5.18 (Access rights — periodic review). SOC 2 CC6.2 (Prior to access, authorization is required).

Recommendation priority matrix

Subsection artifact: The 4 preventive controls with deployment instructions, blast radius, and GRC mapping. This is the Application Governance Deployment Guide artifact.

Knowledge check

Implementing admin consent workflow — step by step

Step 1: Disable user consent. Entra ID → Enterprise Applications → Consent and permissions → User consent settings → “Do not allow user consent.”

Step 2: Configure admin consent reviewers. Entra ID → Enterprise Applications → Admin consent settings → “Users can request admin consent to apps they are unable to consent to” → Yes. Select reviewers: assign 2-3 individuals (Security Administrator + IT Manager + a backup). Set notification email address for consent requests.

Step 3: Communicate to users. Draft: “Starting [date], new application access requests require IT approval. When you encounter a consent prompt for a new application, you can submit a request for admin review. Requests are reviewed within 24 hours (4 hours for urgent business needs). Existing applications you have already consented to continue to work.”

Step 4: Define the review SLA. Standard requests: reviewed within 24 hours. Urgent requests (flagged by the user as business-critical): reviewed within 4 hours. Denied requests: user notified with explanation and alternative suggestion.

Step 5: Create the review procedure. For each consent request, the reviewer checks: Is the application from a verified publisher? What permissions does it request? Is the publisher known and reputable? Does the business need justify the permissions? Apply the red flag scoring from subsection 15.3.

1
2
3
4
5
6
7
8
9

// Monitor admin consent requests — track SLA compliance
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has "admin consent request"
| extend RequestUser = tostring(InitiatedBy.user.userPrincipalName)
| extend AppName = tostring(TargetResources[0].displayName)
| extend RequestTime = TimeGenerated
| project RequestTime, RequestUser, AppName, Result
| order by RequestTime desc

Track: how many consent requests are submitted per week, what percentage are approved vs denied, and whether the SLA is being met. If requests are consistently denied: users may attempt to bypass the control (using personal devices, for example). If the SLA is consistently missed: assign additional reviewers.