What app consent is and is not
OAuth app consent is not antivirus and not a replacement for MFA. It is the consent framework in Microsoft Entra ID: an app requests permissions (scopes), a user or admin approves them, and then that app may act on behalf of the tenant or user — until you revoke the consent. Examples: a project tool that reads calendar; an archiving tool with mail access; a “handy” browser extension that asks for mailbox rights.
It is also not a SharePoint sharing link. External sharing is about files you share; app consent is about API access to Microsoft 365. See also external sharing and Secure Score: score points and hardening often follow after you first set deliberate consent rules.
Why random user consent is risky
Three situations keep returning in SMEs. Phishing or lookalike apps: someone clicks “Allow” on an app asking for Mail.Read or Files.Read.All — the sign-in looks real; the damage is in the grant. Overly broad permissions: an innocent tool asks for directory or mailbox rights far wider than needed. Accumulation: over years old grants remain while nobody remembers why — see also inactive accounts and guest accounts for similar quietly growing access.
MFA and Conditional Access help with who signs in; they do not automatically stop an approved app that later works via tokens. That is why consent policy belongs next to identity hardening — not as an afterthought.
What you decide in writing
Keep it short enough to decide this quarter:
- whether users may approve apps themselves, or only admins (admin consent);
- which types of apps are allowed (your own integrations, approved vendors) and which are not (unknown consumer apps);
- which permissions (scopes) are too broad by default — for example full mailbox or directory — and always need review;
- who may assess an admin-consent request and how quickly;
- review cadence for existing OAuth grants: at least each quarter or after an incident;
- link to joiner and leaver: on exit, also check app access and shared mailboxes.
Write those points on one page. That is your app-consent agreement; the tenant follows that text.
What Floor ICT configures — and what you decide
In the Microsoft 365 tenant we typically set: restrict or disable user consent per your choice; an admin consent workflow or a clear approval path; blocks or limits on risky or consumer apps where licence and policy allow; an inventory of existing enterprise-app grants with a revoke proposal; and a short test “which known tools still work”. We tie this to MFA, admin roles, Conditional Access and Secure Score actions already in scope.
You still decide: which vendors and scopes are acceptable; whether a tool is “must have” despite broad rights; and who may approve an exception. Technical toggles without those choices give a false sense of security; policy without working consent rules does not help either.
More depth
Checklist for SME directors
1) Confirm MFA for named users is on. 2) Disable or strongly restrict user consent — admin consent as the default. 3) Have Floor ICT inventory existing OAuth / enterprise-app grants. 4) Revoke unknown or overly broad grants; document exceptions. 5) Agree who may approve new app requests. 6) Schedule a quarterly grant review — not “someday look in the admin portal”.
Admin consent workflow
Microsoft Entra ID can route user requests to admins instead of letting users approve directly. That prevents one employee click from creating a tenant-wide or mailbox-wide grant. Floor ICT enables the workflow or restriction policy per your written choice; you name who reviews requests — often the same circle as for admin roles.
Reviewing existing grants
Start with high-privilege apps (mail, files, directory) and apps nobody recognises. Revoking is usually safer than “leave it until something breaks”. Test critical integrations (accounting, archiving, backup) before mass revoke. Secure Score and Entra reports help prioritise; the decision “this app stays” is yours.