SaaS supply chain risk is outpacing legacy IAM controls

At a glance

What this is: This analysis argues that SaaS supply chain attacks exploit trusted integrations, valid tokens, and weak visibility across connected applications.

Why it matters: It matters because IAM and NHI teams now have to govern SaaS-to-SaaS access paths that traditional controls and periodic reviews do not actually see.

By the numbers:

• Across its customer environments, the vendor observed an average 120% year-over-year increase in new integrations in Microsoft alone.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read Obsidian Security's analysis of SaaS supply chain attacks and NHI exposure

Context

SaaS supply chain risk is what happens when one application gains trusted access to another through OAuth, APIs, or service accounts, and that trust becomes the attack path. In this case, the problem is not a missing login prompt but a governance gap inside the SaaS layer itself, where non-human identities can act with broad permissions and limited oversight.

The article’s core point is that legacy IAM and perimeter tools were built for users and endpoints, not for autonomous or semi-autonomous integrations that operate continuously across business systems. That makes the current model brittle: access is granted quickly, ownership is often unclear, and investigations only begin after a disclosure forces teams to reconstruct the chain of trust.

For practitioners, this is not an edge case. It is the normal failure mode of SaaS sprawl when integration growth, token persistence, and weak lifecycle governance are allowed to compound.

Key questions

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

A: Security teams should treat OAuth grants as non-human identities with lifecycle ownership, scope review, and revocation controls. Each integration needs an accountable owner, a business purpose, and a clear expiry or review point. The key is to manage delegated access continuously, not to rely on annual third-party reviews after the tokens are already live.

Q: Why do SaaS supply chain attacks evade traditional IAM and CASB controls?

A: They evade legacy controls because the activity is authenticated, expected, and often hidden inside the SaaS layer rather than on endpoints or user sessions. Traditional controls are good at spotting interactive logins and malware, but they miss valid tokens, cross-application API calls, and trust propagation between connected services.

Q: What is the difference between user access and NHI access in SaaS environments?

A: User access is interactive and usually tied to a person with a predictable lifecycle. NHI access is machine-driven, often persistent, and may span integrations, APIs, and service accounts that continue operating long after the original approval. That difference matters because NHI access needs ownership, expiration, and behavioral monitoring.

Q: When should organisations revoke a SaaS integration?

A: Organisations should revoke a SaaS integration when its business purpose is unclear, its permissions exceed current need, its owner is missing, or its behaviour no longer matches expected use. In practice, revocation should also follow any compromise signal, because a trusted integration with broad scope can become a fast path to lateral access.

Technical breakdown

Why OAuth trust becomes an attack surface in SaaS supply chains

OAuth was designed to delegate access without sharing passwords, which makes it efficient but also dangerous when scopes are broad and revocation is rare. In a SaaS supply chain, the token becomes the control plane for data movement between services, so attackers do not need interactive logins if they can reuse valid tokens or compromise the upstream integration. That is why legitimate API calls can mask malicious activity for long periods. Security teams should treat OAuth grants as standing machine access, not as a one-time approval event.

Practical implication: Review OAuth scope, ownership, and expiry as continuously managed NHI controls, not as application onboarding paperwork.

How SaaS-to-SaaS lateral movement evades legacy controls

Traditional CASB, SIEM, and endpoint tooling are strong at spotting user anomalies, but they are weak when the action happens entirely inside the SaaS layer. Lateral movement in this context means an attacker uses one compromised integration to access another connected system, often through normal API behavior. Because the traffic is authenticated and expected, rules based on logins or malware signatures often miss it. The visibility problem is compounded by fragmented logs and inconsistent identity context across platforms.

Practical implication: Correlate identity, token, and API activity across SaaS apps before a breach forces manual reconstruction.

Identity blast radius in connected SaaS ecosystems

Blast radius is the downstream set of systems, records, and entitlements exposed once a SaaS integration is compromised. In these environments, the real risk is rarely limited to the first application. A single trusted connection can extend into CRM data, customer records, and workflow automation, creating a wider incident than teams expect. This is where non-human identity governance must include dependency mapping, permission review, and revocation paths that reflect actual integration relationships.

Practical implication: Map which integrations can reach which data sets so containment starts with the true downstream exposure, not the first alert.

Threat narrative

Attacker objective: The attacker wants persistent, trusted access to downstream SaaS data and workflows without creating obvious authentication failures.

1. Entry occurs through a compromised third-party SaaS integration that already has valid OAuth access into downstream systems.
2. Escalation happens when attackers replay tokens or reuse trusted API calls to move across connected SaaS applications without triggering interactive login controls.
3. Impact follows as sensitive customer data is accessed over time, while the activity blends into normal business operations and delays detection.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

SaaS supply chain governance is now an NHI problem, not just a third-party risk problem. The article shows that trusted integrations can behave like persistent machine identities with broad access and unclear ownership. That shifts the control question from vendor review to lifecycle governance for OAuth grants, service accounts, and shadow integrations. Practitioners should manage SaaS access as part of NHI governance, not as a separate exception process.

Continuous visibility is the control gap the industry keeps underestimating. Annual reviews and static inventories do not keep pace with integration sprawl, especially when permissions evolve after approval. The security failure is not only that access exists, but that no one can reliably answer what a given integration can reach today. Teams need runtime visibility, not periodic attestation, if they want to contain SaaS supply chain abuse.

Identity blast radius is the right named concept for this category of exposure. Once an integration is compromised, the useful question is not whether the first app was trusted, but how far that trust propagated. This article makes clear that blast radius depends on token scope, downstream dependencies, and data sensitivity. Practitioners should prioritize controls that shorten the reachable path, because that is what reduces real incident impact.

AI agents will make this governance gap harder to ignore. The article’s warning about agents is credible because agents extend the same trust pattern: long-lived tokens, delegated actions, and broad SaaS reach. That does not create a new security category so much as it magnifies an old one. The field should expect more unmanaged access paths unless agent governance is built on the same NHI lifecycle discipline as other integrations.

Security teams need to re-center response around containment, not just detection. When logs are fragmented and vendor notifications arrive late, the limiting factor becomes how fast teams can reconstruct access paths and revoke what matters. That means blast-radius analysis, ownership mapping, and rapid revocation workflows are operational necessities. Practitioners should build for containment first, because that is what determines whether a compromise stays local or becomes enterprise-wide.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For the broader control picture, see Top 10 NHI Issues for the governance gaps that repeatedly turn identity sprawl into breach impact.

What this signals

Identity blast radius is now a programme-level metric, not an incident afterthought. If a single SaaS integration can propagate trust into multiple downstream systems, then containment planning must start with reachable assets rather than the first compromised app. Teams that already track NHI exposure can use that discipline to shorten response time and prioritise revocation paths where the business impact is highest.

With 72% of organisations reporting or suspecting an NHI breach, according to The 2024 ESG Report: Managing Non-Human Identities, the governance problem is structural. The article reinforces that the weak point is not just external compromise but unmanaged trust inside business workflows. Practitioners should plan for more SaaS integrations, more autonomous access, and more pressure to verify ownership and expiry continuously.

The most useful next step is to align SaaS governance with NHI lifecycle management and zero trust assumptions. That means mapping delegated access, enforcing ownership, and using behavioural signals to detect when an integration is operating outside its expected role. Programs that treat SaaS connections as static approvals will keep discovering the same problem too late.

For practitioners

• Implement continuous SaaS integration inventory Maintain an always-current inventory of OAuth apps, APIs, service accounts, and shadow integrations across all major SaaS platforms. Tie each integration to an owner, a business purpose, and a revocation path so access can be removed quickly when trust breaks down.
• Right-size OAuth scopes and token lifetimes Review every connected app for the minimum scopes it actually needs, then shorten token lifetime where the business can tolerate it. Treat long-lived tokens as standing machine access and require explicit exceptions for broad or persistent access.
• Correlate identity and SaaS telemetry Join identity events, API activity, and SaaS audit logs so suspicious token replay or unusual cross-app access can be detected without waiting for a vendor disclosure. Build detection around behavior across systems, not just logins at the perimeter.
• Map downstream blast radius before incidents Document which integrations can reach which data sets, workflows, and privileged actions, then use that map during containment. This reduces time lost to manual reconstruction and lets responders revoke the smallest set of credentials that actually matter.

Key takeaways

• SaaS supply chain attacks succeed when trusted integrations become opaque non-human identities with durable access.
• The scale of the problem is already visible in NHI breach data, so this is a governance issue, not a one-off threat pattern.
• Practitioners should prioritize continuous visibility, scope minimization, and blast-radius mapping before a disclosure forces reconstruction.

Key terms

• SaaS Supply Chain: The chain of trusted software relationships created when one SaaS application connects to another through OAuth, APIs, or service accounts. In security terms, it is a hidden dependency graph where one compromised integration can expose downstream systems, data, and privileges across multiple vendors and business workflows.
• Identity Blast Radius: The downstream exposure created when an identity or integration is compromised. It measures how far trust, access, and data reach beyond the initial account, including connected applications, workflows, and sensitive records. Practitioners use it to prioritize containment and revocation decisions.
• Shadow Integration: An unmanaged or undocumented SaaS connection that exists outside normal approval and inventory processes. It may use valid credentials and appear legitimate, but it creates governance blind spots because no one can confidently answer who owns it, what it can access, or when it should be removed.
• Delegated Access: Access granted by one system to another so a machine, app, or agent can act without a human present. It is necessary for modern SaaS operations, but it becomes risky when scopes are broad, tokens persist too long, or ownership and revocation are unclear.

Deepen your knowledge

SaaS supply chain governance and delegated access controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for integrations, tokens, and autonomous access paths, it is worth exploring.

This post draws on content published by Obsidian Security: How trusted integrations become breaches. Read the original.