Govern OAuth application consent before it becomes persistent access

Source fact: consent can outlast a sign-in

Microsoft warns that consent phishing uses the legitimate Microsoft identity platform to persuade a person to authorize a malicious application. The application may receive delegated access to mail, files, contacts, calendars, or other resources without obtaining the user’s password. Application permissions can be broader because software acts as its own identity without an interactive user. A Microsoft-hosted prompt, a familiar application name, or a verified publisher provides context, but none proves that the requested permissions fit the business purpose.

Microsoft also distinguishes consent-grant remediation from ordinary account recovery. Resetting a password or requiring multifactor authentication does not by itself remove an external application’s existing authorization. Changing the tenant’s user-consent setting governs future grants; it does not automatically revoke grants already issued. Microsoft’s current prevention and response guidance is available in Protect against consent phishing.

Build a governed application register

Inventory enterprise applications, service principals, app registrations, delegated grants, and application-role assignments. For each approved application, record its application ID, publisher and tenant of origin, business purpose, service and technical owners, vendor contact, expected users, permissions, consent type, approving identity, credential expiration, data handled, connected systems, and next review date. Investigate ownerless, unused, highly privileged, tenant-wide, or unfamiliar applications first. A recognizable brand is not a substitute for reviewing the actual object and permissions.

Classify which low-impact delegated permissions users may approve, which require administrator review, and which are prohibited except through a documented exception. If user consent is restricted or disabled, provide an administrator-consent request workflow so legitimate demand enters a visible queue. Workflow reviewers still need an appropriate directory role; being named a reviewer does not grant approval authority.

DSE recommendation: approve and respond with evidence

1. Require a named business owner to explain why every requested permission is necessary and why a narrower permission or smaller user scope will not work.
2. Compare the publisher, redirect domains, privacy statement, contract, data location, and deletion terms with the vendor being evaluated.
3. Use least-privileged approvers, restrict user assignment where supported, and record the decision, expiration, conditions, and rollback owner.
4. Review existing grants on a risk-based schedule, prioritizing application permissions, broad admin consent, sensitive data, expiring credentials, dormant use, and missing owners.
5. For suspected illicit consent, preserve application and service-principal IDs, grant details, consent and sign-in events, and affected identities before containment.
6. Disable the suspicious application where appropriate, revoke the relevant grant or app-role assignment, scope accessible data and activity, review related account changes, and monitor for recurrence.

Test revocation against an approved application before an incident so responders know which object to change and how service impact will be handled. Keep password reset, session revocation, authentication-method review, and mailbox or file investigation in the response when account compromise is also possible, but do not mistake those steps for removal of the application grant.