Notifications
Clear all
Topic starter
14/07/2026 4:26 pm
TL;DR: Third-party OAuth applications can preserve access after password resets and MFA enforcement, turning account takeover into delegated app abuse rather than simple credential theft, according to Proofpoint’s analysis of the April 2026 Vercel incident. The control problem is not just login security, but governance over which apps can act on behalf of users and how long those grants remain valid.
NHIMG editorial — based on content published by Proofpoint covering the April 2026 Vercel OAuth incident: third-party app abuse and persistent access paths
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern OAuth apps that have access to developer systems?
A: Security teams should treat OAuth apps as privileged NHIs and inventory them continuously, not just at approval time.
Q: Why are OAuth tokens risky even when MFA is enforced for users?
A: MFA protects the user login, but OAuth tokens can keep working after the initial approval without repeated user authentication.
Q: What breaks when organisations do not review third-party app permissions?
A: What breaks is visibility into who can act with enterprise authority outside normal login flows.
Practitioner guidance
- Inventory every authorised OAuth application Build a current list of apps with access to collaboration, cloud, and directory data.
- Revoke persistence after recovery events When you reset passwords or enforce MFA, also revoke tokens, refresh tokens, and risky third-party app grants.
- Classify AI and productivity apps by delegated authority Treat emerging AI tools as NHI-adjacent integrations that can act on behalf of users.
What's in the full article
Proofpoint's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact detection and response logic for risky OAuth authorisations and token abuse.
- Operational guidance on auditing authorised applications and identifying unnecessary scopes.
- The specific remediation steps for rotating secrets and removing persistent access paths.
- The collaboration security workflow Proofpoint describes for revoking malicious app access.
👉 Read Proofpoint's analysis of the Vercel OAuth incident and persistent access paths →
OAuth persistence and app abuse: what IAM teams need to know?
Explore further
14/07/2026 4:34 pm
OAuth persistence is a governance failure, not just an authentication failure. Once a third-party app receives delegated access, the organisation has created a durable identity path that sits outside normal login controls. Password resets, MFA enforcement, and session hardening do not remove that path unless token and app-grant governance exists. The implication is that access reviews must extend to trusted applications, not stop at user accounts.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when a trusted system is abused for mass impact?
A: Accountability sits with the owners of the privileged platform, the identity controls around it, and the resilience team responsible for containment. Frameworks such as NIST CSF and NIST SP 800-53 expect organisations to manage access, audit high-risk actions, and limit operational impact. If a control plane can wipe or expose assets at scale, that is a governance failure, not just an incident.
👉 Read our full editorial: OAuth persistence turns account takeover into trusted app abuse
