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

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.

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.

Related resources from NHI Mgmt Group

• How should security teams limit insider access to sensitive support tools in customer-facing environments?
• Who should be accountable for break-glass access when emergency privileged access spans security, IT, and management teams?
• How should security teams control privileged access in work-from-anywhere environments?
• How should security teams manage suspended user access to reduce identity risk and support compliance?