Notifications
Clear all
Topic starter
14/08/2026 6:37 pm
TL;DR: As SaaS adoption accelerates outside IT review, security teams lose visibility into OAuth tokens, local accounts, API keys, and other access paths that survive SSO deprovisioning, according to Obsidian Security. The governance problem is no longer just discovery, but proving which app identities still exist and can still reach sensitive systems.
NHIMG editorial — based on content published by Obsidian Security: Obsidian Now Covers 200+ Enterprise Applications. Here's Why That Number Matters
By the numbers:
Questions worth separating out
Q: How should security teams govern SaaS integrations that inherit broad access?
A: Treat each integration as a non-human identity with its own lifecycle, owner, and scope.
Q: Why do unmanaged SaaS apps create access risk even when SSO is in place?
A: Because SSO only governs the apps it covers.
Q: What breaks when organisations cannot see all third-party app connections?
A: Investigation, containment, and accountability all break at the same time.
Practitioner guidance
- Inventory all OAuth grants and SaaS-native accounts Build a live register of every delegated integration, local admin, API key, and service identity across critical SaaS applications.
- Tie connector coverage to revocation workflows Require each new SaaS connector to have an owner, a logging destination, and a defined revocation path for tokens and local accounts.
- Test offboarding beyond SSO deprovisioning Run offboarding checks that verify local SaaS accounts, OAuth tokens, and non-human identities are removed or disabled after employee departure.
What's in the full article
Obsidian Security's full post covers the operational detail this analysis intentionally leaves for the source:
- How the 200+ application connector model maps to monitoring and posture coverage across SaaS environments
- Examples of the app coverage gaps that surfaced dormant accounts and stale permissions after broader visibility was enabled
- The specific breach patterns referenced, including Vercel, Salesloft, and Anodot, with their operational parallels
- What connector expansion changes for security teams that need implementation detail rather than governance framing
👉 Read Obsidian Security's analysis of SaaS connector coverage and hidden identity paths →
SaaS connector coverage and OAuth drift: are your controls keeping up?
Explore further
14/08/2026 6:44 pm
Connector coverage has become a control plane for identity governance, not just a visibility feature. The article shows that each additional SaaS connector expands the organisation's ability to discover dormant accounts, OAuth grants, and application-native identities that sit outside the IdP. That changes the governance model from periodic review to continuous reconciliation across human identity, NHI, and delegated access paths. Practitioners should treat connector breadth as a control requirement, not a convenience feature.
A few things that frame the scale:
- 78% of SaaS were shadow apps, according to Meta AI Instagram Account Takeover.
- A separate finding shows that 98% of companies plan to deploy even more AI agents within the next 12 months, even though 80% of current deployments have already shown rogue behaviour.
A question worth separating out:
Q: Who is accountable when a third-party integration is abused?
A: Accountability belongs to the business owner, the platform owner, and the identity team together, because connected apps sit across operational boundaries. If no one can state who approved the grant, who renews it, and who revokes it, the organisation has a governance gap. Ownership must be explicit before incidents happen.
👉 Read our full editorial: SaaS connector coverage is now an identity governance control
