Long-lived malicious OAuth apps expose a blind spot in M365 IAM

At a glance

What this is: This is a Cyera analysis of long-lived malicious Microsoft 365 OAuth applications that stay active by blending into normal tenant identity patterns and avoiding user-style security signals.

Why it matters: It matters because IAM teams often harden users while leaving application identities under-reviewed, which creates a blind spot for persistent access, MFA bypass, and hidden data exposure.

Context

Microsoft 365 environments can be well defended against direct user account takeover and still remain exposed through application identities. These apps authenticate legitimately, inherit trust through consent, and often keep access long after the original risk should have been re-evaluated.

The governance gap is not simply about detection speed. It is about treating application identities as first-class identities with review, revocation, and scope governance rather than assuming they behave like user accounts.

Key questions

Q: What is the failure mode when malicious OAuth apps stay enabled in Microsoft 365 tenants?

A: The failure mode is lifecycle drift. A consented application keeps its granted access long after the original approval should have been re-evaluated, so the tenant ends up with persistent non-human access that looks legitimate. That exposes data, identity context, and phishing pathways even when the environment is otherwise hardened.

Q: Why do long-lived OAuth applications create more risk than a one-time consent event suggests?

A: Because consent is only the start of the exposure, not the end. If the application keeps working without recertification, revocation, or ownership review, its access remains valid indefinitely. That turns a low-friction onboarding event into a standing access relationship that attackers can abuse quietly.

Q: What are the signs that Microsoft 365 compliance controls are failing in practice?

A: Common warning signs include untracked tenants, settings that drift away from the baseline, missing audit records, and changes that are not tied to a clear owner or approval trail. If teams cannot quickly tell what changed, who changed it, and whether the environment still matches policy, compliance is already degrading and likely to worsen over time.

Q: Should teams treat application identities the same way as user accounts?

A: No. User controls such as MFA and behavioural monitoring are necessary but incomplete for applications. Application identities need consent review, scope validation, publisher trust checks, and lifecycle offboarding, because their risk comes from persistent delegated access rather than interactive login behaviour.

Technical breakdown

Why OAuth consent creates durable application identity risk

OAuth consent gives an application delegated access without requiring the app to prove it is trustworthy over time. In Microsoft 365, that access can survive long after the original user interaction, especially when offline_access or other long-lived permissions are granted. The application then becomes a standing identity with its own scope, token use, and persistence characteristics. Security teams often tune controls for interactive user behaviour, but malicious apps do not need to look interactive to remain dangerous. They can sit quietly inside the tenant and continue to operate within expected platform mechanics.

Practical implication: treat consented applications as governed identities, not one-time approvals.

Why application identities evade user-centric monitoring

Application identities usually do not generate the same behavioural cues as a compromised user account. They may not use MFA, they often lack obvious login anomalies, and their activity can look like ordinary platform traffic rather than intrusion. That makes conventional monitoring biased toward the wrong signal set. The key issue is not whether the app is noisy, but whether its metadata, publisher trust, permissions, and prevalence still justify continued access. Without that review layer, malicious apps can remain enabled even when they are already known-bad or strongly suspicious.

Practical implication: pivot detection from login anomalies to app metadata, consent scope, and publisher trust.

How long-lived permissions turn one consent event into persistent exposure

The danger in these cases is cumulative exposure, not a single moment of compromise. Once an app is granted access, it can keep retrieving data or validating identities until someone deliberately revokes it. Cyera’s examples show that old campaigns can remain enabled for years, which means the control failure is lifecycle governance, not just initial approval. In identity terms, the tenant lacks a reliable offboarding and recertification model for non-human access. That creates an extended exposure window where a benign-looking application can still touch sensitive records long after its legitimacy has expired.

Practical implication: build lifecycle controls for app recertification, revocation, and offboarding.

Threat narrative

Attacker objective: The attacker aims to convert a single consent event into persistent, low-visibility access that can support data exposure, identity validation, and phishing enablement.

1. Entry occurs through legitimate OAuth consent or application installation rather than a technical exploit, which lets the malicious app enter the tenant as a trusted identity.
2. Credential access follows when the app uses granted scopes, such as offline_access or identity-related permissions, to maintain durable token-based access without repeated user interaction.
3. Impact emerges as the application continues to access sensitive data or support phishing and MFA bypass activity while remaining enabled for long periods.

Breaches seen in the wild

• Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Application identities are now a governance object, not a configuration detail. Cyera’s investigation shows that tenant hardening can coexist with a blind spot in non-human access review. The control failure is not at the login screen but in the lifecycle of consented applications, which can remain active long after their legitimacy has expired. Practitioners should treat app identity review as part of core IAM, not as an optional hunt exercise.

Persistent OAuth apps expose a standing-consent problem. The article shows that one-time approval can become durable access when applications are granted long-lived permissions and then left unreviewed. That breaks the assumption that low-friction consent is low-risk. For identity programmes, the issue is not just excess privilege at issuance but unmanaged privilege persistence across the application lifecycle.

Blind trust in publisher labels is a governance failure. Cyera describes cases where seemingly familiar names, verified labels, or disabled-but-not-removed apps created false reassurance. That pattern reveals a need to distinguish appearance from accountability, because a trusted-looking application can still be malicious. The implication is that application trust must be continuously re-established, not inherited from first sight.

Ephemeral consent is the wrong mental model for M365 application identity. The article shows that consented apps can persist for years, so the access event behaves like a standing identity unless it is actively revoked or recertified. That means the governance model should align application identities with lifecycle controls used for other non-human identities. Practitioners need to manage app consent as an ongoing access relationship, not a momentary permission.

Application identity review is the missing analogue to user recertification. The investigation demonstrates that malicious apps blend into normal tenant activity precisely because no equivalent review cadence exists for them. That is a structural gap in identity governance, not a tooling nuisance. The practitioner lesson is that app identities need recertification, ownership, and removal discipline at the same level expected for privileged access.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.

What this signals

Application consent is a lifecycle problem, not a point-in-time approval problem. Microsoft 365 app governance has to shift from initial consent review to continuous entitlement review, because malicious applications can persist with valid access for years. That creates a review gap that ordinary user monitoring does not close.

Persistent app identity exposure changes the meaning of least privilege. In this pattern, least privilege is not only about how much access an app gets at install time, but how long that access remains justified. A stale application identity with legitimate scopes becomes a durable control failure unless ownership and recertification are enforced.

For practitioners

• Review all consented Microsoft 365 applications Build a recurring review process for application identities, including publisher ID, reply URL, granted scopes, and tenant prevalence. Prioritise apps with long-lived access, offline_access, unfamiliar publishers, or no clear business owner.
• Revoke apps with mismatched metadata and permissions Flag applications whose name, homepage, reply URL, and permissions do not align with the stated business purpose. Treat mismatched metadata as a governance failure that warrants immediate investigation and, where necessary, removal.
• Treat disabled apps as still requiring offboarding Do not assume a disabled application is equivalent to deletion. Verify that service principals, consent grants, and token paths are actually removed so the application cannot be re-enabled or continue to expose data.
• Hunt for long-lived consent patterns Use tenant metadata and access logs to search for applications installed long ago, still enabled, or associated with known malicious infrastructure. Focus on persistence indicators rather than waiting for obvious interactive abuse.
• Separate app trust from user trust controls Apply different review logic to user identities and application identities. MFA and user-centric monitoring matter, but they do not replace app consent governance, scope validation, and periodic revocation checks.

Key takeaways

• Malicious Microsoft 365 applications can remain dangerous long after consent because application identities are often left outside normal IAM review cycles.
• Cyera found examples of long-lived apps that stayed enabled for years, including one case tied to more than one million sensitive records.
• The practical response is to govern consented apps as lifecycle-managed identities, with ownership, recertification, and revocation controls.

Key terms

• Application Identity Inventory: A continuously maintained record of every application that can authenticate users, issue sessions, or hold identity-related controls. In practice, this inventory must include managed, unmanaged, and shadow systems so auditors can verify where access rules, logs, and lifecycle evidence actually live.
• OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
• Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.
• Offline access control: The policy and technical handling of secret access when the system is used without live connectivity. In identity governance, offline access can be legitimate, but it usually weakens logging, makes audit harder, and should be treated as a controlled exception.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.