SaaS connector coverage is now an identity governance control

At a glance

What this is: Obsidian Security argues that connector coverage has become part of identity governance because uncovered SaaS apps leave OAuth tokens, local accounts and non-human identities outside normal offboarding and investigation workflows.

Why it matters: This matters because IAM and SaaS security teams cannot treat SSO as complete coverage when app-native identities and third-party connections can outlive user deprovisioning and widen breach evidence gaps.

Context

SaaS governance fails when visibility stops at the identity provider. SSO can disable federated access, but it does not automatically remove local accounts, OAuth grants, API keys, or non-human identities inside the connected applications themselves.

That gap turns connector coverage into an identity control problem, not just a monitoring problem. The article's core point is that every uncovered app leaves both residual access and incomplete evidence, which is typical in fast-moving SaaS environments where employees adopt tools outside IT review.

Key questions

Q: What breaks when SaaS connector coverage is incomplete?

A: Incomplete connector coverage leaves local accounts, OAuth grants, API keys, and non-human identities outside normal governance. SSO may still look healthy, but the real access paths remain active inside the applications. That creates residual access after offboarding and makes incident investigation incomplete because the missing connector also means missing telemetry.

Q: Why do SaaS connectors create identity governance risk after offboarding?

A: Because offboarding in the identity provider only closes the federated path. If the user or integration also had local application access, delegated OAuth consent, or an app-generated token, that access can survive independently. The risk is highest when security teams cannot prove which applications were connected in the first place.

Q: What are the signs that OAuth permissions are drifting out of control?

A: Look for integrations with broad scopes, unused apps that still hold active tokens, unclear ownership, and access patterns that do not match the original business case. Those signals usually mean the integration has become a dormant or over-privileged access path that needs review before it turns into an incident.

Q: How should security teams govern shadow IT in SaaS environments?

A: Security teams should govern shadow IT by treating it as unmanaged access, not just unsanctioned software. Start with continuous discovery, then map each app to owners, data types, delegated scopes, and revocation paths. The control goal is to reduce hidden access paths before they become business-critical dependencies.

Technical breakdown

Why SSO deprovisioning does not close SaaS access paths

Single sign-on centralises authentication, but SaaS applications often maintain their own native identities and delegated grants. Local accounts, OAuth tokens, API keys, and service credentials can persist after the federated account is removed, especially when the app was added outside formal onboarding. That means the IdP can say the user is gone while the application still accepts the token or local credential. The control boundary is therefore split across the IdP and each SaaS tenant, which is why app visibility matters as much as directory hygiene.

Practical implication: Treat each connected application as a separate identity domain and verify offboarding at the app layer, not only in the IdP.

How OAuth drift creates hidden access and investigation gaps

OAuth drift is the gap between the connections security teams think exist and the active grants actually present in the environment. Once a third-party app receives consent, the issued token can authorize downstream actions long after the original user workflow ends. If the app is shadow IT, the security team may never inventory the grant, making forensic reconstruction impossible when an incident occurs. The same problem appears in AI assistant connectors and other delegated integrations, where the trusted token becomes the real control plane.

Practical implication: Continuously inventory delegated OAuth grants and tie them to application ownership, telemetry, and revocation workflows.

Why connector coverage now functions as governance evidence

When an incident crosses an uncovered SaaS application, the missing logs become an audit and liability problem as much as a security problem. Governance depends on answering who accessed what, through which app, and whether that access still existed at the time of the event. If the connector is missing, the record is incomplete by design. In practical terms, connector coverage is now part of evidentiary control, because incomplete application visibility undermines both incident response and board reporting.

Practical implication: Include connector completeness in governance reporting and incident readiness so evidence gaps are visible before a breach exposes them.

Threat narrative

Attacker objective: The attacker wants to use delegated SaaS trust to reach sensitive data and downstream environments while avoiding password theft or direct exploitation.

1. Entry occurs when a user approves a third-party SaaS integration or shadow app that security never reviewed, creating a trusted connection outside normal governance.
2. Credential access follows when the attacker inherits a valid OAuth token, API key, or local account credential tied to that integration.
3. Escalation and lateral movement happen when the trusted app pivots into core SaaS systems and reaches data that the original app should not have been able to touch.
4. Impact is unauthorized access to customer data, source code, or downstream SaaS environments, with the added cost of incomplete forensic evidence.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

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

Connector coverage is now an identity governance control: the boundary of SaaS identity has moved from the IdP to the application estate. SSO can only govern what it can see, and every hidden connector creates a separate lifecycle and revocation problem. For practitioners, this means app coverage must be measured as part of identity governance, not treated as an adjunct to discovery.

OAuth drift is the governance gap most teams are missing: delegated access often persists after the original business reason has passed, especially in shadow IT and AI-assisted workflows. That creates a control gap where the application still trusts a token long after the user or tool should have been re-authorized. Practitioners should treat delegated grants as living access, not one-time approvals.

Uncovered SaaS applications break both offboarding and incident reconstruction: if a connector is absent, the control failure is not just residual access but missing evidence. That is a governance and liability issue as much as a security issue, because boards and auditors need a defensible record of who could reach what. The practical conclusion is to make coverage completeness part of assurance reporting.

AI assistants and third-party integrations intensify the same control problem: they add more non-human identities, more delegated permissions, and more places where trust is inherited rather than continuously proven. That is why NHI governance increasingly sits alongside SaaS governance in the same control conversation. Organisations need a named owner for every integration path before access becomes operational debt.

Zero-trust thinking only works when connector scope is complete: a trust model that ignores application-native identities, OAuth grants, and local accounts assumes away the most common bypass paths. The result is a governance system that certifies the directory while leaving the estate exposed. Practitioners should align connector coverage with least-privilege and lifecycle control, not only with logging.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Connector completeness will become a board-level governance metric: once SaaS estates expand faster than review cycles, the real question is not whether SSO exists but whether every app, grant, and native account is visible and revocable. That is where identity governance meets operational reality, and it is where NHI controls start to matter for SaaS too.

Shadow SaaS creates a persistence layer for access: the article's 78% shadow-app observation fits a wider pattern in which unknown connectors preserve access long after users move on or business teams change tools. Organisations should expect delegated grants and local accounts to outlive the directory record unless they are actively reconciled.

Non-human identities now sit inside SaaS governance boundaries: when agents, integration tools, and service credentials can act through enterprise applications, connector coverage becomes part of NHI lifecycle management. The control objective shifts from simply discovering apps to proving that each non-human path is owned, scoped, and revocable.

For practitioners

• Map every SaaS connector to an owning team Create an authoritative inventory of applications, delegated integrations, and ownership so no connector exists outside a named control boundary.
• Reconcile IdP deprovisioning with app-native access Verify that local accounts, OAuth grants, API keys, and other app-level identities are removed or disabled when users leave or change role.
• Track shadow apps as governance exceptions Treat unsanctioned or user-added apps as formal risk items with expiry dates, review ownership, and revocation triggers instead of informal findings.
• Monitor delegated OAuth grants continuously Alert on new or long-lived OAuth consents, then review whether the connected service still needs access to the data and systems it can reach.
• Use connector coverage as an assurance metric Report the percentage of critical SaaS services covered by telemetry, offboarding controls, and revocation capability so evidence gaps are visible to security and audit teams.

Key takeaways

• SaaS connector coverage has moved from a visibility concern to an identity governance control because app-native accounts and delegated grants can survive SSO deprovisioning.
• Shadow apps, OAuth tokens, and local credentials create both residual access and incomplete evidence, which raises security and audit risk at the same time.
• Security teams need app-level ownership, continuous connector inventory, and revocation workflows that reach beyond the identity provider.

Key terms

• SaaS Connector Coverage: The proportion of connected software-as-a-service applications that are visible to security tooling and governed by lifecycle controls. In practice, it determines whether teams can monitor, revoke, and investigate access across the full app estate rather than only the directory layer.
• OAuth Drift: Divergence in OAuth configuration, scope definitions, or token handling across otherwise similar services. In MCP environments, drift creates inconsistent trust decisions and makes it harder to prove that the same access rule is being applied everywhere.
• 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.
• Application-Native Identity: An account or credential that exists inside a SaaS platform rather than only in the central IdP. These identities are often missed by SSO-only offboarding processes, so they require direct inventory, ownership, and deprovisioning controls within the application boundary.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course covers NHI governance, machine identity security, and secrets management through a practitioner-led curriculum. It suits security teams that need to connect identity controls across SaaS, cloud, and emerging agentic workflows.