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 preserve access in cloud tenants after account remediation, with Proofpoint showing that app-level trust can outlast password resets and MFA.

Why it matters: It matters because IAM and NHI teams cannot treat user recovery as the end of an incident when app registrations, secrets and delegated scopes can keep access alive.

Context

OAuth applications can become a persistence layer inside cloud identity environments when the application, not just the user, remains trusted after compromise. In practical terms, that means access can survive password resets and MFA enforcement if the app registration, secret and granted scopes are still valid.

Proofpoint's analysis focuses on the gap between user-centric recovery and application-centric persistence in Microsoft Entra ID. The governance problem is straightforward: if an internal application can be registered, authorised and left in place, it becomes a durable access path that typical incident response may miss.

The article combines a proof of concept with telemetry from a real account takeover case, which is a typical pattern for this kind of cloud identity abuse. The central issue is not whether authentication works, but whether the platform can see and govern the full lifecycle of the OAuth application itself.

Key questions

Q: Why do OAuth app attacks continue after a password reset?

A: Because the attacker is not relying on the password once consent has been granted. The tenant has already issued tokens and a service principal for the approved app, so the access path lives in the application grant. Revoking the user password does not automatically revoke that trust relationship or the permissions it created.

Q: When should security teams revoke OAuth app access instead of relying on user resets?

A: They should do it whenever the investigation shows a consented app, service principal or client secret may have been created during compromise. User resets help, but they do not terminate application-level authorisation. The safer sequence is to revoke the app grant, invalidate secrets and then restore the account.

Q: What are the warning signs that OAuth consent is being abused?

A: Warning signs include unexpected app registrations, broad scopes that do not match user role, consent events from unmanaged devices, and access patterns that continue after the original user interaction. The key indicator is persistence through delegated permissions rather than a one-time login anomaly. Security teams should treat those signals as active access, not benign configuration noise.

Q: What should teams do immediately after discovering a malicious OAuth grant?

A: Revoke the app grant, invalidate refresh tokens, terminate active sessions, and review any mailbox or API actions already taken through the compromised scopes. If the app was backdoored into a workflow, remove the malicious integration and confirm no additional delegated access remains.

Technical breakdown

How malicious OAuth apps become trusted internal access

In Microsoft Entra ID, a second-party application is one registered inside the tenant and therefore treated as an internal resource rather than an external integration. That matters because the application can inherit trust from the organisation's own directory, even when it was created by a compromised account. Attackers exploit this by registering an app, assigning scopes such as mailbox access, and using the tenant's own governance blind spots to make the app look routine. The persistence problem is created by legitimate platform behaviour, not by a broken login screen.

Practical implication: treat internal app registrations as security-relevant assets, not just admin clutter.

Why client secrets and token types extend the compromise window

Once the malicious application exists, the client secret becomes the application's own credential, independent of the user's password. Access tokens, refresh tokens and ID tokens each serve a different role, but the important point is that the application can continue to request access after the original user session is disrupted. If the secret remains valid for long periods, the attacker can keep generating tokens without re-entering the user's authentication flow. This is why OAuth persistence behaves more like a standing credential than a one-time phishing event.

Practical implication: review application secret lifetime and revocation paths as part of incident containment.

Why password resets do not terminate OAuth persistence

Password resets and MFA enforcement are effective against the user account, but they do not automatically invalidate every application that the account authorised earlier. If the app registration, consent grant and service principal remain in place, the attacker still has a valid path into mailbox and file resources. That is the critical design gap: the access control decision was made at consent time, and the platform continues to honour it until someone explicitly removes the app or revokes its permissions. In other words, the compromise survives because the authorisation boundary sits outside the user's password state.

Practical implication: make app consent revocation and service principal removal part of remediation playbooks.

Threat narrative

Attacker objective: The attacker wants durable, unattended access to cloud resources such as mailboxes, files and collaboration data even after the user account is remediated.

1. Entry begins with AiTM phishing or a reverse proxy toolkit that steals credentials and session cookies from the cloud user account.
2. Credential access is converted into persistence when the attacker registers a malicious internal OAuth application and grants scopes such as Mail.Read and offline_access.
3. Escalation occurs when the app is given a client secret and token material that lets it keep requesting authorised access after password changes.
4. Impact is sustained mailbox, file and collaboration-data access that continues until the app registration, permissions and secrets are removed.

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

OAuth app persistence is a lifecycle problem, not just an authentication problem. The compromise persists because consented applications, service principals and client secrets remain valid after the user password is changed. That breaks the common assumption that account recovery ends the incident. Practitioners should treat application lifecycle governance as part of identity security, not as a separate admin task.

Client secret persistence creates a standing credential window that password policy cannot close. A malicious application with a long-lived secret can continue to request tokens independently of the user session that created it. That is structurally different from stolen password reuse because the credential belongs to the application, not the person. The implication is that secret lifetime is now a core control plane for cloud identity risk.

OAuth consent is effectively an authorisation grant that outlives the moment of compromise. Once a tenant authorises an application, the platform keeps honouring that decision until permissions are revoked or the app is removed. This means cloud IAM teams need to treat app consent as a governed entitlement with review, revocation and offboarding obligations. The practitioner takeaway is simple: consent without lifecycle control becomes persistent access by design.

App registrations are the cloud equivalent of hidden NHIs when they are created from compromised accounts. The article's PoC shows how an internal app can blend into normal directory operations while functioning as a backdoor. That is a named governance gap we can call consent-led persistence: access granted once, then forgotten. The implication is that discovery and offboarding have to cover applications, not only human users.

Cloud identity defence has to move from user remediation to access path termination. Proofpoint's telemetry shows that attackers are already exploiting this gap in the wild, which means the issue is operational rather than theoretical. The important conclusion for IAM and NHI programmes is that application grants, secrets and tokens now sit alongside passwords as first-class identity risks.

From our research library:

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

What this signals

Consent-led persistence should now be treated as a distinct governance pattern in cloud identity programmes. The platform's trust decision is made at authorisation time, so remediation that stops at the user account leaves the access path intact.

Application offboarding has to become part of identity lifecycle management for both human and non-human access paths. If a tenant can register internal apps from compromised accounts, discovery and revocation need to cover app owners, secrets and grants together.

For practitioners

• Audit internal app registrations for persistence risk Inventory second-party applications, their owners, granted scopes and associated secrets so you can identify internal apps that outlive their business purpose.
• Revoke application secrets and tokens during containment If an OAuth app is suspected malicious, invalidate client secrets, remove certificates, revoke user tokens and delete the registration before closing the incident.
• Add consent review to identity governance workflows Require periodic review of delegated scopes, service principals and app ownership so application access can be certified and removed like any other entitlement.
• Monitor for deceptive internal app naming patterns Alert on newly created apps with generic or business-like names, unusual Mail.Read or offline_access grants, and creation by recently compromised accounts.
• Train users to treat unexpected consent prompts as suspicious Educate users to question application consent requests, report unusual authorisations and avoid granting access to apps they do not recognise.

Key takeaways

• Malicious OAuth applications can preserve access after user remediation, which means password resets and MFA enforcement do not necessarily end a cloud compromise.
• Proofpoint's telemetry shows the pattern is not theoretical, with a real account takeover persisting for days after the initial compromise.
• The control that matters most is application lifecycle termination, including revocation of consent, removal of secrets and deletion of the registration.

Key terms

• OAuth Application Persistence: OAuth application persistence is the ability of an authorised app to keep accessing tenant resources after the original user login is recovered. In cloud identity environments, the durable object is the app grant, secret and token path, not the person who approved it.
• 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.
• 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.

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.