UNC6395 shows SaaS integrations can widen NHI blast radius

At a glance

What this is: This is an incident analysis showing how compromised SaaS integrations allowed UNC6395 to spread from Salesloft-Drift into Salesforce and Google Workspace across hundreds of downstream companies.

Why it matters: It matters because IAM and NHI teams have to govern SaaS integrations as access-bearing identities, not as passive connectors that sit outside normal entitlement, monitoring, and offboarding controls.

By the numbers:

• Obsidian Security says the campaign has impacted over 700 companies and counting.

Context

UNC6395 is a supply chain attack against SaaS integrations, where a trusted third-party connection becomes the path into downstream environments. In this case, the article describes compromise of Salesloft Drift and Drift Email, followed by access to Salesforce and Google Workspace instances across multiple customer organisations.

The governance problem is not just breach containment inside one application. It is that SaaS-to-SaaS integrations often inherit broad trust, opaque scope, and weak monitoring, which leaves IAM teams without a reliable boundary for entitlement review or blast-radius control.

For identity programmes, the question is whether integration credentials, OAuth grants, and connected app permissions are treated as governed access paths. If they are not, the organisation may be securing the wrong layer while the real path to data and workflow access remains open.

Key questions

Q: What breaks when SaaS integrations are treated as low-risk conveniences?

A: Access review, revocation, and incident containment all weaken when SaaS connections are approved as convenience features rather than governed identity relationships. Delegated access then persists beyond the business need, visibility drops across tokens and vendor-admin paths, and one compromise can ripple through many connected applications before teams can isolate it.

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: How do security teams know whether SaaS integration monitoring is actually working?

A: Monitoring is working when it surfaces abnormal authentication, unusual API queries, large exports, and suspicious session patterns quickly enough to support containment. Teams should test whether alerts fire on token abuse, bulk extraction, and admin impersonation, then verify that logs are normalized and reviewed in real time rather than left inside the SaaS platform.

Q: Should teams treat SaaS-to-SaaS integrations as privileged access?

A: Yes. A connected app can function like a privileged service identity if it can read, write, or export business data through APIs. Treating it as ordinary application plumbing leaves no clear place for certification, offboarding, or incident revocation, which is exactly where shared blast radius emerges.

Technical breakdown

How compromised SaaS integrations extend trust downstream

A SaaS integration can function like an identity bridge between platforms, especially when OAuth tokens or app grants let one service act inside another on behalf of a tenant. When that bridge is over-scoped or unmonitored, compromise of the upstream app can translate into authorised downstream access without needing to break the target account directly. That is why these incidents behave like access-path abuse rather than isolated application compromise. The technical issue is not just token theft. It is the delegation model that turns one trusted integration into a reusable control plane for many customers.

Practical implication: inventory every connected SaaS app, its grant scope, and the data and workflow it can reach.

Why proxy and perimeter controls miss SaaS-to-SaaS abuse

Proxy controls are often tuned for user traffic and known application sessions, not for integration identities that operate through vendor-to-vendor trust. Once the attacker holds a valid integration credential or token, the activity may look like normal service traffic unless the organisation has baseline behaviour for connected apps, user-agent patterns, and cross-platform access paths. This is why SaaS breach detection has to watch the integration layer itself, not just endpoints or human sign-ins. The control failure is visibility at the trust boundary.

Practical implication: baseline integration behaviour across SaaS environments and alert on non-routine cross-platform access patterns.

How a single vendor compromise creates multi-tenant blast radius

SaaS supply chain incidents scale because one upstream compromise can fan out into many downstream tenants through pre-existing trust relationships. In this article, Obsidian Security describes an impact pattern that is materially worse than direct account takeover because the attacker is no longer repeating the same intrusion against each victim. Instead, one compromised vendor or connected app becomes a distribution channel. That changes the risk model from single-org compromise to ecosystem-wide exposure, which is exactly why integration governance has to be part of identity security, not an adjacent concern.

Practical implication: treat high-trust SaaS integrations as shared blast-radius assets and review them with the same rigor as privileged access.

Threat narrative

Attacker objective: The objective was to use a trusted SaaS integration as a distribution path into downstream business systems and data stores at scale.

1. Attackers initially compromised third-party SaaS tools, including Salesloft Drift and Drift Email, to gain a foothold in the integration layer.
2. They then used the integrations' identities and OAuth-linked access to pivot into Salesforce and Google Workspace environments belonging to downstream companies.
3. The campaign expanded across many tenants because the same trusted integration path could be reused against multiple organisations, increasing impact without repeating the initial compromise.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SaaS integrations are privileged identities, not peripheral connections. When an integration can move data, trigger workflows, or access customer environments, it already behaves like a governed identity path. The article shows that treating those connections as low-risk plumbing leaves the real access boundary unowned. Practitioners should fold connected apps into entitlement governance, not into shadow inventory.

Integration trust now defines blast radius. The decisive security question is not whether an app is trusted, but how far that trust extends and whether it is bounded by scope, monitoring, and revocation. Obsidian Security's reporting shows that the downstream damage from one compromised integration can exceed the damage from direct account compromise by an order of magnitude. Identity teams should assess integration fan-out as a first-class risk metric.

Integration blast radius: This article sharpens a useful governance concept for SaaS environments. Blast radius is no longer only a function of the victim account's privilege level; it is also a function of how many connected tenants, apps, and workflows inherit trust from one integration. The implication is that lifecycle control must extend to third-party app relationships and their delegated access scope.

Monitoring has to move from users to delegated access paths. Traditional SaaS oversight often centres on sign-in anomalies and individual entitlements, but this campaign moved through trusted app-to-app pathways. That means the governance failure is not just missing detection, it is misplaced detection. Security teams should manage integrations as part of the identity control plane and not as a separate SaaS admin problem.

Supply chain identity risk is now an IAM design issue. The article reinforces a broader market shift: SaaS and NHI governance are converging around delegated authority, third-party access, and dynamic trust relationships. That convergence makes isolated tool ownership less defensible and cross-domain visibility more necessary. Practitioners should expect integration governance to become a central requirement in identity programmes.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Integration governance is now part of identity governance. The useful boundary is no longer human users versus machine accounts alone. SaaS-to-SaaS connections can hold enough delegated authority to become the real control plane, which means programme owners need to include connected apps in entitlement review, offboarding, and exception handling.

Monitoring must be multi-platform, not app-by-app. A campaign like UNC6395 can look fragmented if teams only inspect one SaaS tenant at a time. Identity operations should correlate integration behaviour across the estate so that unusual access paths surface as one event chain instead of many isolated alerts.

Delegated trust has to be measured as fan-out. The article shows that one compromised integration can reach many downstream environments, so practitioners should track how many systems inherit access from each connector. That metric is a better indicator of exposure than the number of integrations alone.

For practitioners

• Inventory all SaaS-to-SaaS integrations Build a complete register of connected apps, OAuth grants, service accounts, and vendor-managed connectors across Salesforce, Google Workspace, and other core SaaS platforms.
• Classify integrations by blast radius Rank each integration by tenant reach, data access, workflow authority, and whether it can act across multiple business units or customer environments.
• Review overscoped and unused connections Remove high-risk, dormant, or unnecessary integrations, especially where the connector has broader access than the business process requires.
• Monitor cross-platform activity baselines Correlate user-agent strings, app IDs, and source IP patterns across SaaS platforms so abnormal integration activity is visible as one campaign rather than separate events.
• Test revocation and offboarding paths Verify that you can revoke third-party integration access quickly and that disconnected apps cannot continue to reach downstream tenants after trust is removed.

Key takeaways

• SaaS integrations can function as privileged identity paths, so a compromise upstream can expose many downstream environments at once.
• The UNC6395 campaign shows that integration trust can produce a much larger blast radius than direct account compromise.
• Identity teams should govern connected apps with the same discipline they apply to privileged access, especially for scope review and revocation.

Key terms

• SaaS-to-SaaS Integration: A SaaS-to-SaaS integration is a machine-to-machine connection that lets one cloud application access another through delegated credentials. In NHI governance terms, it creates a persistent identity, a permission scope, and a lifecycle obligation that must be reviewed like any other access relationship.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.

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.