Revoking an app's permissions does not stop users from granting them again. Microsoft's documentation says you also need to stop the application from requesting those permissions through dynamic consent, or block user consent altogether. Otherwise the next click on a consent screen restores the access you removed.
What Microsoft says
In its guidance on reviewing permissions granted to enterprise applications, Microsoft notes that revoking the current granted permission does not stop users from re-consenting to the application's requested permissions. It points to two follow-up actions: stop the application from requesting the permissions through dynamic consent, and, if you want to block users from consenting altogether, configure how users consent to applications.
Why this happens
An OAuth grant is the record of a user or admin saying yes to a list of permissions. Revoking deletes that record. It does not change the app, which can ask again the next time a user signs in, and it does not change tenant policy, which may let any user approve.
Three levels of fix
1. Remove the grant. Quick and needed, but temporary on its own.
2. Change the app's requests. If you own the app, update its requested permissions so it no longer asks for the scope. If it is a vendor app, you cannot change what it asks for, so rely on the next level.
3. Change tenant consent policy. Restrict who can consent. Common options are to require admin approval for all apps, or to allow user consent only for apps from verified publishers and low-risk permissions. Exact options vary by platform and plan, so read the current documentation before choosing.
A cleanup order
- Revoke the grant.
- Check sign-in logs for the app to see recent use.
- Invalidate refresh tokens where the platform allows it, since issued tokens may remain usable until they expire or are revoked.
- Tighten consent policy.
- Tell users why, and give them a request path for tools they need.
Give users a way to ask
Blocking consent without a request route pushes people to workarounds, such as personal accounts. An admin consent workflow with a service level for decisions keeps the control without the friction.
If the app was malicious
Treat it as an incident: preserve logs, identify which users granted access and what data the scopes allowed, rotate any secrets the app could have read, and follow your incident process.
Other platforms
The same pattern holds elsewhere: a grant is separate from policy. Check each platform's admin console for connected apps and consent settings.
Document the decision in your app inventory so the next admin knows why an app was blocked and does not re-approve it from a support ticket.
Where Safeguard fits
Safeguard does not manage consent policies in identity providers. It supports policies, gates and compliance evidence automation for software you develop.
Quick check
Does revoking also end active sessions?
Not necessarily. Microsoft's guidance covers invalidating refresh tokens as a separate action, so check that step as well.
Sources
Last reviewed: 19 October 2026.