Third-party SaaS tokens are becoming an identity time bomb

At a glance

What this is: This analysis shows how third-party SaaS integrations can turn long-lived OAuth tokens into an enterprise-wide identity risk.

Why it matters: It matters because IAM, NHI, and governance teams need continuous ownership of app credentials and integrations, not just one-time onboarding checks.

By the numbers:

• In the 2025 breach, attackers used stolen OAuth tokens from a third-party SaaS integration to access a slew of customer systems.

👉 Read SafePaaS's analysis of third-party SaaS identity risk and token exposure

Context

Third-party SaaS risk is an identity problem before it is a procurement problem. When applications, bots, and APIs are connected through long-lived OAuth tokens, the organization has effectively created machine credentials with durable trust and weak visibility. That is why a breach can begin in one integration and spread into systems that were never meant to share that level of access.

The article’s core point is that governance stopped at onboarding. Tokens were over-privileged, rarely reviewed, and left in a no-one-owns-this gap between customer and vendor accountability. For IAM and NHI teams, that is the real control failure: the identity exists, but its lifecycle is unmanaged after initial approval.

Key questions

Q: How should security teams govern third-party SaaS integrations that use OAuth tokens?

A: Security teams should govern them like non-human identities with ownership, scope, and lifecycle controls. That means inventorying every connector, assigning a business and technical owner, enforcing token expiration and rotation, and requiring periodic attestation that the access is still needed. If a token cannot be revoked quickly, it is already too risky.

Q: Why do long-lived application tokens increase enterprise breach risk?

A: Long-lived tokens extend the useful life of stolen access, especially when they are over-privileged and rarely reviewed. An attacker does not need to defeat authentication again if the token already carries trusted authority. The longer the token survives without rotation or revocation, the larger the blast radius becomes when it is compromised.

Q: What do security teams get wrong about third-party risk management?

A: They often treat third-party risk as a questionnaire exercise rather than an identity lifecycle problem. Paper controls do not reveal which tokens exist, who owns them, or whether they still have the right scope. Effective governance depends on continuous visibility into non-human access, not one-time assurance at onboarding.

Q: Who is accountable when a SaaS integration token is stolen?

A: Accountability should be shared, but operational ownership must be explicit. The business owner, identity team, and vendor all have different responsibilities, yet someone inside the enterprise must own review, rotation, and revocation. Without a named owner, the credential becomes a governance orphan and attackers benefit from the gap.

Technical breakdown

Why OAuth tokens create durable trust in SaaS integrations

OAuth was designed to let applications act on behalf of a user or service without sharing passwords, but the security model depends on scope, expiration, and revocation being actively governed. In SaaS ecosystems, those controls are often weakly enforced or left untouched after setup, so the token becomes a standing trust relationship. If the token is over-scoped, an attacker does not need to break authentication again. They simply inherit the permissions already embedded in the integration.

Practical implication: treat every integration token as an actively governed identity, not a passive configuration item.

Shadow identities and the SaaS governance gap

Shadow identities are application connections, service accounts, or automation tokens that operate outside normal IAM ownership. They are often created by business teams for speed, then forgotten because no one maps them into lifecycle, attestation, or monitoring workflows. That creates a grey zone where access persists without clear ownership, review cadence, or revocation trigger. In practice, the risk is not just excess access. It is the absence of a control owner who can answer whether the credential still needs to exist.

Practical implication: build a complete inventory of non-human identities and assign explicit owners for review and revocation.

Federated identity governance for multicloud and SaaS

Federated governance means connecting identity controls across cloud platforms, SaaS apps, and internal IAM systems so that credentials and permissions are managed as one operating model. For this class of risk, the important mechanics are mutual authentication, short token lifetimes, rotation, revocation, and continuous attestation. Without those controls working together, a trusted integration can become a persistent entry path even when the underlying application is secure. The governance challenge is orchestration, not just policy writing.

Practical implication: align token lifecycle controls with attestation and monitoring so revocation is operationally possible.

Threat narrative

Attacker objective: The attacker aimed to impersonate a trusted application and use that authority to move quietly across customer systems at scale.

1. Entry occurred through a stolen OAuth token from a third-party SaaS integration, giving attackers access through a trusted application path rather than a noisy login attack.
2. Escalation came from over-privileged, long-lived tokens that were never reviewed, rotated, or revoked, allowing the trusted application to be impersonated at scale.
3. Impact was broad customer-system exposure, because one compromised integration could reach multiple downstream environments that trusted the token’s authority.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Third-party SaaS has become an identity problem, not just a supplier risk problem. The article shows that the real exposure sits in the identities connecting systems, not in the contract paperwork that preceded them. When OAuth tokens, app connectors, and automation identities are left outside lifecycle governance, the attack surface outlives the onboarding process. Practitioners should treat every external integration as a governed identity with ownership, scope, and revocation authority.

No-one-owns-this token governance is the control gap this breach exploited. The tokens were long-lived, over-privileged, and not continuously reviewed, so the breach did not depend on breaking strong authentication. It depended on a lifecycle failure where neither customer nor vendor accepted operational responsibility for revocation and attestation. The implication is that identity governance must extend across organisational boundaries, or the weakest shared credential becomes the highest-value access path.

Shadow identities now sit in the same risk class as unmanaged service accounts. The article’s one-click integration model shows how fast business units can create persistent non-human access without central oversight. That puts SaaS connectors, bots, and tokens into the same governance conversation as workload identity and privileged machine accounts. NHI governance teams should assume the next breach may begin in a business-approved integration that no security team can currently enumerate.

Federated identity governance is becoming the minimum viable control fabric for SaaS sprawl. A checklist-based third-party process cannot keep pace with the rate at which applications, APIs, and tokens are created. What matters now is whether governance can continuously map ownership, enforce scope, and prove revocation across multiple platforms. The practitioner conclusion is simple: if the control fabric cannot see the identity, it cannot govern the risk.

Short-lived trust is the only durable response to permanent integration sprawl. The article makes clear that long-lived trust relationships are the real problem, because they create an attacker-friendly window that survives normal business change. That is why the industry must shift from static approval to continuous evidence that the integration still deserves access. For IAM leaders, the question is no longer whether to inspect these identities, but whether their programme can keep pace with them.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For related guidance, read Guide to the Secret Sprawl Challenge for the lifecycle controls that help reduce hidden credential risk.

What this signals

Shadow SaaS identities will keep expanding faster than manual governance can track them. The programme signal is clear: inventory quality matters more than another approval layer, because each one-click integration creates a durable identity surface that can outlive the team that created it. Teams should expect more unmanaged connectors until ownership is tied to identity lifecycle, not procurement paperwork.

With 27 days to remediate a leaked secret, the operational gap is not discovery alone but follow-through. That timeline is too slow for credentials that can be abused in minutes, which means response plans must pre-authorise rotation and revocation workflows before an incident occurs.

Identity blast radius: the real metric to watch is how many downstream systems a single token can reach. When a trusted application can traverse multiple environments, the control question is no longer whether access exists, but how quickly it can be reduced without breaking business operations. Use this as a board-level indicator of SaaS governance maturity.

For practitioners

• Inventory every third-party integration and token Create a unified register of SaaS connectors, app tokens, bots, and service accounts. Assign a named owner for each identity and tie it to a review date, a business purpose, and a revocation path.
• Enforce token lifetimes and rotation by default Set short expirations for OAuth and API tokens, and require rotation for anything that reaches sensitive business systems. Where a system cannot support rotation, treat that limitation as a risk exception with compensating controls.
• Add continuous attestation to third-party access Move beyond annual vendor questionnaires and require recurring attestation of actual token use, scope, and ownership. Use logs and access baselines to confirm that the integration is still active for the stated purpose.
• Baseline abnormal integration behaviour Monitor normal call volume, data destinations, and access timing for each trusted application. Alert when a connector reaches new systems, expands scope, or starts acting outside its established pattern.

Key takeaways

• The breach reveals a governance failure in third-party SaaS identity, where tokens outlived ownership and became trusted entry points.
• The scale of the issue is measured in blast radius, because one compromised integration can expose many customer systems through inherited trust.
• The control that matters most is continuous lifecycle governance for non-human credentials, including ownership, rotation, attestation, and revocation.

Key terms

• Shadow Identity: A shadow identity is a non-human account, token, connector, or automation path that exists outside normal IAM visibility or ownership. These identities often work correctly from a business perspective while remaining unmanaged from a security perspective, which makes them easy for attackers to abuse and difficult for defenders to revoke quickly.
• OAuth Token: An OAuth token is a credential that lets an application act with delegated authority instead of using a password. In SaaS environments, the token can become a persistent trust mechanism, so its scope, lifetime, rotation, and revocation determine whether the integration remains safe or turns into a standing access path.
• Federated Identity Governance: Federated identity governance is the practice of coordinating identity controls across multiple systems, platforms, and business domains under a single operating model. It matters when access is spread across SaaS, cloud, and internal applications, because ownership, certification, and revocation must work together rather than in isolated silos.
• Identity Blast Radius: Identity blast radius is the amount of downstream access an identity can reach if it is compromised. The wider the blast radius, the more systems, data, and workflows can be affected by a single stolen token or over-privileged account, making scope reduction one of the most important control objectives.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by SafePaaS: the 2025 supply chain breach and the identity risks of third-party SaaS. Read the original.