Microsoft 365 App Consent Governance: How to Control OAuth Apps, Graph Permissions, and User Consent

Microsoft 365 environments often focus heavily on user identities while giving too little attention to application access. App consent can create persistent access paths into business data through third-party or internal applications, and without approval, ownership, visibility, and review, that access becomes difficult to govern.

While we have previously discussed External Sharing Governance: controlling how people share files: app consent governance addresses a different risk: how software itself accesses your tenant. Modern SaaS integrations use the OAuth 2.0 protocol to request access. When a user or administrator clicks “Accept” on a permission prompt, they aren’t just signing in; they are granting that application a specific set of permissions to interact with business data, often persistently and silently.

This is distinct from user access governance. User access governance focuses on who should have access. App access governance focuses on what software has been allowed to access, under what permission model, and with what ongoing oversight.

Without a structured governance model, these applications become a source of unmanaged application access, unmonitored data access, and permission creep that exists entirely outside of standard user access reviews.

The App Permission Landscape: Delegated vs. Application

To govern application access effectively, you must first distinguish between the two primary permission models in the Microsoft identity platform. Each carries a different risk profile and requires a different level of oversight.

Delegated Permissions

Delegated permissions are used when an application needs to act on behalf of a signed-in user. The app can only access the data that the specific user can already see. For example, a productivity plugin might use delegated permissions to read a user’s calendar or send an email on their behalf.

From a governance perspective, delegated access still requires scrutiny. Users frequently grant broader access than the application genuinely needs, creating unnecessary exposure through routine consent decisions.

Application Permissions

Application permissions allow an app to run as its own identity, without any user present. These are typically used for background services, business IT support tools, or automation scripts.

Because these permissions often grant tenant-wide access (e.g., “Read all files in all SharePoint sites”), they require a higher approval threshold, stronger ownership controls, and regular review.

Why User Consent Becomes a Governance Problem

By default, many Microsoft 365 environments allow users to consent to applications for themselves. While this reduces IT support tickets, it creates several friction points for security and compliance:

• Unmanaged Application Access via OAuth: Users may connect browser extensions, “free” PDF converters, or third-party CRM integrations to their corporate mailbox without realising they are granting a third party the right to read their entire inbox.
• Lack of Visibility: Unless IT is actively monitoring the “Enterprise Applications” dashboard, these connections happen with limited oversight. Data may be syncing to a third-party service for months before it is discovered.
• Broad Scopes for Convenience: Many app developers request broad permissions “just in case” to avoid future errors. Users rarely read the fine print of permission scopes, leading to significant over-privilege.

When consent is left entirely to the user, the business effectively loses control over where its data is being copied or processed.

Admin Consent: Treating Apps as Privileged Identities

When an application requires access to data across the entire organisation, it requires “Admin Consent.” In a well-governed tenant, granting admin consent should never be a routine technical checkbox; it is a high-level access decision.

Apps that have been granted admin consent effectively become permanent residents in your environment. If an application is granted the ability to “Read all Directory data” or “Manage all Groups,” it possesses a level of access that would be highly scrutinized if it were held by a human user.

Governance requires that these high-impact apps follow the same logic as Privileged Access Governance. They must have a documented business justification, a defined internal owner, and a regular review schedule to ensure the integration is still necessary.

Data Access Scope and the Microsoft Graph

The risk of an application is defined by its “scope”: the specific datasets it is allowed to touch via the Microsoft Graph API. The Graph is the central nervous system of Microsoft 365, and apps can be granted access to:

• Mail and Calendars: Reading, sending, or deleting emails.
• Files and Sites: Accessing SharePoint libraries and OneDrive for Business data.
• Teams: Accessing chat history, channel messages, and recording settings.
• Directory Information: Reading user profiles, group memberships, and organisational structures.

Governing app consent means ensuring no application is granted a broader scope than is strictly required for its stated function. “Read.All” should only be granted when “Read.Selected” is insufficient.

The Problem of Stale and Forgotten App Access

One of the most common governance failures is “stale” application access. Apps are frequently connected for a one-time project, a trial period, or a specific marketing campaign, and then forgotten. However, unlike a user account that might be disabled during an Identity Lifecycle review, the application’s service principal and its OAuth tokens often remain active indefinitely.

This creates stale or abandoned applications: trusted third-party connections that no one is monitoring, but which still have the authority to pull data from your tenant. If that third-party vendor is later compromised, your tenant becomes a target through that forgotten bridge.

Why MFA and Conditional Access Do Not Solve Consent Risk

It is a common misconception that strong authentication prevents app-based data breaches. While we advocate that MFA alone is not an access control strategy, it is particularly true in the context of OAuth.

MFA protects the initial sign-in session. Conditional Access controls the conditions under which that session is established. However, once a user or admin has consented to an app and a refresh token has been issued, the application can often continue to access data according to its granted scope without requiring the user to re-authenticate or satisfy Conditional Access policies again for a long period.

Consent governance is the control layer that determines if the app should have access at all, regardless of whether the user’s individual sign-in was secure.

Warning Signs of Weak App Consent Governance

Your organisation may be at risk if any of the following are true:

1. Open User Consent: Users can connect any third-party application without any administrative oversight or approval.
2. No Central Inventory: There is no documented list of which apps have been granted admin-level permissions or why.
3. Abandoned Enterprise Apps: Your Entra ID dashboard contains dozens of “Enterprise Applications” that haven’t been used in over a year.
4. No Owner Assignment: Applications exist in the tenant with no clearly assigned internal stakeholder responsible for their security.
5. Technical Decisions Only: App approval is handled by IT as a support ticket rather than being vetted for business risk and data privacy.

Governance Controls That Matter

To bring application access under control, organisations should implement several core principles:

• Restrict User Consent: Disable the ability for users to grant consent to unverified apps. Move toward an “Admin Consent Workflow” where users can request access, but IT or Security must review it.
• Define Approval Workflows: Establish a standard vetting process. Does the app have a privacy policy? Where is the data stored? Does it truly need “Read.All” permissions?
• Assign Ownership: Every enterprise application should have a designated internal owner. If the owner leaves the business, the app must be reassigned or revoked.
• Periodic Reviews: Conduct a bi-annual review of all application permissions. Revoke any app that is no longer in active use.
• Logging and Monitoring: Ensure that your Audit Logging captures consent events. This is vital for Incident Response Readiness so you can quickly identify when and how a malicious app was introduced.

A Practical Rollout Approach

For most small to mid-sized organisations, fixing app governance is a phased process:

1. Phase 1: Inventory & Audit. Export a list of all current Enterprise Applications and their permissions. Focus your review on apps with “Application” permissions or those that were granted “Admin Consent.”
2. Phase 2: The Clean-Up. Identify and remove apps that are clearly redundant, were part of old trials, or are from unknown vendors.
3. Phase 3: Tighten Consent Settings. Configure the Admin Consent Workflow in Entra ID. This allows users to still find the tools they need but ensures a “human-in-the-loop” review before the data bridge is built.
4. Phase 4: Establish Remove Discipline. Make the removal of unnecessary applications a standard part of your quarterly security hygiene.

Managing application access is a critical component of a secure Microsoft 365 environment. By treating app consent as a governance discipline rather than a one-time configuration, organisations can ensure that third-party integrations remain visible, justified, and under control. If you need a hand securing your tenant, contact us to chat about your needs.