Who should own offboarding when access to customer environments spans engineering, support, and security teams?

Ownership should sit with the team that controls the access workflow, with security defining the policy and engineering or support executing it in daily operations. Shared responsibility works only when revocation is unambiguous, time bound, and measurable. If ownership is unclear, offboarding becomes a coordination problem, which is how access lingers after a project ends or an employee leaves.

Who Owns Offboarding When Access Spans Multiple Teams

Offboarding should have one accountable owner, even if more than one team executes the work. The right owner is the team that can actually revoke, disable, or time-box the access path end to end. In practice, that is often engineering or support for day-to-day execution, while security sets policy, controls, and audit expectations.

When access spans customer environments, the ownership question is really about control of the workflow. If one team can approve access but another team can only request it, then the requestor cannot own revocation. A clean ownership model makes the handoff explicit, removes ambiguity at the end of employment or engagement, and prevents access from surviving past its business purpose.

For a broader lifecycle view, the strongest internal guidance is the NHI Lifecycle Management Guide, which treats offboarding as part of the same control plane as provisioning, rotation, and visibility. That framing matters because offboarding failures are rarely just process gaps, they are usually ownership gaps.

What Good Shared Responsibility Looks Like

Shared responsibility works only when each team’s role is narrow and measurable. Security should define the offboarding policy, required revocation paths, evidence standards, and escalation thresholds. Engineering or support should own the operational steps, such as disabling access, revoking tokens, closing support-specific credentials, and confirming that customer access cannot be reactivated without a new approval.

The main failure mode is split accountability. If security owns the policy but not the systems, and operations owns the systems but not the decision, neither team has a complete view of whether access was actually removed. That is why shared responsibility needs a single system of record, a named owner for each access class, and a time bound service-level expectation for completion.

The most useful internal reference for the lifecycle and ownership mechanics is Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs, because it ties ownership to lifecycle control rather than team boundaries. For a risk-focused view of what happens when ownership is vague, Ultimate Guide to NHIs, Key Challenges and Risks is the better anchor.

Risk and Threat Considerations

Unclear ownership turns offboarding into a delay problem, and delay is the exposure. When no one is clearly accountable for revocation, access can remain active after a role change, project end, or departure, which preserves a live path into customer environments longer than intended. That creates both operational risk and a compromise opportunity if the old access is later abused.

Failure mechanism: One team assumes another team will revoke the access, but the handoff is not tracked, so tokens, accounts, or support paths remain usable after the relationship ends.

Impact: Lingering access increases blast radius, weakens auditability, and can allow continued customer environment access after the person or project should no longer have it.

For evidence that this is not a theoretical failure, the 2025 State of NHIs and Secrets in Cybersecurity highlights that 91% of former employee tokens remain active after offboarding, which is exactly the kind of stale-access condition that weak ownership allows. The breach pattern behind this is also reinforced by Coupang Signing Key Breach, where unrevoked credentials persisted beyond the point at which they should have been retired.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 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
OWASP Non-Human Identity Top 10	NHI Lifecycle Management — Lifecycle Management	Offboarding is a core NHI lifecycle control across provisioning and revocation.
Recommendation — Define a single revocation owner and require time-bound access removal evidence.
CIS Controls v8	6 — Access Control Management	Access removal and ownership are direct access-control operations with measurable enforcement.
Recommendation — Assign accountable owners for revocation and verify access is removed on schedule.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	The question concerns who governs and executes access removal across teams.
	GV.RM — Risk Management Strategy	Ambiguous ownership is an operational risk that needs explicit governance and accountability.
Recommendation — Map each customer access path to an owner and enforce timely deprovisioning. Set accountability for access removal as a managed risk with defined escalation.
NIST Zero Trust (SP 800-207)	4 — Policy Engine and Policy Enforcement	Offboarding works when policy and enforcement are clearly separated but coordinated.
Recommendation — Separate policy ownership from execution and enforce revocation through policy-controlled workflows.

Practitioner Guidance

What to prioritise: Assign one accountable owner per access path, not per team. If engineering, support, and security all touch the workflow, document which group can actually complete revocation and which group only governs or approves it.

What to verify: The offboarding process should produce evidence, not just a ticket closure. Verify that revocation is time bound, that the access path is uniquely identified, and that there is a confirmation step showing the customer environment can no longer be reached through the former route.

Decision rule: If revocation requires coordination across teams, treat the process as high risk unless the workflow has one named executor, one approval owner, and one measurable completion target. If any of those are missing, the process is still ambiguous.

Practitioner takeaway: Offboarding fails when ownership is shared in theory but fragmented in execution, so the safest model is one accountable operator, one policy owner, and one auditable revocation path.