Why do SaaS connectors create identity governance risk after offboarding?

Why connectors outlive the offboarding event

Offboarding in the identity provider often closes only the federated login path. SaaS connectors can keep their own local user record, delegated consent, refresh token, API key, or service-side authorization alive, so the app still recognizes the connection after the directory account is disabled. That is why connector governance has to be treated as a separate lifecycle problem, not just a login problem.

The practical issue is that offboarding answers “can the person still sign in through the primary identity layer?” but not “what other trust grants did this app already issue?” If the connector was authorized directly inside the SaaS tenant, or if automation used the same integration to act on the user’s behalf, the access path may persist until the application-side grant is explicitly revoked.

Connector sprawl also creates hidden ownership gaps. When security teams cannot prove which applications were connected in the first place, they cannot prove that all downstream entitlements were removed either. That is a governance failure, because the risk is not just lingering access, it is lack of evidence that access ever left the estate cleanly.

Which access paths survive the directory cleanup

The common survivors are local application accounts, delegated OAuth consent, and app-issued tokens. A federated SSO or IdP deprovisioning step may remove the easiest path, but it does not automatically invalidate every token cache, consent grant, or connector object already created inside the SaaS platform. In practice, that means a connector can still read mail, sync files, pull CRM data, or post to another system even after the human offboarding record is closed.

This is why the distinction between authentication and authorization matters. Authentication can be withdrawn at the IdP, yet authorization may still exist inside the application as a separate grant. For SaaS apps that maintain their own tenants or delegated app trust, the effective control point is the connector and its stored secret or consent, not the directory user record alone.

Discovery is part of the control, not an extra nice-to-have. IAM and IGA Basics is useful here because the governance problem is really about provisioning, entitlements, and access certification across both people and connected apps. For lifecycle-specific cleanup, Joiner-Mover-Leaver (JML) Guide shows why offboarding must include revocation of the tokens, keys, and connectors that a leaving user may have left behind. The broader lifecycle view is also captured in NHI Lifecycle Management Guide, which treats offboarding, rotation, and visibility as a single operational chain rather than isolated tasks.

Why this is an identity governance problem, not only an app admin task

SaaS connector risk becomes an identity governance issue because it sits at the boundary between central directory control and local application trust. If the estate lacks a current inventory of connectors, consents, and app-local accounts, offboarding is only partially observable. The result is residual access that can survive policy compliance on paper while still being active in production.

That gap matters most in environments with shared integrations, delegated admin access, or service accounts that are reused across teams. The app may still have enough standing privilege to continue acting, even when the original user is gone. The governance question is therefore not “was the user disabled?” but “were all access grants, tokens, and connector relationships discovered, mapped, and revoked?”

For that reason, Access Reviews and Certification Guide is relevant because connector inventories need periodic attestation, not just event-driven cleanup. IGA Buyer's Guide is also a practical fit when organisations need platform features that can discover disconnected applications, review entitlements, and close the loop on remediation. Identity Visibility and Intelligence Platforms (IVIP) Guide matters when the core problem is simply not being able to see where access still exists.

Risk and Threat Considerations

SaaS connector residue creates a real post-offboarding exposure because it preserves the ability to act even after the main identity has been removed. The risk is strongest where OAuth consent, refresh tokens, local app accounts, or long-lived API credentials are not revoked in the same workflow, because an attacker or former user can continue to use a trusted integration path without needing the original login.

Failure mechanism: Offboarding removes federated authentication but leaves a separate application-side authorization grant, token, or local account intact, so the connector still works.

Impact: Data access, workflow execution, and downstream system changes can continue after the user is supposedly gone, and the organisation may not notice until an audit, incident, or anomalous activity reveals the orphaned connection.

Practitioner Guidance

What to verify: Confirm that offboarding runbooks cover the SaaS tenant itself, not just the IdP. The minimum verification is a current connector inventory, evidence that delegated consents were revoked, and proof that any app-local account or token was removed or expired.

Decision rule: If a SaaS app can authenticate with anything other than the corporate SSO path, treat that connector as a separate identity lifecycle object. Disable the directory account, but also revoke the app grant, rotate any shared secret, and confirm the connector no longer has effective access.

What to measure: Track the percentage of offboarded users whose connected apps were enumerated and closed within the same change window. If the organisation cannot report that number, it does not yet have a complete offboarding control.

Practitioner takeaway: Offboarding is only complete when every trust path is closed, and for SaaS connectors that usually means the identity team and the application owner must both sign off on revocation.

Related resources from NHI Mgmt Group

• Why do one-off connectors create governance risk in identity security?
• Why do former employees create identity risk after offboarding?
• Why do unmanaged SaaS apps create identity governance risk?
• Why do SaaS renewals create identity governance risk?