Who is accountable when third-party access remains active after the task is complete?

Why This Matters for Security Teams

When third-party access remains active after a task is complete, the issue is not just access sprawl. It is a governance failure that leaves an external party with standing capability long after the business justification has ended. That creates audit exposure, weakens least privilege, and increases the chance that a forgotten account, token, or API key becomes the entry point for misuse.

This is especially visible in NHI incidents, where dormant credentials and unmanaged integrations are repeatedly abused. NHIMG’s 52 NHI Breaches Analysis shows how often access control breaks down once identities are no longer actively monitored. OWASP’s OWASP Non-Human Identity Top 10 also highlights that unmanaged service access is a recurring risk, not an edge case.

The key mistake is assuming that temporary business need automatically produces temporary technical access. In practice, many security teams encounter this only after an external supplier, contractor, or integration has already kept working permissions long past the approved window.

How It Works in Practice

Accountability should follow the control points that created and sustained the access. The governance owner approves the business need, but the operational owner must enforce expiry, review, and revocation. If either side treats third-party access as a one-time approval instead of a lifecycle, the organisation inherits residual risk.

Practitioners usually need three linked controls:

• Time-bound access with a clear end date, not an open-ended exception.
• Periodic recertification by the approving business owner and the system owner.
• Automated offboarding that revokes accounts, tokens, keys, and delegated permissions at task completion.

For machine-to-machine and vendor integrations, workload identity and ephemeral credentials are preferable to static shared secrets. NIST’s Cybersecurity Framework 2.0 expects access to be actively governed, while the Ultimate Guide to NHIs explains why non-human access must be managed as a lifecycle, not a ticket. Where possible, pair approval workflows with revocation automation so the record of who approved access matches the record of who removed it.

That approach aligns with common identity practice, but current guidance suggests the strongest control is still real-time enforcement rather than manual sign-off alone. These controls tend to break down when third-party access is embedded in legacy integrations because no single owner can reliably see every downstream token, credential, or delegated permission.

Common Variations and Edge Cases

Tighter offboarding often increases coordination overhead, requiring organisations to balance fast vendor onboarding against stronger expiry and review discipline. That tradeoff becomes more visible when access is granted for support, incident response, or data migration, where business teams want speed but security needs a verifiable end state.

There is no universal standard for this yet, but best practice is evolving toward explicit accountability models. In many environments, the business sponsor owns the justification, the platform or IAM team owns the technical revocation, and procurement or vendor management owns contract clauses that require timely offboarding. If one of those roles is missing, the access often survives because everyone assumes someone else is watching it.

Edge cases include shared vendor admin accounts, long-lived API integrations, and emergency break-glass access. Those scenarios should not be treated as exceptions to governance; they should have stricter logging, shorter TTLs, and mandatory post-use review. NHIMG’s DeepSeek breach illustrates how exposed credentials can create downstream exposure long after the original purpose has passed. In practice, the highest-risk failures happen when third-party access is approved for a project but never formally closed at project end.

Related resources from NHI Mgmt Group

• Who is accountable when third-party cloud access is abused in a data breach?
• 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?
• Who is accountable when vendor access remains active after a banking engagement ends?