An attacker may not need your password to read every email in your Microsoft 365 tenant.
They need one user to approve a permission request. MFA will not stop it. Conditional access may not stop it. Endpoint hardening will not stop it. The enterprise application sitting in Microsoft Entra ID with mailbox permissions no one has reviewed in three years is the open door, and attackers know exactly how to find it.
OAuth consent attacks can establish persistent tenant access through token theft, or credential compromise. Enterprise applications can be hard to detect entry point, and they are the one most organizations forget to secure.
Enterprise applications are third-party or internally developed apps connected to your Microsoft 365 tenant through OAuth or Microsoft Graph API integrations. They live in Microsoft Entra ID, formerly Azure AD, and serve real purposes. Single sign-on, data sync, email integrations, and security tooling all run through them.
When a user clicks "Accept" on a permissions consent prompt, the application registers in the tenant. It receives whatever permissions the user approved. That can include mailbox data, OneDrive and SharePoint files, Teams messages, calendars, and user profiles.
Some are Microsoft first-party products or tools your team deployed on purpose. In older tenants, applications also pile up from projects, vendor trials, and one-off integrations. People leave, projects end, and the applications stay behind. That accumulation is where the risk starts.
Enterprise applications sit in a gray area that most security reviews skip. Simply because they do not produce the same signals as other threats.
A suspicious sign-in generates an alert. A phishing email gets flagged. An enterprise application with broad OAuth permissions can read mailbox data, pull files, and call Microsoft Graph APIs without producing one security signals. The traffic looks like normal API activity because it is technically authorized.
That makes enterprise applications hard to detect with standard monitoring. The longer they go unreviewed, the larger the exposure becomes.
This blind spot is an actively exploited attack vector, not an administrative footnote.
Consent phishing, also called an OAuth consent attack, works by tricking a user into granting permissions to a malicious application. The attacker registers an app that impersonates a known service, such as a document sharing tool or cloud storage connector. A phishing email sends the user to a real Microsoft login page with a consent prompt. The user clicks "Accept". The attacker receives an OAuth token that grants tenant access.
Because the access is token-based, it survives password resets. That makes it difficult to revoke after the fact.
This is happening at scale. In May 2026, the FBI issued a public advisory about Kali365, a phishing-as-a-service platform that automates device code phishing to harvest Microsoft 365 OAuth tokens. Those tokens are often used to facilitate consent for Malicious OAuth Applications. Security researchers at Wiz identified 19 malicious OAuth applications impersonating brands like Adobe, Microsoft OneDrive and DocuSign, affecting more than 20 organizations. In May 2026, ConsentFix v3 appeared on underground forums, automating the full consent phishing chain from reconnaissance to token extraction.
One of the biggest contributors to this problem is a default setting that many organizations never revisit. User consent.
For many years, the default setting in Microsoft 365 let any user grant permissions to third-party applications without administrator approval. A single user can authorize an app to access their email or files. No one else in the organization will know unless they go looking.
Blocking all consent breaks legitimate tools. Leaving it open creates an exploitable surface. The recommended middle ground has three parts:
Disable user consent for OAuth apps. This stops users from granting broad access like Mail.Read or Files.ReadWrite.All on their own.
Enable an admin consent workflow. New application requests route to an administrator for review before access is granted.
Pre-approve low-risk permissions. Applications that only need basic profile information for single sign-on can run without adding friction.
These settings are in the Entra ID portal under Enterprise Applications, then Security, then Consent and Permissions.
If your enterprise applications have not been reviewed recently, start with visibility into what is already connected.
Open the Microsoft Entra admin center and go to Enterprise Applications under Identity and Applications. This view shows every application with a service principal in your tenant. Sort by recently added applications, elevated permission scopes, or low user counts to surface the highest-risk entries first.
Check the granted permissions for each application. Note the difference between user consent and admin consent. User-consented applications are the most likely to have been authorized without formal review. Watch for scopes such as Mail.Read, Files.Read.All, Files.ReadWrite.All, and User.ReadWrite.All. These can expose a lot of data if the application is compromised.
Cross-reference the list against what your organization actively uses. An application provisioned for a project that wrapped years ago is a strong candidate for removal. An application that no one recognizes warrants immediate investigation.
For years, the primary option for a suspicious enterprise application were to leave it running or delete it. Deletion removed all configuration, permissions, and metadata. That was disruptive if the application turned out to be legitimate, and it destroyed forensic evidence if the application proved to be malicious.
Microsoft closed that gap in early 2026 with application deactivation in Entra ID. Deactivation does the following.
It blocks the issuance of new access tokens. Existing tokens stay valid until they expire, but no new tokens are issued. It preserves all configuration, permissions, and metadata. It keeps the application in the Enterprise Applications list for continued investigation. It is fully reversible with a single action if the application is determined to be safe.
Here is how deactivation compares to the other remediation options in Entra ID:
|
Action |
Token Issuance |
Configuration Preserved |
Reversible |
|
Deactivate |
Blocked |
Yes |
Yes |
|
Disabled by Microsoft |
Blocked |
Yes |
Yes |
|
Disable Sign-In |
Blocked in tenant |
Yes |
Yes |
|
Delete |
Blocked |
No (30-day recycle bin) |
Yes (30 days) |
This changes how incident response works. You can cut off a suspicious application's access without losing the evidence needed to investigate the breach. It also helps with routine maintenance. If you are not sure whether an older application is still in use, deactivation lets you measure the impact before committing to a permanent decision. If nothing breaks after a few weeks, you have your answer.
Deactivation runs through the Entra admin center under App Registrations, or through the Microsoft Graph API. It requires at least the Cloud Application Administrator role.
One important detail: Review application owners before deactivating. If owners stay assigned, they can reactivate the application on their own.
Enterprise applications are foundational to how Microsoft 365 works. They power integrations, automate workflows, and support the productivity the platform is built to deliver. They are also one of the most under monitored attack surfaces in most tenants.
Permissive default consent settings and a rising volume of OAuth-based attacks have created a gap many organizations have not fully acknowledged. The controls to close that gap exist in Entra ID today. Review what is connected, restrict what users can authorize, and put a process in place for handling suspicious applications before you need one.
Open your Entra ID portal, review what is connected, and close the gaps before someone else finds them.
Want a second set of eyes on your enterprise applications? Contact Sourcepass MCOE to review what is connected to your tenant.
Related Reading:
Watch our video on How Microsoft 365 is Reshaping AI, Security, and Governance