Notifications
Clear all
Topic starter
14/07/2026 4:25 pm
TL;DR: Malicious OAuth applications can preserve access after password resets and MFA enforcement, enabling mailbox and file access to continue inside compromised cloud tenants, according to Proofpoint. That persistence window turns OAuth consent, app registration, and secret lifecycle into the real control surface, not just user authentication.
NHIMG editorial — based on content published by Proofpoint: LLMjacking and malicious OAuth application persistence in cloud environments
Questions worth separating out
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.
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.
A: Look for scope creep, unused permissions, unexpected API volume, and access from new IP ranges or proxy infrastructure.
Practitioner guidance
- 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.
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.
👉 Read Proofpoint's analysis of malicious OAuth app persistence in cloud tenants →
OAuth app persistence in cloud tenants: are controls keeping up?
Explore further
14/07/2026 4:33 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth app persistence exposes a blind spot in cloud identity
