Notifications
Clear all
Topic starter
06/09/2026 6:20 pm
TL;DR: SalesLoft Drift breaches show how dormant OAuth tokens inherited through acquisitions can expose Salesforce and Google Workspace access across fourth-party relationships, according to Vorlon. The breach pattern proves that static vendor assessments miss inherited permissions and that continuous visibility into token behaviour is now essential for identity governance.
NHIMG editorial — based on content published by Vorlon covering the SalesLoft Drift breaches: fourth-party OAuth exposure and inherited token risk
Questions worth separating out
Q: What breaks when an acquired vendor’s OAuth tokens remain active?
A: What breaks is the assumption that ownership change resets access.
Q: Why do inherited OAuth grants create more risk than direct vendor access?
A: Inherited grants are harder to inventory, harder to attribute, and more likely to be forgotten during M&A.
Q: How can teams tell whether an OAuth grant is still legitimate?
A: Teams should verify current business ownership, current technical ownership, and current data reach.
Practitioner guidance
- Map inherited SaaS integrations after every acquisition Build an inventory of acquired applications, connected apps, delegated permissions, and legacy OAuth grants that may have crossed ownership boundaries.
- Revalidate business ownership for every dormant token Require the current business owner and current technical owner to be recorded before any OAuth grant remains active.
- Tie recertification to data reach, not app registration Review which Salesforce objects, Google Workspace resources, and other sensitive datasets each token can actually reach.
What's in the full article
Vorlon's full analysis covers the operational detail this post intentionally leaves for the source:
- A deeper walkthrough of how fourth-party OAuth exposure emerges during acquisition and integration inheritance.
- Operational recommendations for discovering dormant tokens, delegated grants, and legacy connected apps.
- Examples of runtime monitoring signals that distinguish legitimate usage from inherited access abuse.
- The article’s broader perspective on how SaaS consolidation changes the identity governance model.
👉 Read Vorlon's analysis of fourth-party OAuth exposure in the SalesLoft Drift breaches →
Fourth-party OAuth exposure: what it means for IAM teams now?
Explore further
06/09/2026 6:21 pm
Fourth-party OAuth exposure is a lifecycle problem, not just a vendor-risk problem: the breach pattern exists because access grants survive ownership changes unless someone actively revalidates them. Traditional third-party risk processes assume the counterparty stays stable long enough for periodic review. That assumption fails when acquisitions inherit dormant tokens and inherited permissions. The implication is that SaaS access governance must extend through acquisition history, not stop at the direct supplier.
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.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: Which control matters most after a SaaS acquisition: monitoring or revocation?
A: Revocation matters first because monitoring only sees access that is already live. Behavioural detection can reduce dwell time, but it does not remove inherited permissions that survived the acquisition and continue to work until somebody explicitly removes them.
👉 Read our full editorial: Fourth-party OAuth token exposure is redefining SaaS identity risk
