Who is accountable when third-party access remains active after the engagement ends?

Why This Matters for Security Teams

When third-party access stays active after an engagement ends, the issue is not just cleanup timing. It is evidence that ownership, offboarding, and entitlement review were never connected end to end. That gap creates lingering access paths that can be reused, forgotten, or exploited long after the business relationship is over. OWASP’s Non-Human Identity Top 10 highlights how unmanaged machine and service access becomes a durable attack surface when lifecycle controls are weak.

NHI Management Group’s 52 NHI Breaches Analysis shows the same pattern repeatedly: access persists because no one is forced to prove who owns revocation. That is why accountability must be visible in the identity programme, not buried in procurement, ticketing, or vendor management. In practice, many security teams encounter stale third-party access only after an audit, an incident, or a contract dispute has already exposed the gap.

How It Works in Practice

Accountability for third-party access should be shared, but the operational burden must be explicit. The business owner defines the need for access, the access owner approves and periodically reviews it, and the third-party sponsor confirms when the work has ended. Security then enforces the control plane: time-bound entitlements, documented offboarding, and revocation triggers tied to contract end dates, project closure, or inactivity thresholds.

This is where lifecycle automation matters. Access reviews should not rely on memory or manual follow-up alone. Current guidance suggests linking IAM, PAM, and vendor management records so that termination events generate a removal workflow. For service accounts, API keys, and other secrets, the same principle applies: short-lived credentials are safer than long-lived static access because they reduce the window in which forgotten access can be abused. The Ultimate Guide to NHIs is useful here because it frames access as an identity lifecycle problem, not a one-time approval.

• Assign a named business owner for every third-party engagement.
• Require an access owner to validate least privilege before provisioning.
• Link sponsor approval to contract start and end dates.
• Automate revocation when the engagement closes or the ticket is resolved.
• Review privileged third-party access on a fixed cadence, not ad hoc.

For implementation, teams often align with OWASP Non-Human Identity Top 10 guidance and workload-centric identity practices so that access can be proven, limited, and revoked with evidence. These controls tend to break down when vendor access is shared across multiple internal owners because no single system records who is responsible for offboarding.

Common Variations and Edge Cases

Tighter third-party access controls often increase operational overhead, requiring organisations to balance fast vendor onboarding against stronger revocation discipline. That tradeoff is real, especially in managed service, consulting, and emergency response scenarios where access is needed quickly and then forgotten after the incident passes.

There is no universal standard for this yet, but best practice is evolving toward explicit expiry dates, just-in-time access, and periodic reattestation for every external account. Where vendors use shared credentials or unmanaged service accounts, accountability becomes harder because the person who approved access is not always the person who can remove it. In those cases, the control must shift from trust in people to enforcement in systems.

Security teams should also treat inactive access differently from approved long-duration access. A contractor with a valid six-month project may need persistent access, but the entitlement still needs a documented sunset and a named reviewer. The most common failure mode is not malicious retention; it is ambiguous ownership across procurement, IT, and the business unit. That is why role clarity and lifecycle evidence matter as much as the access decision itself.

For broader context on how stale identities turn into breach paths, the DeepSeek breach and LiteLLM PyPI package breach both show how quickly exposed identities and credentials can become operational risk once ownership is unclear.

Related resources from NHI Mgmt Group

• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when third-party access remains active after the task is complete?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a third-party integration keeps an NHI active after the business need ends?