Fourth-party OAuth token exposure is redefining SaaS identity risk

At a glance

What this is: This is an analysis of fourth-party OAuth exposure after acquisitions, with the key finding that dormant inherited tokens can survive ownership changes and still access customer data.

Why it matters: It matters because IAM, IGA, and SaaS security teams must govern not just direct vendors but inherited integrations, standing OAuth access, and offboarding across acquisition chains.

👉 Read Vorlon's analysis of fourth-party OAuth exposure in the SalesLoft Drift breaches

Context

Fourth-party OAuth exposure is the gap that appears when a vendor acquires another company and inherits its tokens, integrations, and permissions. In this case, the concern is not a direct compromise of the customer’s own controls, but the persistence of access that survives ownership changes and remains valid unless someone explicitly revokes it.

For identity governance, this is a non-human identity problem first and a supply-chain problem second. OAuth tokens, API connections, and connected apps are all machine-held credentials that can outlive the business relationship that created them, which means lifecycle control matters as much as initial approval.

The primary lesson for IAM teams is that vendor due diligence cannot stop at the contracted counterparty. If the environment includes SaaS integrations, Google Workspace access, or Salesforce connected apps, then acquisition inheritance becomes part of the access model and must be governed as such.

Key questions

Q: What breaks when an acquired vendor’s OAuth tokens remain active?

A: What breaks is the assumption that ownership change resets access. A token may continue to authenticate into Salesforce or Google Workspace even after the business relationship has changed, so inherited grants can expose data long after the original justification disappears.

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. That combination makes them ideal for long-lived exposure, because the customer often monitors the direct supplier but not the supplier’s acquisitions or legacy integrations.

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. If any of those three no longer align, the grant should be treated as standing access that needs immediate review, because legitimacy is no longer self-evident.

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.

Technical breakdown

How inherited OAuth tokens survive acquisition chains

OAuth refresh tokens and connected-app grants are designed to persist until revoked, which is useful for continuity and dangerous in mergers and acquisitions. When a company is acquired, the technical owner changes, but the token may still authenticate exactly as before. That creates a trust mismatch between business ownership and runtime access. In practice, the dangerous part is not token creation, but token persistence across organisational boundaries, especially where no one revalidates the integration after the acquisition closes.

Practical implication: inventory every acquired integration and revoke any token whose business owner cannot be positively confirmed.

Why connected apps create hidden SaaS attack surface

Connected apps extend access from one platform into another, often through delegated permissions that are broad enough to read mail, query records, or export files. The access path is usually opaque to the customer because the grant sits inside the upstream application and may not be visible in a standard vendor inventory. That is why traditional questionnaires miss the real risk. The attack surface is not only the app you bought, but every inherited connector the app can still use at runtime.

Practical implication: build runtime visibility for OAuth-connected apps, not just a static vendor register.

OAuth archaeology and identity blast radius

OAuth archaeology is the discipline of tracing which tokens still exist, what data they can reach, and whether the business relationship that justified them still exists. It is less about searching for secrets than about mapping identity blast radius across acquisition chains. In this case, the blast radius includes Salesforce and Google Workspace because inherited tokens can retain data-plane reach long after the original product boundary has changed. That makes ownership history part of the access-control model.

Practical implication: tie token review to acquisition events, not calendar-based recertification alone.

Threat narrative

Attacker objective: The attacker’s objective was to abuse trusted OAuth access to extract customer data from SaaS environments without needing to break primary authentication.

1. Entry occurred through legacy OAuth tokens associated with the Drift application after the acquisition chain created inherited access paths.
2. Escalation came from valid delegated permissions that allowed the attacker to enumerate Salesforce data and touch a limited number of Google Workspace accounts.
3. Impact was cross-tenant exposure of customer data through trusted SaaS integrations that remained active long after the original business context had changed.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Identity blast radius is now shaped by corporate structure as much as by technical design: one acquired company can bring old integrations, old tokens, and old trust into a new ownership boundary. That means the effective access model changes whenever M&A occurs, even if the customer never changed its own configuration. For identity teams, the real question is no longer whether the vendor is approved, but whether every inherited grant still fits the current business relationship.

OAuth tokens are durable credentials, which makes them governance objects, not just technical artefacts: if a token can continue to work through restructurings, bankruptcies, and acquisitions, then it needs lifecycle ownership like any other NHI. The control gap is not token issuance. It is the absence of a reliable offboarding trigger when business ownership changes. Practitioners should treat inherited OAuth grants as standing access with a delayed failure mode.

OAuth archaeology should become a named governance concept for acquired SaaS estates: tracing inherited integrations, undocumented grants, and dormant permissions is now a repeatable discipline, not an ad hoc investigation. This is where OWASP-NHI, Zero Trust, and SaaS governance converge: runtime access must be verified against current ownership, current data sensitivity, and current necessity. The practical conclusion is that acquisition-aware recertification belongs in every serious NHI programme.

Continuous monitoring is necessary, but it does not replace lifecycle control: watching a token behave anomalously is useful after the fact, yet the better governance question is why the token remained active after the business context changed. Monitoring detects misuse; lifecycle management prevents inherited access from becoming normalised. That distinction matters because fourth-party exposure is created by persistence, not by novelty.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: 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.
• Acquisition-aware token governance is the next practical step, because inherited OAuth access turns supplier diligence into a runtime identity problem rather than a paperwork exercise.

What this signals

OAuth archaeology: organisations should start treating acquired integrations as live identity infrastructure, not historical artefacts. The governance question is whether every token, connector, and delegated grant can still be justified against the current business relationship and current data sensitivity.

The operational signal is straightforward: if a vendor can inherit permissions faster than your team can review them, then calendar-based recertification will always lag the risk. Continuous visibility across SaaS integrations, plus acquisition-triggered offboarding, is the only credible way to reduce inherited blast radius.

Teams that already use Zero Trust language should apply it to third-party tokens as well. The practical bar is current verification of current access, backed by acquisition-aware inventory and behaviour monitoring from sources such as NIST Cybersecurity Framework 2.0.

For practitioners

• 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. Treat the acquisition date as an access-review trigger, not an accounting event.
• 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. If ownership cannot be confirmed, revoke the token and force reauthorisation through a controlled workflow.
• Tie recertification to data reach, not app registration Review which Salesforce objects, Google Workspace resources, and other sensitive datasets each token can actually reach. Prioritise grants with export, mailbox, or bulk-read capability because those are the paths that expand blast radius fastest.
• Monitor OAuth behaviour for acquisition-era anomalies Alert on unusual access patterns such as high-volume reads, access from unfamiliar geographies, or activity outside normal business hours. Use behavioural telemetry to identify tokens that remain valid but no longer belong in the environment.

Key takeaways

• Fourth-party OAuth exposure shows that the real identity perimeter now follows corporate acquisitions, not vendor contracts.
• The scale problem is visibility, because inherited tokens can remain active long after the business context that created them has disappeared.
• Acquisition-triggered revocation, current ownership validation, and runtime monitoring together reduce the risk that dormant delegated access becomes a breach path.

Key terms

• Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.
• OAuth archaeology: OAuth archaeology is the process of tracing every active OAuth grant, delegated permission, and dormant token back through ownership changes and integration history. It matters because access can survive mergers, rebrands, and product pivots even when the original business justification no longer exists.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Inherited token persistence: Inherited token persistence is the continued validity of a machine credential after the company, app, or service that created it has been acquired or changed hands. It is a lifecycle failure when revocation does not track ownership changes.

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.

👉 Vorlon's full post covers the acquisition chain, token persistence, and runtime exposure in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.