SaaS connector coverage is now an identity governance control

At a glance

What this is: This is an analysis of expanded SaaS connector coverage and the control gaps created by shadow apps, OAuth-based access, and incomplete offboarding.

Why it matters: It matters because IAM, PAM, and NHI programmes cannot govern what they cannot see, especially when third-party app access persists outside the IdP and survives employee offboarding.

By the numbers:

• 78% of SaaS were shadow apps

👉 Read Obsidian Security's analysis of SaaS connector coverage and hidden identity paths

Context

SaaS connector coverage is now an identity governance issue because the access paths that matter most are often outside the identity provider's normal view. Modern enterprises accumulate shadow apps, OAuth tokens, local SaaS accounts, API keys, and non-human identities faster than security teams can review or revoke them, which creates a persistent control gap across identity security and data access.

The article's core point is that visibility is a prerequisite for both breach investigation and offboarding. If security teams cannot see which third-party apps, tokens, and local identities exist, they cannot reliably answer who accessed what, nor can they prove that departed users and connected tools have actually been removed from the environment.

Key questions

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. Review the effective permissions after inheritance, not just the initial approval. Then enforce rotation, reauthorization, and revocation rules so the integration cannot keep access after the business need changes.

Q: Why do unmanaged SaaS apps create access risk even when SSO is in place?

A: Because SSO only governs the apps it covers. Employees can still use browser tools, local accounts, and OAuth-linked services outside federation, which leaves access invisible to standard identity reporting. The risk is not the absence of authentication, but the absence of complete lifecycle control over what users can actually reach.

Q: What breaks when organisations cannot see all third-party app connections?

A: Investigation, containment, and accountability all break at the same time. Without full connector visibility, teams cannot tell which token was used, which data path was involved, or whether a stale account still existed. That creates blind spots for incident response, compliance, and post-breach reporting, especially when the attacker moved through a trusted integration.

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.

Technical breakdown

Why OAuth connections create hidden identity paths

OAuth is designed to let one application act on behalf of a user or another system without sharing the user's password. That delegation is useful, but it also creates a separate identity path that is not the same as the federated login managed by SSO. Once a token is issued, downstream services often trust it until expiry or revocation, even if the originating app is unmanaged. In practice, that means a legitimate token can become an attacker-controlled access channel when a third-party tool is compromised or overconnected.

Practical implication: inventory and govern OAuth grants as live access paths, not as one-time application integrations.

Why SSO deprovisioning does not close every account

SSO deprovisioning removes the federated path through the identity provider, but it does not automatically remove local SaaS accounts, application-native admins, API keys, or service identities that were created directly in the application. Those identities can remain active long after a user leaves, especially in environments with decentralised app adoption. This is an NHI governance problem as much as a human IAM problem, because machine and app credentials often sit outside the HR-driven lifecycle that IAM teams rely on.

Practical implication: reconcile IdP deprovisioning with application-native identity and secret revocation before considering offboarding complete.

How incomplete telemetry weakens breach investigation and control

When an uncovered application or token is used in an incident, the security team loses a section of the evidentiary chain. Logs may show the result in the destination system, but not the path that carried the attacker there. That undermines containment, forensic scoping, and board-level reporting because the organisation cannot prove which accounts, tokens, or connectors were involved. In supply chain incidents, this gap is often the difference between a contained event and an unbounded blast radius.

Practical implication: extend telemetry to third-party connectors and identity-bearing integrations so investigation starts with complete evidence, not assumptions.

Threat narrative

Attacker objective: The attacker wants to pivot through trusted SaaS and identity integrations to reach high-value data and credentials without exploiting the primary application directly.

1. Entry occurs through a trusted third-party SaaS integration or OAuth connection that was connected outside IT oversight.
2. Escalation happens when the attacker inherits a valid token or application credential and uses it to move into core systems without triggering password-based controls.
3. Impact follows as customer data, API keys, source code, or other sensitive assets are accessed through the connected application chain.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

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.

Delegated access is the hidden NHI problem inside SaaS security. OAuth tokens, API keys, and local app accounts behave like non-human identities because they can persist, bypass HR-driven lifecycle controls, and retain access after the original user is gone. This is the governance gap the article exposes: the identity provider can be clean while the application layer remains full of standing access. Teams should map every delegated path to an accountable owner and lifecycle process.

Visibility gaps create evidentiary gaps, and evidentiary gaps become liability gaps. The article correctly links incomplete telemetry to board and auditor exposure because an unseen connector means an unprovable access path. That makes this issue relevant to GRC, not only security operations. Shadow SaaS drift: the accumulation of unmanaged apps, tokens, and local accounts that outpace review cycles. Practitioners should measure whether every material app has logs, ownership, and revocation coverage before the next incident test.

Supply chain exposure now includes identity relationships between applications. The breach examples in the article show that attackers increasingly target the trust fabric between apps rather than the crown jewel itself. That means SaaS governance has to be evaluated alongside third-party risk, least privilege, and secrets management. Security teams should assume the weakest connected application can become the shortest path to core data.

AI agents intensify the same control problem because they create more identity-bearing integrations. As agents, assistants, and automations start calling SaaS tools, the number of tokens, delegated permissions, and service identities rises sharply. That is why the boundary between SaaS security and NHI governance is narrowing. Practitioners should build one inventory for both application integrations and AI-driven access paths.

From our research:

• 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.
• That combination is why practitioners should connect identity governance to the OWASP NHI Top 10 and the NIST AI Risk Management Framework before AI-driven access paths multiply further.

What this signals

Shadow SaaS drift is becoming a governance metric, not just an architecture problem. The operational question for security teams is no longer whether a few unmanaged apps exist, but whether connector coverage is complete enough to make revocation and investigation reliable. Where SaaS adoption outpaces review, the control objective shifts to continuous reconciliation across apps, tokens, and identities.

The practical risk is a split-brain identity estate. The IdP may look clean while application-native identities, OAuth grants, and NHI-style credentials continue to operate underneath it. Teams should expect more incidents where offboarding appears successful in IAM reports but fails in the application layer, which means SaaS telemetry, secret governance, and access ownership need to be measured together.

AI agents will amplify the same exposure pattern because they multiply delegated access and tool connections. That makes SaaS visibility a forward-looking NHI control, not a one-time cleanup exercise. Practitioners should prepare for more app-to-app trust chains and build governance around the combined identity surface rather than treating human and machine access as separate problems.

For practitioners

• 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. Reconcile that register against IdP records so offboarding covers both federated and application-native access paths.
• 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. If the integration cannot be monitored and revoked, it should not be treated as in scope for business use.
• 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. Validate the result directly in the application, not only in the identity provider.
• Correlate third-party app logs with destination system logs Join connector telemetry with logs from core systems so investigators can trace a token from source app to target environment. This shortens scoping time and reveals whether an incident came through a trusted integration path.

Key takeaways

• Expanded SaaS connector coverage is really about governing hidden identity paths that live outside the IdP.
• Token-based access, local accounts, and unmanaged integrations can survive offboarding and widen the breach blast radius.
• Security teams need continuous reconciliation across apps, logs, and revocation workflows before visibility gaps become liability gaps.

Key terms

• 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.
• App-native identity workflow: An app-native identity workflow is an access or verification flow implemented directly inside the customer’s own application code rather than delivered only as a fixed embedded component. It improves flexibility, but it also makes governance depend on the organisation’s repository, review, and release controls.
• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
• Connector coverage: Connector coverage is the extent to which an identity platform can integrate with the systems where real access decisions exist. It matters because governance controls only work when the platform can see entitlements, roles, and conflicts in the applications that actually hold risk.

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

👉 The full Obsidian Security post covers the breach patterns, offboarding gaps, and connector coverage implications in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider access paths now appearing across SaaS and AI-driven environments.