Topic starter
16/01/2026 3:21 pm
TL;DR: UNC6395 shows that compromising a third-party SaaS integration can cascade into Salesforce and Google Workspace access across hundreds of downstream companies, with Obsidian Security reporting impact across 700-plus organizations and a blast radius 10 times larger than direct-account breach patterns. SaaS identity governance now has to treat integrations as privileged pathways, not peripheral connections.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “BREAKING: UNC6395 – The Biggest SaaS Breach of 2025”.
By the numbers:
- Obsidian Security says the campaign has impacted over 700 companies and counting.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: SaaS integrations can function as privileged identity paths, so a compromise upstream can expose many downstream environments at once.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/10/2026 4:55 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: UNC6395 shows SaaS integrations can widen NHI blast radius