Topic starter
14/07/2026 4:25 pm
TL;DR: Malicious OAuth applications can keep mailbox and file access alive after password resets and MFA enforcement, according to Proofpoint. Cloud tenants need app-level revocation and secret cleanup, or remediation may leave delegated access in place.
Editorial analysis by NHI Mgmt Group, based on content published by Proofpoint: “Beyond credentials: weaponizing OAuth applications for persistent cloud access”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Malicious OAuth applications can preserve access after user remediation, which means password resets and MFA enforcement do not necessarily end a cloud compromise.
Glossary terms: OAuth Application Persistence, Second-Party Application, Client Secret, Consent Grant
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
14/07/2026 4:33 pm
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.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
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.
👉 Read our full editorial: OAuth app persistence exposes a blind spot in cloud identity