In-Depth
The Threat Lurking in Your Entra Directory
What do the recent Salesloft / Drift and Commvault breaches have in common? If you answered “OAuth applications”, you'd be right. There's a hidden danger lurking in most organizations Entra ID directories, waiting to be exploited. We recently looked at the risks of SaaS apps being compromised, and that article is a good primer on the risks associated with SaaS apps that your business is relying on. These SaaS apps, and other types of add-ins are registered in your Entra ID (or Google or Salesforce). And these live alongside applications your users have individually consented to, as well as any apps that administrators have approved company wide. These bring risks to your business in an area of your infrastructure that's generally not well governed.
In this article we'll dive into the threats that OAuth registered applications can bring, and how you can manage that risk, both from a technical standpoint as well as how you can communicate this to decision makers.
The Basics
In the beginning there was Active Directory (AD), now over 25 years old, and it's where most older IT professionals started their identity journey. Here it was “easy”, applications could be installed anywhere in your infrastructure, but rarely interacted with your directory, except when they wanted to extend the schema. The AD schema defines what fields are available for a user account for example (first and last name, department etc.) and if you deployed Exchange Server, it needed to add its own fields (distribution groups, mailbox location etc.).
If the application needed to run under an account with permissions, we just created a user account, gave it a password (often set to never expire) and gave it all the permissions the application developers asked for (or just Domain Admin, because then it just works). This approach was (and still is) terrible from a security point of view -- please use gMSA, Group Managed Service Accounts, as Service Principals whenever possible.
Entra (formerly Azure AD) is different -- every application that needs to interact with any object (data, user or group accounts, etc.) through an API in your tenant -- requires a registration. There are two ways this can happen, either an end user installs an extension (such as a ChatGPT button into Word to easily use Generative AI when editing documents) and grants it permissions to the users own data or an administrator grants an application permissions to the entire directory (a M365 mailbox backup service for example would need access to everyone's mailboxes).
Once an application is registered, the permissions it has been granted, and the scope of them, are available to the app to use. Apps can be single-tenant, an application you develop and deploy in your tenant, or multi-tenant where it's housed in the vendors tenant, but an instance of it is registered in your tenant.
[Click on image for larger view.] Example of an OAuth Consent Dialog.
In this dialog you can see the permissions requested, and since the account signed in is an administrative account, the option to consent for the whole tenant is available.
The default used to be that end users could grant permissions to a set of lower risk permissions to their own data, with the option to restrict this to either a set of permissions you felt were acceptable or disable the option for end-users to grant permissions altogether. This approach also allowed you to set up an administrative workflow where the end user could ask administrators to grant them access to the app (admins receive an email with a link to the portal where they can review the app and either allow it or block it).
[Click on image for larger view.] User Consent Settings in Entra.
Note that in October 2025 the default was changed to require admin consent for more permissions, full list here.
[Click on image for larger view.] Admin Consent Settings in Entra.
There are a few different risks with apps, particularly ones with highly privileged permissions. First, if the application is malicious, it can use all the permissions granted to steal data or alter data. A classic example is an Outlook add-in that sends emails on behalf of a user, asking to change an account number for invoice payments, leading to Business Email Compromise. A malicious application could be one that an end user is tricked into installing / granting permissions to (if end users are allowed to do this), or a previously benign application that has changed owners or been compromised. This is what happened to Salesloft, where the company behind this add-on to Salesforce was compromised, and attackers stole their OAuth access tokens and used them to access Salesforce data from Cloudflare, Zscaler, Palo Alto Networks, Google, Tenable and Proofpoint and others. Over 700 organizations are thought to have been impacted.
Now you understand how applications can end up in your directory, and the risks associated with the broad permissions they can have. This problem is also growing for two reasons, firstly citizen developers using Power Platform to generate internal apps that need permissions in Entra. These users certainly aren't experts in API permissions and will request the permissions they think they need to make the app work which will introduce risk. Secondly -- AI agents will be given a new type of identity and permissions in Entra (in preview at the moment). Currently this is only available for Copilot Studio and Azure AI Foundry created agents but will presumably extend to third party AI agents in the future.
Thus, there will be even more apps registered in your Entra tenant in the future, but what do you do with the applications that are already there?
Defender XDR Application Governance
You have a few different options to inventory the applications you have, and their associated permissions. Start in the Entra portal -- Enterprise applications to see the list.
[Click on image for larger view.] Enterprise Applications in Entra ID - Non-Microsoft only.
By default, this list is filtered to only show the applications that you have added, if you want to see the full list, remove the Application type == Enterprise Applications filter:
[Click on image for larger view.] Enterprise Applications in Entra ID - the Full List.
In this tenant, you can see the list go from 68 to 712(!). Microsoft manages these, normally hidden, applications used to provide the functionality of M365 so you shouldn't have to worry about their security.
For each application you can inventory the permissions that have been granted (under Security -- Permissions) and if you click Review permissions, a list of options is provided to remediate risk if you think the app is suspicious or malicious.
[Click on image for larger view.] Permissions Granted to an Application and Remediation Options.
This approach doesn't scale well, unless you have hordes of idle identity administrators that you can task to go through each app manually, and continue to do so as new apps are introduced.
If you have Defender for Cloud Apps licensing (part of M365 E5) you'll have access to App governance. This lets you connect M365 (Entra) as well as Salesforce or Google directories to show OAuth apps deployed there and it comes with several built-in policies enabled. It'll sort them by overprivileged / highly privileged apps, show you the data usage per month, and the type of object accessed (email or documents), plus apps with unused permissions that they have been granted. A recent addition is the Assets -- Applications that has a tab for SaaS apps, and another for OAuth apps, bringing the two worlds together.
[Click on image for larger view.] Default Set of App Governance Policies in Defender for Cloud Apps.
You can also create custom policies with a host of different conditions, and also automatically disable the app:
[Click on image for larger view.] List of Policy Conditions in Defender for Cloud Apps Governance Policy.
ENOW Application Governance
One example of a third-party option to manage this risk is ENOW (I have no financial or other relationship with ENOW). They offer a free Application Governance Assessment Report, which looks like this (for the same tenant used above) once you agree to a set of read only permissions to your Entra tenant.
[Click on image for larger view.] Application Governance Assessment Report.
This report takes a few minutes (longer if you have many apps) and gives you basic information about your app landscape, with explanations for each test. Realistically you'll want to take advantage of the seven-day trial of the Standard version to understand the ramifications. Standard gives you more information about the risks (with a daily scan) and much more comprehensive information:
[Click on image for larger view.] App Governance Accelerator Standard Example Page.
Recommendations
Start by disabling the ability for end users to add apps without going through an admin approval (FWIW, this is how I have set it up for my clients). That stops more potential problems being added as you're dealing with the existing ones. Make sure you have processes in place for managing the potential deluge of app requests from your end users.
Then, you need to understand the scope of the problem. Use the built-in tools / scripts or one of the other tools covered here (or another third party offering) to see the extent of the issue. You'll want a clear understanding of the apps that have high privileges, especially where they're scoped to the entire tenant. And you'll want insight into usage, if an app is rarely used it's a candidate for removal, but be careful, sometimes an app is only used twice or four times a year for a specific business process. Spotting uncommon apps that are only present in a few tenants worldwide is another signal to investigate further.
Next, you'll need to start working through the list, focusing on the riskiest apps, whittling down the list. You'll also need an onboarding process so that new apps can be evaluated before being introduced, as well as an offboarding process. Most applications don't remove their Enterprise app registration when they're uninstalled, leaving them orphaned and potentially a gap that could be exploited.
And you'll need leadership buy-in, because in larger organizations, particularly where app governance hasn't been taken seriously before, this will need resources allocated to it. In some businesses, the governance of apps is left to the app owner (generally a an end user with minimal understanding of the risks), or the general IT team, who also may not have experts on hand to quantify the risks. A high-profile breach due to OAuth permissions that's in the mainstream news can be the catalyst for a productive conversation to take this threat seriously.
Conclusion
App registrations is the modern, cloud version of “infrastructure that's invisible when it works”, such as DNS. Nobody thinks of them until they suddenly break (exhibit A: AWS outage October 2025), just as no-one was worried about the Salesloft / Drift integration into their Salesforce tenant -- until attackers stole all their client data and help desk logs.
Comparing Defender for Cloud Apps to ENOW's offering my recommendation would be that if you already have the licensing (M365 E5/A5), use Application Governance as outlined above, but if you don't, take a good look at ENOW's plans, there's Standard, Professional and Enterprise. It has more complete workflow and automation tools built in to manage the overall challenge in a large enterprise, and the higher levels of licensing also come with expert consultation hours.
Entra is a complex beast, and Enterprise application registrations are convenient but, in most cases, an unmanaged risk -- don't let the danger lurk in the shadow, bring it out into the light and work to limit your exposure.