M365Clarity Blog · 18 July 2026 · Identity Security App Registrations Entra ID

Microsoft 365 App Registration Audit — the attack surface most IT admins have never checked

There is an attack surface in almost every Microsoft 365 tenant that most IT admins have never looked at. It's not a misconfigured policy or a weak password. It's the list of third-party applications that were connected years ago — during a proof of concept, by a contractor, through a helpdesk ticket that nobody remembers — and that still have admin-consented access to your tenant today.

Enterprise applications with broad permissions are one of the most commonly overlooked security risks in Microsoft 365. A single app with Mail.ReadWrite.All has silent access to every mailbox in your organisation. Most organisations have no idea what's connected.

App registrations vs enterprise applications — the distinction that matters

Microsoft's naming is confusing here. When an external application requests access to your tenant, it creates an enterprise application (also called a service principal) in your Entra ID. This is distinct from app registrations, which are applications you've built yourself.

The attack surface lives in enterprise applications — specifically, in the permissions those applications have been granted. You find them at Entra admin centre → Enterprise applications → All applications, not in App registrations.

How admin consent works — and why it persists

When a third-party app requests permissions that require an admin to approve, a Global Admin sees a consent screen listing the requested permissions and clicks Accept. From that moment, the application has those permissions for every user in the tenant — indefinitely, until someone explicitly removes them.

The problem is that consent doesn't expire. The contractor who set up the integration leaves. The POC is never productionised. The helpdesk ticket is closed. But the application remains in your tenant, with its admin-consented permissions, quietly waiting.

What a breach looks like: An attacker compromises the vendor whose application has Mail.ReadWrite.All consent in your tenant. The attacker doesn't need your users' passwords. They use the vendor's application credentials to read every email in your organisation — silently, with no alerts, because the access is legitimate from Microsoft's perspective.

The permissions that matter most

Not all permissions are equally dangerous. M365Clarity's App Registration Audit focuses on the permissions that represent significant risk when granted to a third-party application.

Mail.ReadWrite.All
Read and write access to all mailboxes in the tenant. An app with this permission can read, send, delete, and move email for any user without their knowledge.
Files.ReadWrite.All
Read and write access to all files in OneDrive and SharePoint across the entire tenant. Includes the ability to delete or overwrite files.
User.ReadWrite.All
Read and write access to all user profiles, including the ability to reset passwords. Combined with other permissions, this can be used to escalate privilege.
Mail.Read (application permission)
Read-only access to all mailboxes. Less dangerous than ReadWrite but still allows an attacker to exfiltrate your entire email history.
Delegated permission grants
Permissions granted to act on behalf of users. These allow apps to access user data whenever that user is active — without requiring the user's explicit action on each access.

How to find this in your tenant manually

Go to Entra admin centre → Enterprise applications → All applications. For each application you don't recognise, click through to Permissions and review what has been admin-consented. Look specifically for application permissions (not delegated) with broad scope — anything ending in .All on sensitive resources like Mail, Files, or Users.

This process is manual, time-consuming, and easy to miss. There's no built-in report that says "here are the dangerous apps" — you have to click through each one individually.

How M365Clarity automates this

M365Clarity's App Registration Audit scans all service principals in your tenant via the Microsoft Graph API and flags any third-party application that has been granted admin-consented permissions with write access to mail, files, or users.

For each flagged application you see:

The audit runs as part of every M365Clarity scan. If a new application is added to your tenant with broad permissions, it will appear in your next scan results.

What to do when you find something: Don't immediately remove consent for every unfamiliar app — some are legitimate integrations your users rely on. For each flagged app: identify who granted consent and why, check whether it's actively used, review whether the permissions it holds are proportionate to what it actually needs, and remove consent for any app that is no longer used or whose permissions exceed its legitimate purpose.

Restricting user consent going forward

By default, Microsoft 365 allows users to consent to applications requesting low-risk permissions — which means any user can connect a third-party app to your tenant without admin approval. M365Clarity flags whether your user consent settings allow this.

Best practice is to require admin approval for all application consent, or to configure the admin consent workflow so that users can request approval rather than granting it themselves. This is configured at Entra admin centre → Enterprise applications → Consent and permissions → User consent settings.

Audit your enterprise app permissions

M365Clarity scans all third-party apps in your tenant and flags high-risk permission grants automatically.

Run a free scan →