UNC6395 shows SaaS integrations can widen NHI blast radius

At a glance

What this is: UNC6395 is a SaaS supply-chain breach pattern where compromised integrations expanded access from one third-party app into Salesforce and Google Workspace environments across many downstream tenants.

Why it matters: For IAM and NHI practitioners, it shows that unmonitored SaaS-to-SaaS identities can bypass normal controls and create enterprise-wide exposure faster than direct credential theft.

By the numbers:

• Obsidian Security reports that the UNC6395 campaign has impacted over 700 companies and counting.

👉 Read Obsidian Security's analysis of the UNC6395 SaaS supply-chain breach

Context

Non-human identity risk is not limited to service accounts and API keys. In SaaS environments, integrations, OAuth grants, and delegated application identities can become the real control surface, especially when they sit outside proxy visibility and are trusted by default. This is why SaaS governance has become a core part of NHI management, not a side issue.

The UNC6395 case matters because it turns a familiar identity problem into a supply-chain problem. When one compromised integration can reach Salesforce and Gmail across many customers, the issue is no longer isolated account security but downstream trust collapse. That pattern is increasingly typical in modern SaaS estates, where integration sprawl often outpaces oversight.

Key questions

Q: How should security teams govern SaaS integrations as non-human identities?

A: Treat each integration as a privileged non-human identity with an owner, approved scope, review cadence, and revocation path. The key is to manage the integration lifecycle, not just the initial consent. If the app can read mail, CRM records, or admin APIs, it needs the same scrutiny as other high-risk access paths.

Q: Why do SaaS supply-chain attacks create a larger blast radius than direct account compromise?

A: A compromised integration can inherit trusted access and reach many downstream tenants without re-authenticating each one. That makes the breach scale through approved relationships instead of through repeated credential theft. The result is faster spread, broader exposure, and a containment problem that is much harder than a single-account incident.

Q: What is the difference between an integration review and a normal access review?

A: A normal access review focuses on users and their entitlements. An integration review focuses on delegated authority, consent scopes, connected systems, and the downstream impact of a compromise. For SaaS estates, that distinction matters because a single app can represent more risk than many individual users.

Q: When should organisations revoke a SaaS integration immediately?

A: Revoke it as soon as the integration is ownerless, unused, overscoped, or associated with suspicious cross-platform activity. Immediate revocation is also justified when the app touches sensitive systems and no one can explain why it still needs its current permissions.

Technical breakdown

How SaaS-to-SaaS integrations expand the identity attack surface

SaaS-to-SaaS integrations often authenticate through OAuth grants, service tokens, or delegated application identities. Those connections can inherit broad access scopes that look legitimate to the platform but are rarely reviewed with the same rigor as human accounts. Once a trusted integration is compromised, attackers do not need to break each customer directly. They can reuse the integration's authority to reach multiple tenants, export data, or trigger actions across connected systems. The core failure is not the protocol itself but the lack of lifecycle control over integration permissions, monitoring, and revocation.

Practical implication: Treat every integration as a privileged NHI and inventory its scopes, owners, and revocation path.

Why proxy controls miss SaaS lateral movement

Traditional perimeter controls are weak against cloud-to-cloud abuse because the traffic often occurs inside authenticated SaaS sessions. The request may come from a valid token, a known app ID, or a normal API pattern, so network inspection alone sees little risk. Attackers exploit this by moving laterally through approved integrations rather than by forcing obvious login failures. That is why detection needs identity telemetry, application governance, and cross-platform baselines. If the monitoring model only watches users and endpoints, it will miss the trust relationships that make the breach scalable.

Practical implication: Correlate app identity, consent changes, and cross-tenant activity instead of relying only on network and endpoint alerts.

What blast-radius control means for connected SaaS estates

Blast-radius control is the discipline of limiting how far a compromised integration can move once trust is broken. In practical terms, that means reducing scopes, segmenting apps by business purpose, tightening tenant-to-tenant permissions, and requiring rapid revocation procedures. It also means distinguishing between necessary high-trust integrations and legacy connections that persist because nobody owns them. Without those controls, a single compromised SaaS vendor can become a multiplier for every customer attached to it.

Practical implication: Build review and containment processes around the size of the possible downstream blast radius, not just the number of integrations.

Threat narrative

Attacker objective: The attacker objective is to leverage one compromised SaaS integration to gain scalable access to many customer environments and their data.

1. Entry occurred when attackers compromised third-party sales tools and their associated SaaS identities rather than attacking downstream companies one by one.
2. Escalation followed as the attackers reused trusted integration authority to pivot into Salesforce and Google Workspace instances across multiple organizations.
3. Impact was a supply-chain style cascade that expanded breach reach across hundreds of downstream environments and widened the number of affected tenants.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Compromised SaaS integrations are now privileged NHIs, not convenience features. The UNC6395 pattern shows that delegated app identities can carry more operational risk than many human accounts because they can touch multiple platforms without obvious friction. Governance teams that still treat integrations as peripheral tooling are underestimating the access model. Practitioners should move integrations into the same review and control lifecycle as other high-risk NHIs.

Blast-radius control is becoming the decisive control objective in SaaS security. The central question is no longer whether an integration is authenticated, but how far it can move if its trust is abused. Scope reduction, tenant segmentation, and emergency revocation should be treated as first-class controls. Security teams should measure success by how quickly they can contain a compromised integration.

Unmonitored SaaS-to-SaaS trust creates identity debt. Each dormant, over-scoped, or ownerless connection accumulates hidden exposure until a breach exposes it. That debt is structural because SaaS ecosystems grow faster than governance processes. The practical conclusion is to build integration inventories that are owned, reviewed, and continuously tested for excessive privilege.

The market is signaling a shift from account security to integration governance. Direct credential theft remains relevant, but supply-chain abuse through SaaS apps now scales faster and is harder to contain. That pushes buyers toward controls that can observe consent, scopes, and cross-application behavior. Practitioners should expect integration governance to become a standard part of NHI programs.

Security teams need a separate control model for cloud-connected non-human identities. Human-centric IAM assumes a bounded user session, while SaaS integrations can persist, replicate, and silently expand authority. That mismatch is where the breach class grows. The field should align on an integration governance model that covers discovery, scope review, revocation, and downstream monitoring.

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.
• Our research also found that organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
• That fragmentation is a useful reminder to revisit 52 NHI Breaches Analysis for patterns in how unmanaged credentials become downstream access paths.

What this signals

Integration governance will become a board-level NHI control problem. The practical issue is not whether teams can detect one compromised app, but whether they can enumerate every trust path before attackers exploit it. Programs that still separate SaaS administration from identity governance will keep missing the real blast radius.

With 75% of organisations expressing strong confidence in secrets management capabilities while the average estimated time to remediate a leaked secret remains 27 days, the gap between perceived control and operational containment is already visible. SaaS integration abuse widens that gap because the weak point is often delegated access, not just a leaked token. Teams should expect shorter revocation windows and more pressure to prove continuous ownership of app-to-app trust.

Identity blast radius: the downstream reach a single compromised integration can have across SaaS systems. Once that reach is measured, teams can segment apps by data sensitivity, restrict high-impact scopes, and align governance to OWASP Non-Human Identity Top 10 concerns instead of treating integrations as background plumbing.

For practitioners

• Inventory every SaaS integration as a privileged identity Map each third-party app, OAuth grant, and delegated token to an owner, business purpose, scope, and revocation path. Unknown or ownerless connections should be treated as unmanaged NHI exposure, not harmless background configuration.
• Review scopes and consent drift on a fixed cadence Check whether each integration still needs its current permissions, especially those touching CRM, mail, or collaboration systems. Remove overscoped or unused access before attackers can reuse it as a pivot path.
• Correlate cross-platform activity for abnormal pivots Build detections that join SaaS audit logs, application IDs, and token use across connected systems. Watch for unusual user agents, bulk export behavior, and access patterns that jump between platforms without a normal business trigger.
• Prepare an integration revocation playbook Define who can disable a compromised SaaS integration, how fast that revocation must happen, and what downstream systems must be checked afterward. The goal is to shrink the blast radius before the compromise spreads further.
• Separate trusted business apps from high-risk connectors Classify integrations by data sensitivity and operational reach, then apply stricter review to apps that can touch customer data, email, or admin APIs. High-reach integrations deserve stronger monitoring and shorter approval cycles.

Key takeaways

• SaaS integrations can function as high-risk non-human identities when they carry delegated access across multiple platforms.
• UNC6395 shows that one compromised app can create a much larger downstream blast radius than direct account compromise.
• Practitioners should govern integrations with inventory, scope review, monitoring, and rapid revocation controls.

Key terms

• SaaS-to-SaaS Integration: A SaaS-to-SaaS integration is a trust relationship that lets one cloud application act inside another cloud application. In identity terms, it often behaves like a non-human identity with delegated authority, scopes, and persistence that must be governed across its full lifecycle.
• Integration Blast Radius: Integration blast radius is the amount of downstream access and data exposure a compromised connection can create. It is determined by scopes, tenant reach, and connected systems, so it is a governance measure as much as a technical one.
• Delegated Application Identity: A delegated application identity is an access path that lets an app act on behalf of a user, tenant, or business process. It is common in OAuth-based ecosystems and becomes risky when nobody owns the permissions, reviews the scope, or can revoke it quickly.

Deepen your knowledge

SaaS integration governance and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment relies on delegated app access across Salesforce, Gmail, or other cloud services, it is worth exploring.

This post draws on content published by Obsidian Security: BREAKING: UNC6395 and the biggest SaaS breach of 2025. Read the original.