Topic starter
19/08/2026 3:30 pm
TL;DR: Delegated OAuth access can keep working after trust changes, Expel found in its report on Vercel and Context AI. Linked systems stay exposed until app inventory, scope review, and revocation catch up with the changed risk.
Editorial analysis by NHI Mgmt Group, based on content published by Expel: “OAuth hijacked: How a third-party breach hit Vercel”.
Key questions
Q: Why do compromised OAuth apps create such a high-risk access path?
A: Because the attacker inherits legitimate delegated access rather than forcing a fresh login or password compromise.
Q: How should security teams reduce the impact of malicious OAuth consent grants?
A: They should restrict which apps and users can complete high-risk consent paths, remove unnecessary Conditional Access exclusions, and review token reuse across app families.
Q: What breaks when a third-party OAuth app is compromised?
A: A compromised OAuth app inherits whatever delegated scopes users already approved, so the attacker can act through legitimate tokens instead of noisy intrusion methods.
Practitioner guidance
- Audit third-party OAuth consent grants Review all consented applications for scope, owner, and business justification, then flag grants that no longer match active use or approved vendors.
- Restrict user-approved permissions Limit which permissions users can grant to third-party apps, especially mailbox, data export, and offline access scopes that expand blast radius.
- Hunt for unexpected client IDs Search tenants for the disclosed application client ID and similar uncommon OAuth app identifiers to find where the same trust relationship exists.
Bottom line: A compromised third-party OAuth grant can expose data without a direct breach of the target platform.
Glossary terms: OAuth Consent, Third-Party App Governance, Client ID, Shadow app
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
19/08/2026 4:13 pm
Third-party OAuth consent is now part of the identity perimeter. Once a user grants an external application access, the security boundary extends beyond the local tenant and into the app's own compromise posture. That means a clean internal environment can still be exposed by a delegated relationship that was approved months earlier. Practitioners need to govern consented apps as identities with lifecycle and scope, not as passive integrations.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: When should organisations revoke third-party access credentials?
A: Organisations should revoke third-party access credentials whenever the business purpose changes, an incident occurs, the vendor scope expands unexpectedly, or the credential has not been explicitly revalidated. Standing access should be the exception, not the default. If the credential is no longer clearly justified, it is already overdue for removal.
👉 Read our full editorial: OAuth supply chain abuse exposed Vercel data through third-party access