Who should own access removal when employee offboarding spans identity, SaaS, and cloud systems?

Ownership should sit with the people who control each resource, while IAM or security coordinates the overall workflow. The identity team can disable the primary account, but application owners must revoke access to tools outside the IdP and transfer any shared data or admin privileges. Clear accountability prevents gaps when access is spread across multiple platforms and teams.

Who Owns the Offboarding Work When Access Spans Multiple Platforms?

Ownership should follow control of the resource, not a single team’s convenience. The identity team can disable the core directory account, but SaaS administrators, cloud platform owners, and application owners each control the access paths that live outside the IdP. That split matters because a complete offboarding depends on coordinated revocation, not just one account being turned off.

In practice, IAM or security should run the workflow, set the deadline, and verify closure, while the resource owner executes the removal that only they can authorise. That includes removing privileged roles, rotating shared access where needed, and transferring ownership of data or automation before access is withdrawn. The most reliable pattern is a named owner per system, backed by a standard offboarding checklist and a clear exception path for dormant accounts, federated apps, and cloud-native service roles.

How to Split Responsibility Without Leaving Gaps

Offboarding breaks down when teams assume that disabling the employee’s primary login automatically removes every effective access path. That assumption is wrong in environments where access is federated across SaaS tools, direct cloud roles, local admin consoles, or shared workspaces. The practical control is to treat offboarding as a short-lived workflow with explicit handoffs: identity ops handles the directory record, resource owners remove application-level permissions, and cloud or platform teams revoke direct roles and keys.

A useful ownership model distinguishes between coordination and execution. IAM or security should own the process, timeline, and evidence capture. Resource owners should own the actual entitlement removal for the systems they administer because they know which permissions, service links, and delegated shares matter. For example, if a user owns a SaaS integration, the owner may need to reassign the integration before disabling access; if a user has cloud console privileges, the cloud platform owner may need to remove role bindings, not just the directory group. NHI Management Group research has found that 91% of former employee tokens remain active after offboarding, which is a strong signal that the risk is not theoretical but lifecycle-related.

Effective teams also define which actions are reversible and which are not. Removing a standard user from a group is routine, but removing a shared admin role, a service credential, or a collaboration space can break automation or business continuity if ownership transfer is not handled first. That is why the sequence matters:

Disable the primary identity to stop fresh authentication.
Remove direct entitlements in SaaS and cloud systems owned outside the IdP.
Reassign or revoke shared administrative access and ownership.
Confirm that secrets, tokens, and delegated access paths are retired or rotated.
Record evidence that each owner completed their part of the workflow.

These controls tend to break down when offboarding is managed as a ticket closure exercise instead of a cross-system access removal process, because the highest-risk entitlements are often outside the directory and invisible to the first team that closes the request.

When Ownership Becomes a Governance Problem

Tighter ownership boundaries can improve accountability, but they also increase coordination overhead, especially in organisations with many SaaS admins and cloud platform teams. The tradeoff is clear: centralising every action creates bottlenecks, while decentralising without ownership creates blind spots. The right balance is usually a federated model with one accountable coordinator and named system owners who can actually remove access.

Current guidance suggests paying special attention to systems where access is shared, inherited, or indirectly granted. That includes group-based SaaS entitlements, cloud roles attached to projects or subscriptions, and applications that bypass the IdP entirely. If the access path is local to the platform, the platform owner must be able to prove revocation. If the access path is tied to a shared secret or automation token, the owner must be able to prove rotation or retirement. The question is not who initiates the offboarding request, but who can technically and operationally remove the last valid path to use that access.

For readers who want a deeper lifecycle view, the NHI Lifecycle Management Guide is useful because it frames removal as part of a broader identity lifecycle rather than a one-time HR event. The OWASP Non-Human Identity Top 10 also reinforces the wider pattern: access often persists in places that central identity tooling does not fully control.

Risk and Threat Considerations

The main risk is residual access after departure, especially where the employee had privileges across SaaS, cloud, or shared operational systems. Offboarding failures are dangerous because one missed entitlement can preserve a valid path into production data, collaboration spaces, or administrative consoles long after the primary account is disabled.

Failure mechanism: Attackers and insiders exploit the gap between identity deactivation and resource-level revocation. If direct roles, delegated shares, tokens, or local admin rights are not removed, the former user or anyone who obtains those credentials can continue to access systems, bypassing the directory shutdown and extending the compromise window.

Impact: The organisation can lose confidentiality, integrity, and accountability at the same time. Data exposure may continue, privileged actions may remain possible, and audit trails can become misleading because the identity record suggests the user is gone while effective access still exists.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	5 — Account Management	Offboarding requires timely removal of user and privileged access across systems.
Recommendation — Enforce account disabling and entitlement removal as part of a verified offboarding workflow.
NIST CSF 2.0	PR.AC — Identity Management, Authentication and Access Control	Access removal is an access-control lifecycle issue spanning multiple systems.
	PR.IP — Information Protection Processes and Procedures	Offboarding needs a repeatable process with evidence and ownership.
Recommendation — Coordinate identity and entitlement revocation across all platforms before closing offboarding. Standardise offboarding procedures and retain proof that each access path was removed.
NIST Zero Trust (SP 800-207)	AC-4 — Dynamic Access Control	Access should be revoked at the resource level when trust is no longer valid.
Recommendation — Re-evaluate and remove access at the resource layer instead of relying on directory closure alone.
MITRE ATT&CK	T1098 — Account Manipulation	Residual or altered accounts and entitlements can preserve access after departure.
Recommendation — Monitor for lingering or modified account entitlements that survive employee offboarding.

Practitioner Guidance

What to prioritise: Assign the offboarding owner to the team that can verify complete revocation, not just ticket routing. IAM should coordinate the workflow, but each SaaS, cloud, and application owner must sign off on the removal of access they control.

What to verify: Before closing the case, confirm three things: the primary account is disabled, all non-IdP access paths are removed, and any shared or privileged ownership has been transferred or retired. If a system cannot produce evidence of revocation, treat that as an open offboarding item.

Decision rule: If the access is tied to a platform-native role, token, or shared admin function, the resource owner must own the final removal. If the access is purely directory-based, IAM can complete it directly.

Practitioner takeaway: Offboarding is complete only when the last usable path is gone, which means ownership must be distributed to the teams that control each path and then coordinated centrally for proof.