A third-party OAuth application can retain access after its original user stops using the service. Reviewing the application name alone is insufficient: the useful unit is the grant connecting a particular client, resource, permission and consent context. The review should establish a business owner, a current need and a verified outcome for any removal.
This guide produces a consent review worksheet. It uses Microsoft Entra as a documented example while keeping the decision method applicable to other identity platforms. Microsoft’s permission review and revocation guidance, checked on 27 September 2026, distinguishes delegated grants, application permissions and other authorisation mechanisms. Confirm the current platform procedure before changing a production grant.
Inventory grants, not just installed applications
Record the tenant, application ID, local service-principal identifier where relevant, resource API and permission. Distinguish delegated access exercised with a user context from application access exercised without that user context. The distinction affects what the application can do and how the grant should be reviewed.
Capture who granted consent, whether it applies to a user or the organisation, and when the evidence was extracted. A display name can change and similar names can identify different applications. Use stable identifiers in the worksheet and keep the friendly name for readability.
The security-of-processing guide provides broader risk context when personal data is involved. An OAuth review should also cover business information, configuration and other resources that may be sensitive even when the personal-data question is limited.
Join the technical grant to a business purpose
Ask the owner which operation requires each significant permission. “The sales team uses it” does not explain why an integration can read every mailbox or change files. Identify the workflow, the users, the data required and the expected frequency of access.
Check whether the current application version still needs the original scopes. Integrations often accumulate permissions during pilots or migrations. Reducing a grant may be preferable to removing a useful service, but the proposed reduced scope must be supported by the application’s actual operation.
If no owner can be found, record an orphaned grant and follow the organisation’s escalation process. Absence of an owner is a governance defect; it does not automatically prove that immediate revocation is safe. A background integration may support a critical workflow even when its original sponsor has left.
Build the consent worksheet
| Field | Review question | Evidence |
|---|---|---|
| Client identity | Which exact application is this? | Stable IDs and publisher details |
| Resource and scope | Which operations and data are allowed? | Grant export and API permission description |
| Consent context | Who approved what for whom? | Consent record and tenant settings |
| Business owner | Who confirms the continuing need? | Named owner and workflow reference |
| Usage | What activity is visible in which period? | Relevant logs with coverage limits |
| Decision | Retain, narrow, remove or investigate? | Reason and authorised reviewer |
| Execution | Which grant or authorisation changed? | Change record and operator |
| Verification | What access is still possible? | Follow-up inventory and controlled checks |
Keep the worksheet separate from secrets. It should identify credentials or certificates that need review without copying usable values into a widely shared file. Access to the evidence itself should reflect the sensitivity of the systems it describes.
Assess publisher identity without treating it as approval
Publisher information can help establish attribution and detect an unexpected application. It does not, by itself, show that the requested permission is necessary for your organisation. Verify that the documented publisher, domain, application identifiers and purchased service correspond.
Investigate mismatches rather than guessing. A legitimate supplier may use a different legal entity or application registration for a particular integration. Ask for an explanation and evidence. An unexplained mismatch, however, should not be cleared simply because the display name resembles a familiar brand.
Use your NIS2 risk-management process, where relevant, to connect the grant to the service and its impact. A broad grant to a low-priority convenience application may deserve different treatment from a narrowly scoped grant supporting an essential operational function.
Interpret usage with its limits
A quiet log can mean unused access, incomplete logging, a short retention window or a task that runs infrequently. Record the observation period and which event types were available. Do not translate “no event in the available fourteen days” into “never used.”
Compare activity with the declared workflow. An integration expected to run once each night but active continuously may need investigation. Equally, a disaster-recovery integration may be intentionally dormant. Ask the owner to explain the pattern and preserve the evidence supporting that explanation.
NIST SP 800-53A provides a useful distinction between examining records, interviewing responsible people and testing a control. The worksheet should identify which of those activities supports the decision. An interview alone may be insufficient for a sensitive permission.
Worked example: a retired calendar assistant
A hypothetical organisation finds a calendar assistant approved during a pilot. The application still has delegated access for twelve users. Eight users have stopped using it, three still use a related workflow and one has left the company. The original project owner has moved teams.
The review assigns a replacement owner and separates the cases. The former employee’s wider access lifecycle is checked. The eight unused grants are scheduled for removal. For the remaining users, the team confirms which permissions are necessary and whether an approved alternative supports the workflow.
After authorised revocation, the operator records the exact grants changed and refreshes the inventory. The team checks whether users could simply consent again under the tenant’s current settings. Microsoft’s documentation explicitly notes that revoking an existing permission does not, by itself, prevent new consent. The corrective action therefore includes reviewing the consent policy for this application class.
The review also considers existing tokens and other authorisation routes under the platform’s current behaviour. It does not claim that deleting one object instantly invalidates every possible session or permission. Closure depends on the observed and documented effect relevant to the service.
Plan the change and its verification
For a business-critical integration, agree a change window, expected impact and recovery route. Preserve the original grant identifiers and approved configuration so an authorised operator can diagnose a problem. A recovery plan should not become an automatic instruction to restore excessive permissions without review.
Verify both the intended loss of access and the continued operation of approved functions. Removing an overbroad grant may reveal that the application requires redesign or a different integration pattern. Record this as an unresolved dependency rather than marking the review complete because the change command succeeded.
The combined ISO 27001 and GDPR guide explains the value of coordinating security and privacy work. Keep their conclusions distinct: a technically restricted grant can still involve an unsuitable processing arrangement, and a signed agreement does not justify every technical permission.
Keep other access paths in scope
Application permissions and delegated grants are not the only authorisations that can matter. The Microsoft guidance identifies additional systems such as directory roles and resource-specific permissions. Review the routes relevant to the application instead of assuming the OAuth inventory is the complete access inventory.
Check application credentials, service accounts and external connections according to their own control processes. Record the handoff when a problem falls outside the consent worksheet. The GDPR audit methodology can help preserve this boundary between an observed issue and the team responsible for investigating it.
Distinguish what a grant permits from what was exercised
A granted scope describes potential access under the identity platform’s rules; an activity log records selected observed events. Those are different kinds of evidence. Before calling a grant dormant, identify the log source, retention period, resource covered and whether the relevant API actions appear there. Microsoft’s application permission audit-log guidance describes grant and revoke events. Those events help reconstruct permission changes, but they should not be mistaken for a complete record of every data access by the application.
For a sensitive grant, ask the application owner for a concrete operation: which API is called, on whose behalf, using which permission, and at what frequency? Compare that account with configuration and observed activity. If the supplier says a broad scope is required, ask whether its current product can use a narrower permission or resource boundary. Record any technical constraint and the business decision to accept it. Do not infer necessity from a successful sign-in or from a vendor’s generic permission list.
The result may be “investigate” rather than immediate retain or revoke. Give that state an owner, a question and a date for further evidence. Without these fields, the unresolved grant remains effectively approved by silence. A high-impact grant with no owner may justify temporary restrictions while the dependency is investigated, subject to the organisation’s change process.
Review the path back to consent
Removing an existing grant solves only part of the lifecycle problem if users can grant it again. After a removal, check the tenant’s user-consent setting, administrator approval path and any exception for trusted application categories. Microsoft’s consent management guidance explains how requests can be reviewed and how user access can be limited. Translate the platform options into an internal rule for who may approve the particular risk, with a route for legitimate users to request an integration.
Look for duplicate application registrations before closing the case. A supplier may have separate production and test clients; the same product may appear under more than one publisher or resource. Use application and service-principal identifiers, not display names alone, and ask the service owner which clients are expected. Removing one stale client should not create a false conclusion about a second live grant.
If consent is denied during procurement, preserve the reason and the exact permission set assessed. A later release may request new scopes, change publisher registration or move to an application permission. That should trigger a new review. The earlier approval did not authorise an unlimited future permission set.
Verify revocation at the resource boundary
The implementation record should show which delegated grant or application role assignment changed, which operator made the change and what the refreshed inventory shows. In Microsoft Entra, the permission review guidance distinguishes administrator consent visible in the portal from user consent that may require Graph or PowerShell for revocation. The operator must use the route appropriate to the actual grant and retain the change identifier.
Where feasible, perform a controlled check against the relevant resource after the change. A failed sign-in to the app does not by itself prove that an existing token, alternate account or other authorisation route cannot reach the API. Plan the verification around the resource and the expected operation, observing the platform’s token behaviour and the organisation’s incident procedure. Avoid a destructive test against production data merely to make the evidence look stronger.
If the approved integration stops working, compare the observed failure with the permission removed. A recovery decision may restore a narrower grant or hold the service while an alternative is built. Record who authorised the decision and retest both the approved function and the prohibited access. A review is closed when the technical state matches the authorised decision, including any explicit residual limitation.
When a grant is retained temporarily, put a concrete condition on that decision: a reduced scope released by the supplier, a migration date, a replacement owner or a completed dependency test. The next reviewer should be able to see whether that condition occurred without reconstructing the original discussion. If it did not, the exception returns for a new decision; it should not quietly renew because the application still functions. This is especially useful when a broad application permission supports an important service but the team has agreed to redesign the integration.
Close with a repeatable review trigger
Retain the inventory date, decisions, implementation evidence and unresolved exceptions. Trigger further review after scope expansion, ownership changes, a supplier incident or an unexpected permission request, as well as on the organisation’s chosen risk-based schedule.
Track grants without owners and removals awaiting verification separately from completed reviews. For procurement teams, the audit-tool selection guide offers questions about evidence workflows. The essential outcome remains independent of the tool: a reader should understand why each significant grant remains, who approved it and how removed access was checked.