Topic starter
07/03/2026 1:41 am
TL;DR: Trusted SaaS integrations can replay valid OAuth tokens, move laterally across connected applications, and expose sensitive data without the signals that perimeter tools expect, according to Obsidian Security. The security problem is no longer just access review, but continuous governance of non-human identity behavior inside the SaaS layer.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “Obsidian Security for the modern SaaS Supply Chain”.
By the numbers:
- Organizations saw an average 120% year-over-year increase in new integrations in Microsoft alone, according to Obsidian Security.
- Obsidian Security says the blast radius of the Salesloft-Drift supply chain attack was 10x greater than previous incidents.
Key questions
Q: What breaks when OAuth tokens are compromised in connected SaaS environments?
A: When OAuth tokens are compromised, attackers can inherit delegated access without defeating passwords or MFA.
Q: Why do SaaS vendor breaches create such a wide blast radius?
A: Because SaaS services often reuse trust across many customers and workflows.
Q: What are the signs that SaaS access controls are not strong enough?
A: Common warning signs include dormant accounts that remain active, inconsistent MFA enforcement, broad privileges that exceed job needs, and limited visibility into activity across SaaS and integrated apps.
Practitioner guidance
- Inventory every SaaS integration continuously Track OAuth apps, APIs, service accounts, and shadow integrations as one live estate so access paths and ownership stay current.
- Right-size delegated scopes and revoke stale access Review broad OAuth grants for each connected application, remove unused integrations, and shorten the exposure window for tokens that no longer match business use.
- Baseline trusted SaaS behaviour Build detection around normal API sequences, integration context, and cross-app data flow so unusual delegated activity can be distinguished from legitimate business traffic.
Bottom line: SaaS supply chain breaches exploit trusted integrations, not just compromised logins, which makes identity context central to detection and governance.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/10/2026 4:41 pm
SaaS supply chain risk is now an identity governance problem, not just a vendor risk problem. The article shows that the trust boundary has moved inside the SaaS layer, where OAuth grants, APIs, service accounts, and shadow integrations operate as live identity paths. That means annual reviews and point-in-time approvals are structurally behind the threat. Practitioners need to govern the access graph, not just the supplier list.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a SaaS integration exposes customer data?
A: Accountability sits with the organisation that owns the delegated access path, even if the token originated from a third-party service. Security, application, and SaaS owners all need a defined revocation process and an incident playbook. If the integration can reach customer data, it must be governed like any other privileged identity.
👉 Read our full editorial: SaaS supply chain risk is outpacing legacy IAM controls