Who is accountable when a supplier account remains active after handover?

Why This Matters for Security Teams

When a supplier account stays active after handover, the issue is not just excess access. It is a control failure that can preserve privileged pathways long after the business relationship has changed. Accountability matters because someone inside the consuming organisation must own the lifecycle decision, including approval, review, suspension, and revocation. That expectation aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, which treats access management as an operational control, not a vendor courtesy.

Teams often assume the supplier will disable its own access when the engagement ends, but that assumption breaks down when accounts are federated, shared across projects, or linked to service workflows. The practical risk is that dormant supplier access becomes a persistence mechanism for data exposure, change abuse, or lateral movement. In identity programs, this is one of the most common places where governance and technical enforcement drift apart.

In practice, many security teams encounter stale third-party access only after an audit, a contract dispute, or an incident has already exposed the gap, rather than through intentional lifecycle control.

How It Works in Practice

Accountability should be explicit in the access model before the supplier receives any entitlement. The system owner should be responsible for the business need, the business sponsor should confirm that the need still exists, and the security or IAM function should enforce the process controls that make revocation timely. Supplier management teams can coordinate the relationship, but they should not be the sole control point for account removal.

A workable operating model usually includes:

• Named account ownership for every external user or service account.
• Time-bound approvals tied to a contract, statement of work, or change record.
• Periodic recertification by the business sponsor, not just by procurement.
• Revocation authority held by the consuming organisation, with clear escalation paths.
• Logging and alerting for accounts that remain active after the expected end date.

In a mature environment, this also includes privileged access workflows where supplier accounts are issued through PAM, tracked as distinct identities, and monitored for reuse or privilege creep. If the account is tied to non-human automation, the same principle applies: the consuming organisation still owns the lifecycle and should not rely on the supplier to police its own residual access. Control ownership becomes even more important when access is federated across cloud services or granted through shared platform integrations, because a single missed deprovisioning step can leave multiple downstream systems exposed.

Current guidance suggests that the best control is not a single offboarding event but a chain of ownership checks that span approval, provisioning, review, and termination. These controls tend to break down when access is issued through informal project channels because no single team can prove who still has the authority to remove it.

Common Variations and Edge Cases

Tighter supplier access governance often increases administrative overhead, requiring organisations to balance speed for delivery against assurance that access does not outlive its purpose. That tradeoff becomes more visible in fast-moving engineering, cloud operations, and managed-service arrangements.

There is no universal standard for every handover scenario. For short-term consultancy, the system owner may be sufficient as the accountable party, while for managed service providers, accountability may need to be split across the service owner, the contract owner, and the security function. The important point is that accountability must remain internal to the consuming organisation, even when execution is outsourced.

Edge cases often appear when supplier access is embedded in automated jobs, break-glass accounts, or standing administrator privileges. In those cases, governance should treat the account as part of the organisation’s own control surface, not as an external exception. Where the account supports sensitive data or regulated workloads, current practice increasingly favours stronger review intervals and stronger evidence of termination than a simple ticket closure. For deeper control mapping, teams can anchor lifecycle and access governance to the broader control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Related resources from NHI Mgmt Group

• Who is accountable when a vendor account remains active after the work ends?
• Who is accountable when a workload secret remains active after compromise?
• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when a user remains active after directory removal?