Who is accountable when a vendor account remains active after the work ends?

Accountability sits with the business owner, the technical approver, and the identity team that failed to remove the access. In regulated or safety-sensitive environments, that shared accountability must be explicit, because lingering access is not just an administrative miss. It is a governance failure that can affect compliance, audit evidence, and operational resilience.

Why This Matters for Security Teams

When a vendor account stays active after the work ends, the issue is rarely just a missed deprovisioning step. It becomes an ownership problem across procurement, business operations, IAM, and security controls. In practice, that lingering access can still reach production systems, data stores, support queues, or AI tooling long after the contract or task has closed.

The risk is amplified because third-party accounts often carry exceptions, shared privileges, or stale approvals that were accepted for speed. Guidance from the NIST Cybersecurity Framework 2.0 places identity governance inside ongoing risk management, not one-time provisioning, which is why accountability must be explicit before the account is created. NHIMG’s research on the Ultimate Guide to NHIs — The NHI Market shows how quickly unmanaged identities become operational debt when ownership is unclear.

In practice, many security teams encounter the failure only after an audit finding, a vendor offboarding dispute, or an incident review, rather than through intentional access lifecycle control.

How It Works in Practice

Accountability for a stale vendor account should be assigned at three levels: the business owner who requested the access, the technical approver who authorized the entitlement, and the identity or platform team that executed the lifecycle control. Those roles are distinct because removal depends on both governance and implementation. If any one of them treats deprovisioning as “someone else’s job,” the account tends to survive past the work period.

Practitioners usually reduce risk by making account closure part of a defined offboarding workflow. That means the vendor end date, contract end date, and access review date are all linked, with termination triggers routed into IAM or PAM. For high-risk access, best practice is evolving toward time-bound approval, just-in-time access, and automatic expiry rather than manual cleanup. The LLMjacking: How Attackers Hijack AI Using Compromised NHIs research is a useful reminder that compromised or abandoned credentials can be abused very quickly once they exist.

• Document one accountable business owner for every vendor identity.
• Record the technical approver and the expiry condition at approval time.
• Use short-lived access where possible, with automatic revocation on end date.
• Require periodic attestation for any exception that remains active.
• Log revocation evidence so audit teams can verify closure.

Operationally, this works best when the identity team owns the mechanism, the business owner owns the risk acceptance, and security owns monitoring and enforcement. These controls tend to break down in distributed procurement environments where vendors are onboarded through local teams because no single system receives the definitive offboarding signal.

Common Variations and Edge Cases

Tighter deprovisioning often increases workflow overhead, so organisations must balance speed of vendor onboarding against the cost of stale access. That tradeoff is especially visible in emergency support, outsourced engineering, and regulated environments where access needs to start fast but still end predictably.

There is no universal standard for this yet, but current guidance suggests that shared accountability should be documented in the access request itself, not inferred later during an incident. If a vendor account is tied to a third-party managed service, the vendor may operate the account day to day, but the customer still retains accountability for the entitlement lifecycle and the risk it creates. The same is true for service account used by integrators, MSPs, or automation platforms.

Edge cases often appear when contracts renew without re-approval, when a supplier changes personnel but keeps the same account, or when a decommission request is sent to procurement instead of IAM. In those situations, the control failure is not just missed deletion. It is a broken ownership chain. NHIMG’s view of the NHI market is that identity sprawl is a governance issue first, and a tooling issue second.

Where contracts, delegated administration, and shared service desks overlap, accountability often becomes disputed only after access is found to be active during review or after an incident.

Related resources from NHI Mgmt Group

• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when SSO leaves users active after offboarding?
• Who is accountable when a third-party integration keeps an NHI active after the business need ends?
• Who is accountable when a workload secret remains active after compromise?