Microsoft 365 OAuth App Risk Review and Consent Cleanup

In one week on one tenant it answers the question 'which applications can read our data, who let them in, and do we still want that?' — and then acts on the answer. We export every enterprise application, app registration and permission grant with its scopes, consent type, granting user, publisher status, owner, credentials and last use; build a risk-tiered register; agree keep, reduce or revoke for each item with you; run the removals in recorded waves with restore commands; harden the user consent settings so it cannot silently refill; configure the admin consent workflow with named reviewers; switch on app governance where you are licensed for it; and hand over a one-page approval procedure and a readout.

An attacker registers an application, tricks a user into consenting to it — through a phishing message or a compromised page — and from then on the application reads that user's mail, files or contacts directly through Microsoft Graph. It never uses the password, so the account can have multifactor authentication, a strong password and a compliant device, and the access continues. Microsoft's own guidance says normal remediation such as resetting passwords or requiring multifactor authentication is not effective here, because the application is external to your organization. The only thing that removes the access is removing the grant — which is what this engagement does, at estate scale.

No. The discovery, the register, the revocation, the user consent settings, the permission classifications, the custom app consent policy and the admin consent workflow are all native to Microsoft Entra ID and work on Business Premium, E3 or E5. Defender for Cloud Apps only matters for the app governance layer — the automated unused-app, unused-credential and expiring-credential policies. Where you are licensed for it, we turn it on and build those policies inside the same fixed fee; where you are not, the same findings come from Entra's own application recommendations and our register, and we say which of the two you are getting before you sign anything.

That is the risk the method is built around. Nothing is revoked without a named owner confirming it first; the register identifies business-critical integrations before the first wave; removals run in batches with a hold between them so a dependency surfaces while we are still on the call; and every batch is recorded with the exact grant identifiers and the Microsoft Graph or PowerShell commands that put it back. Microsoft supports restoring a revoked permission, so the honest expectation to set is not 'nothing will break' but 'if something breaks, it is back within minutes and we know exactly what it was'.

By reach first, then by provenance, then by age. Application permissions held by non-Microsoft applications come first, because they run with no signed-in user — a grant to read all mailboxes or write to all sites does not care whose account is compromised. Then tenant-wide delegated grants, which Microsoft records with the consent type AllPrincipals, meaning everyone in the tenant is covered by one person's click. Then anything carrying offline_access, which is what keeps an application coming back when nobody is using it. Then publishers Microsoft has not verified, applications consented by users who have left, applications with no owner, applications with no sign-in in 90 days, and credentials that are unused, ageing or expired. Every line in the register says which rule put it there.

The main one is user consent. Microsoft's default is that any user may consent to any permission that does not require administrator approval; the recommended middle setting allows consent only to applications from verified publishers and only to permissions you have classified as low impact; the strictest setting is administrators only. Users notice when they hit an application that no longer qualifies — which is exactly why the admin consent workflow goes in at the same time, so the user sends a request to a named reviewer instead of hitting a wall. We agree the posture with you in the workshop, and the basic sign-in permissions stay classified as low impact so ordinary sign-in flows are unaffected.

It is the Entra feature that turns 'this app needs admin approval' into a request routed to people you name, with email notification, reminders and an expiry you set. Reviewers should be the people who actually understand the business case — usually IT plus an application or data owner — but be clear on the limits: being a reviewer confers no privilege, so a reviewer can view, block or deny, while approving a request for Microsoft Graph application permissions still needs a Global Administrator. We configure it, put your reviewers in, and run one test request through it end to end so nobody meets the interface for the first time on a real request.

One Microsoft Entra tenant with up to 300 non-Microsoft applications, counted at discovery, each service principal counted once however many grants it holds. Microsoft's own first-party service principals are inventoried for context but not counted against that number — a typical tenant has a lot of them, and charging for Microsoft's own apps would be nonsense. If the export comes back above 300, or if there are several tenants, we quote per tenant, and you hear the number on day one rather than in the invoice.

Probably not first. If you have evidence of an account takeover — inbox rules you did not create, mail leaving the tenant, a sign-in from somewhere impossible — that is an incident, and Business Email Compromise Investigation and Recovery is the engagement that scopes and contains it. This service is the hygiene pass that removes the standing access an attacker would use, and the one you run afterwards so the same door is not open again. If the register turns up something that looks live while we are working, we stop and tell you the same day rather than quietly continuing as a clean-up.

Yes, and we deliberately leave you able to. Microsoft publishes the method — the permissions inventory script referenced from its illicit-consent-grant playbook, the audit search for consent events, the revocation cmdlets — and everything in the register can be reproduced with the queries we hand over. What you are buying is a week of somebody who has done it before: the risk tiering that turns a 4,000-row CSV into about 40 decisions, the wave discipline that stops a clean-up becoming an outage, the settings posture agreed rather than guessed, and a written procedure at the end. Teams that try it in-house usually get the export and stall at the decisions.

It removes the standing app access that this class of attack leaves behind, and it makes the next grant harder to obtain — but blocking the flow itself is a Conditional Access change. Microsoft's guidance is to get as close as possible to a unilateral block on the device code flow, allowing it only for documented cases like legacy tooling, and to deploy that policy in report-only first with emergency access accounts excluded. Where you already run Conditional Access we build that policy and hand it to you in report-only for your own review; rolling out and operating a Conditional Access baseline is a separate engagement.

Granular, time-bound delegated access that you approve — our published policy is GDAP rather than standing Global Administrator. Practically that means Cloud Application Administrator or Application Administrator for the review and revocation work, Privileged Role Administrator for the consent policy changes, and a Global Administrator of yours available for the steps Microsoft reserves to that role, such as turning on the admin consent workflow and running the tenant-wide permissions inventory. The last item in the handover is removing our access and showing you the audit log entry that proves it.

You do, with the procedure — and the honest warning that an estate refills. Microsoft's own advice for organizations with many registered applications and a large user base is to review consent grants weekly. If nobody on your team has time for that, Managed Entra ID Identity Hygiene and Access Reviews takes over the recurring watch on new consents, new registrations, expiring credentials and access reviews for a monthly per-user fee, and it starts exactly where this project ends. Where Defender for Cloud Apps is licensed, the app governance policies we build keep working on their own and raise alerts into your Defender incident queue.

$1,950 per project, fixed, quoted in writing before work begins, and you pay after you approve delivery. It covers one Microsoft Entra tenant with up to 300 non-Microsoft applications: the full export and register, the consent-event review, the decision workshop, the revocation waves with restore paths, the consent settings and permission classifications, any custom app consent policy, the admin consent workflow with a test request, app governance enablement and hygiene policies where you are licensed for it, the optional report-only device code flow policy where Conditional Access is already in use, the approval procedure and the readout. Larger estates and additional tenants are quoted per tenant. Microsoft's licences — Defender for Cloud Apps, the E5 bundles, Microsoft Entra Workload ID Premium — are billed by Microsoft or your CSP and are never part of this fee.