Every OAuth application connected to your Microsoft 365 tenant has been granted specific permissions to access data or perform actions on behalf of users or the organisation. When those permissions are broad, sensitive, or poorly understood, they represent a persistent attack surface that exists independently of user credentials or MFA.

Overe flags applications holding high-risk Graph API permissions — including the ability to read all mail, access all files, query directory data, or send email as any user. These permissions can be delegated (requiring a signed-in user) or application-level (operating without any user present). Application-level permissions carry the higher risk, as they can be exercised silently and at scale.

Apps with risky permissions are particularly dangerous because they often persist long after their original purpose is forgotten. A tool added during a project, a vendor integration that was never removed, or an app consented to by a user during a phishing attack can all hold active permissions indefinitely.

• Attacker compromises an app with Mail.Read.All and reads every email across the tenant without signing in as any user
• Application credentials (client secret or certificate) stolen and used to access data with no user interaction required
• An app with Files.ReadWrite.All used to silently exfiltrate OneDrive and SharePoint content
• An app with Directory.ReadWrite.All used to enumerate users, groups, and roles — and to modify them
• Phishing attack tricks a user into consenting to a broad-permission app, giving the attacker persistent access even after a password reset
• Legacy or abandoned apps with live credentials used as re-entry points after a primary compromise is remediated
• App registration with a long-lived client secret that was never rotated used as a persistent entry point after the original developer's access was revoked
• Application with SendMail.All permission used to send phishing or BEC emails from legitimate organisational domain addresses that bypass external spam filters

Many legitimate business applications require broad Graph permissions to function correctly. HR integrations, backup tools, monitoring platforms, and SIEM connectors commonly hold extensive read access. The question is not whether the permissions are broad — it is whether the application is known, documented, and still in use.

An app with high-risk permissions is acceptable when it has a named owner, a documented business purpose, active usage, and credentials that are managed and rotated appropriately. An app with the same permissions but no clear owner, no recent sign-in activity, or unmanaged credentials is a different matter entirely.

Before modifying or removing any application's permissions:

• Identify the application's publisher and confirm whether it is a Microsoft first-party app, a verified third-party, or an unverified or internal app
• Confirm whether the app has delegated permissions, application permissions, or both — application permissions carry higher risk
• Check when the app last made API calls and whether it is still in active use
• Identify who consented to the app — was it an admin granting tenant-wide consent, or individual users?
• Review the app's credentials: does it have active client secrets or certificates, and when do they expire?
• Check whether the app has any corresponding service principal with Entra ID role assignments
• Confirm with a named business owner whether the app is still required and the permissions are justified

1. Use Overe to review all apps with high-risk permissions across the tenant, prioritising application-level permissions over delegated
2. For apps that are no longer in use, revoke permissions and disable or delete the app registration
3. For active apps with overly broad permissions, work with the vendor or developer to reduce scope to the minimum required
4. For apps with unmanaged or long-lived credentials, rotate or revoke client secrets — expired credentials can still be re-issued by an attacker with access to the app registration
5. Review and restrict user consent settings to prevent users from granting high-risk permissions without admin review
6. For any app where ownership is unclear, investigate before taking action — removal of a live integration can cause service disruption
7. Document all high-risk app permissions with a named owner and a review date

Where direct remediation is required, Overe provides links to the appropriate Microsoft admin controls to complete the action safely.

Microsoft: Review permissions granted to applications - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-application-permissions

Microsoft: Restrict user consent to applications - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent

Microsoft: Investigate risky OAuth apps - https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth

After reviewing apps with risky permissions, also check these related risk areas:

• Apps with Admin Roles — apps holding both broad Graph API permissions and Entra ID admin roles represent a compounded risk; review both categories together for the same application set
• Dormant Apps — an app with risky permissions that is no longer actively used is harder to justify and harder to monitor; check dormant apps for overlapping permission scope
• OAuth Phishing via First-Party Microsoft Apps — user-consented permissions can be granted through phishing; check whether any broad-permission apps were consented to outside of admin-controlled workflows
• Power Automate Flow Created — automation flows can use app credentials or impersonation permissions; check whether any flows are using connected apps with broad data access
• Anomalous Delete Sequence — an app with Files.ReadWrite.All or SharePoint permissions that triggers bulk deletions may be compromised or abused; investigate the two signals together