What breaks when zero trust stops at SSO in SaaS environments?

Access removal becomes incomplete because SaaS applications often retain direct grants, delegated connections, and local admin roles after the directory account is disabled. That leaves hidden privilege behind even when the primary login path looks closed. Teams need application-level verification before they can claim the identity is fully offboarded.

Why This Matters for Security Teams

zero trust is weakened when it is treated as a login problem instead of an authorization problem. In SaaS environments, disabling SSO can leave behind direct app grants, delegated OAuth connections, and local admin roles that still work after the directory account is removed. That gap matters because the attack surface often survives in the application, even when the IdP looks clean. NIST SP 800-207 Zero Trust Architecture frames this correctly: trust decisions must be continuous and context-aware, not implied by the front door alone. The same lesson shows up repeatedly in incidents such as the Salesloft OAuth token breach, where token-based access outlived the assumptions around primary authentication.

NHI Management Group research shows why this is not a corner case: 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs — Standards section. In practice, many security teams discover residual access only after an incident or a failed offboarding review, rather than through intentional application-level verification.

How It Works in Practice

The operational fix is to treat SaaS access as a layered identity graph, not a single SSO session. First, confirm the IdP account state. Then verify every application-specific grant that may persist independently: direct user memberships, service account bindings, API tokens, refresh tokens, delegated app approvals, SCIM exceptions, and local super-admin roles. If the SaaS platform supports it, validate access through its own audit logs and administrative APIs rather than assuming the directory is authoritative.

This is where workload identity discipline starts to matter even in “human” offboarding flows. When a SaaS integration uses a service principal, OAuth app, or API key, the real question is whether the workload identity still has standing privileges. The Guide to SPIFFE and SPIRE is useful here because it reinforces the broader principle: cryptographic identity should be verifiable at the resource boundary, not inferred from a cancelled login path. For modern SaaS governance, current guidance suggests combining directory deprovisioning with application-native entitlement checks, token revocation, and periodic recertification of delegated access.

• Reconcile IdP disablement against SaaS entitlements and admin roles.
• Revoke OAuth consents, refresh tokens, and API keys separately from SSO.
• Validate SCIM and provisioning connectors so they do not recreate access.
• Check whether break-glass or local admin accounts bypass the directory entirely.
• Record evidence from the SaaS audit trail before closing the offboarding ticket.

The control fails most often in multi-tenant SaaS estates with many shadow admins, legacy integrations, and tenant-local accounts because those privileges are invisible to the directory team.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance faster deprovisioning against the time needed to inspect every connected app and token. That tradeoff is unavoidable in SaaS because some platforms expose excellent admin APIs while others offer only partial visibility, and best practice is still evolving for how much evidence is “enough” to declare access removed.

Edge cases usually involve federated apps with separate authorisation stores, partner-managed tenants, or emergency access that was intentionally exempted from SSO. In those environments, a clean directory deletion does not mean the identity is gone. The most common failure mode is stale delegated access hidden behind consented apps, as seen in breaches like BeyondTrust API key breach and Snowflake breach, where token and secret hygiene were central to the blast radius. NHI Management Group’s broader guidance on offboarding and rotation is clear: if a SaaS platform cannot prove revocation at the app layer, zero trust has not actually reached the asset that matters.

Related resources from NHI Mgmt Group

• What do security teams get wrong about zero trust in agentic access environments?
• What breaks when Zero Trust only covers login and privileged access?
• Why do fragmented IT environments make zero trust harder to enforce?
• Why do non-human identities complicate zero trust architecture?