OAuth app persistence exposes a blind spot in cloud identity

At a glance

What this is: This is an analysis of how malicious OAuth applications create persistent cloud access that survives password resets and MFA changes.

Why it matters: It matters because identity teams must govern application consent, app registration, token lifecycles, and admin visibility as rigorously as user authentication and session controls.

👉 Read Proofpoint's analysis of malicious OAuth app persistence in cloud tenants

Context

OAuth persistence is a cloud identity problem, not just a phishing problem. Once an attacker controls a user account in Microsoft Entra ID or a similar tenant, they can create internal applications that inherit trust and continue operating after the original login is changed. That shifts the real risk from password compromise to application consent, token issuance, and secret lifecycle.

For IAM and NHI programmes, this is the uncomfortable part of modern cloud access: a user account can be recovered while the malicious application remains fully authorised. That means incident response focused only on password resets and MFA enforcement leaves the attacker’s programmatic foothold intact unless app registrations, client secrets, and granted scopes are also removed or reviewed.

Key questions

Q: What breaks when attackers create malicious OAuth applications in a compromised tenant?

A: The break point is the assumption that resetting the user account ends the compromise. Malicious OAuth applications can hold their own credentials and scopes, so access to mailboxes or files can continue after password changes. Teams must therefore revoke the app registration, its secrets, and its permissions, not just the user session.

Q: Why do OAuth apps create persistent identity risk for IAM teams?

A: OAuth apps create persistent identity risk because the access token or grant can remain active long after the point of approval. That makes them behave like non-human identities with lifecycle, review, and revocation requirements. IAM teams need to manage who owns the grant, what it can do, and whether it still needs to exist.

Q: How do security teams know whether an OAuth-connected app is operating outside its intended boundary?

A: Look for scope creep, unused permissions, unexpected API volume, and access from new IP ranges or proxy infrastructure. A healthy integration should have a clear owner, a limited purpose, and predictable API patterns. If the team cannot explain why the app still has access, the boundary is already being exceeded.

Q: Who is accountable when a malicious OAuth app keeps reading mail after a password reset?

A: Accountability sits with the organisation that granted and failed to govern the permission, not just with the user who clicked consent. The app should be treated as an identity with scope, ownership, and revocation rules. Frameworks that govern privileged access and lifecycle reviews are directly relevant because the grant behaves like standing access.

Technical breakdown

How malicious OAuth applications keep access after password resets

OAuth applications separate user authentication from application authorisation. In a compromised tenant, an attacker can register an internal app, assign scopes such as mailbox or file access, and then authenticate with the application’s own client secret and tokens. Because the app is now an authorised object in the tenant, a password reset on the original user does not automatically invalidate the app’s permissions. The persistence comes from the app registration, not the stolen password. Practical implication: review application-level trust as a distinct control plane, not as a side effect of user account recovery.

Practical implication: treat app registrations, client secrets, and consent grants as first-class incident response targets.

Why second-party app trust creates an NHI blind spot

Second-party applications are created inside the organisation’s own tenant, so they look internal and often inherit implicit trust. That matters because many security controls are tuned to monitor external OAuth consent, while attacker-created internal apps can blend into administrative noise. Once the attacker owns the app registration and configures scopes, the tenant may see legitimate-looking authentication from an internal resource. This is an NHI problem because the app is a non-human identity with its own credential and permission lifecycle. Practical implication: build discovery and review around internal app registrations, not just third-party consent.

Practical implication: inventory internal OAuth apps and review who can create them, not only who can approve them.

Client secrets and refresh tokens extend the dwell time

OAuth persistence depends on the attacker retaining something more durable than the user session. Client secrets let the malicious application authenticate independently, while refresh tokens allow new access tokens to be minted without user interaction. If those secrets are long-lived, the dwell time becomes a governance issue rather than a one-time compromise event. The article’s two-year secret example shows how an attacker can stretch a single foothold into prolonged access. Practical implication: align token and secret lifetimes to the minimum operational need, then continuously audit for orphaned or suspicious app credentials.

Practical implication: shorten secret lifetime and hunt for long-lived app credentials that outlive their business purpose.

Threat narrative

Attacker objective: The attacker wants durable programmatic access to mailboxes, files, and tenant resources that survives normal account recovery steps.

1. Entry occurs when attackers steal credentials and session cookies through phishing, reverse proxy tooling, or similar account takeover methods.
2. Escalation occurs when the compromised account is used to register an internal OAuth application, assign scopes, and create client secrets that outlast the session.
3. Impact occurs when the malicious application continues mailbox and resource access after password resets, enabling persistent exfiltration and follow-on activity.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Persistent OAuth access is an NHI lifecycle failure, not a password failure. The article shows that once an internal application is authorised, it can outlive the user’s login state and continue to operate after resets and MFA changes. That means the governance object is the app registration, its secret, and its scopes, not the human account alone. Practitioners should treat the application as the enduring identity that must be discovered, reviewed, and retired on its own lifecycle.

Internal OAuth apps create a trust inversion inside the tenant. Second-party applications are registered within the organisation and inherit enough legitimacy to evade controls built around external consent risk. Proofpoint’s example demonstrates that attacker-owned internal apps can look like ordinary business integrations while holding durable access to critical resources. The implication is that app-creation rights, consent boundaries, and tenant-level monitoring are part of identity governance, not just cloud hygiene.

Long-lived client secrets create identity blast radius. A two-year secret turns a single consent event into a prolonged access window with limited accountability. The problem is not merely that secrets exist, but that their lifetime can exceed the business context that justified them. Practitioners should view secret duration as a direct multiplier on compromise impact and recovery complexity.

Mailbox access is the visible symptom, but the control gap is broader. The same pattern can reach SharePoint, OneDrive, Teams, calendars, and contacts whenever the app receives those scopes. That is why application review must be tied to granted permissions, ownership changes, and offboarding of unused registrations. The implication is that identity teams need a tenant-level governance model for non-human access paths, not just user recovery playbooks.

Legacy IAM assumptions break when application identity can be self-provisioned by an attacker. Access reviews were designed for stable entitlements and known owners, but malicious OAuth apps can be created, armed, and used faster than many review cycles detect. The implication is that organisations must rethink how they define standing access, authoritative ownership, and revocation authority for internal app identities.

From our research:

• 23.7% of organisations share secrets through insecure methods such as email or messaging applications, according to The 2024 Non-Human Identity Security Report.
• A separate finding from the same report shows that 88.5% of organisations say their non-human IAM practices lag behind or merely match their human IAM efforts.
• For a broader view of the lifecycle problem, see 52 NHI Breaches Analysis, which links recurring access failures to weak identity governance.

What this signals

OAuth persistence is forcing IAM teams to treat internal applications as durable identities with their own offboarding requirements. The practical shift is away from password-centric recovery and toward lifecycle control for app registrations, secrets, and granted scopes. That change affects IAM, cloud operations, and SOC workflows at the same time.

The governance gap is wider than one platform. When an attacker can create an internal app that keeps working after user remediation, the enterprise has a blind spot in non-human identity discovery, consent review, and revocation authority. Teams should map that blind spot against OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs , Static vs Dynamic Secrets.

Identity blast radius: the useful way to think about this pattern is the amount of access a malicious app can retain after the original account is fixed. If that blast radius includes mail, files, chat, and calendar data, the tenant has already moved beyond account takeover and into application governance failure.

For practitioners

• Block uncontrolled internal app creation Restrict who can register second-party applications in the tenant and require explicit approval for any identity that can request sensitive scopes such as mailbox, file, or offline access.
• Review app permissions as part of incident response When a user account is compromised, revoke the application registration, remove granted permissions, delete the service principal, and invalidate all client secrets and tokens before closing the case.
• Shorten secret and token lifetimes Set the minimum viable validity period for client secrets and refresh tokens, then continuously look for long-lived credentials that remain active after the original business use has ended.
• Monitor for suspicious internal consent patterns Detect unusual app names, unexpected offline_access grants, and internal applications created shortly after account takeover signals, then correlate them with mailbox rule creation and VPN anomalies.

Key takeaways

• Malicious OAuth apps can preserve tenant access after the original user is remediated, which makes application lifecycle a core identity control.
• The evidence here points to a durable non-human identity problem, not a one-off phishing event, because app permissions and secrets outlive the stolen login.
• The limiting controls are app registration governance, secret rotation, scope review, and full revocation of the application object, not password resets alone.

Key terms

• Second-Party Application: An application registered inside an organisation's own tenant and therefore treated as internal. In identity governance terms, it is a non-human identity with its own ownership, scopes, secrets, and revocation lifecycle, which means it can become a persistent access path if not reviewed separately from the user account that created it.
• Client Secret: A client secret is a credential used by an application to prove its identity to an identity provider during token exchange. In OIDC, it functions like a password for the workload, so exposure in code, logs, or build artifacts can enable impersonation and downstream access.
• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• Consent Grant: A consent grant is the delegated approval a user gives an application to access data or APIs on their behalf. In OAuth environments, the grant can persist beyond the login session, so it becomes a governed access artefact rather than a one-time click.

What's in the full article

Proofpoint's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step demonstration of how the malicious OAuth application is registered and configured inside a compromised tenant.
• Token collection workflow showing how access tokens, refresh tokens, and client secrets are obtained and reused.
• Real-world telemetry details from the four-day account takeover, including the internal app named in the incident and the observed login pattern.
• Remediation sequence for revoking secrets, tokens, permissions, and service principals in the correct order.

👉 Proofpoint's full post covers the attack flow, PoC behaviour, and remediation sequence in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.