Who is accountable when a third party keeps access after the work ends?

Accountability should sit with the business owner who requested the access and the system owner who approved and enforced it. If revocation fails, the organisation has a governance problem, not just a technical one. Frameworks such as the NIST Cybersecurity Framework 2.0 expect access control and oversight to be measurable, not informal.

Why This Matters for Security Teams

When third-party access outlives the work, the risk is not just stale permissions. It is an ownership failure across procurement, engineering, security, and the business team that requested the access in the first place. NHI Management Group’s research on 52 NHI Breaches Analysis shows that identity sprawl and weak lifecycle controls repeatedly turn temporary access into lasting exposure. The same pattern appears in the OWASP Non-Human Identity Top 10, where over-privilege and poor secret hygiene are treated as systemic problems, not one-off mistakes.

The practical issue is accountability. If a vendor, contractor, or integrator still has access after the engagement ends, someone failed to define the end state, enforce revocation, or verify completion. In many organisations, access is granted through one workflow and removed through a different one, which creates a gap no one formally owns. That gap is where incident response, audit findings, and regulatory questions start. In practice, many security teams encounter lingering third-party access only after a project is closed, a token is abused, or an offboarding review exposes that no one ever checked revocation.

How It Works in Practice

Accountability should follow the control points, not just the system. The business owner who requested the third party should own the business justification and end date. The system owner should own enforcement, including whether access is time-bound, scoped, and revocable. Security and IAM teams should define the policy and verify that removal actually happened. This aligns with the NIST Cybersecurity Framework 2.0 expectation that access control is measurable, and with the NIST AI Risk Management Framework when access is granted to autonomous or semi-autonomous services.

For third-party access, best practice is evolving toward explicit lifecycle controls: approval, expiry, periodic review, and revocation evidence. That means the access request should include the purpose, named sponsor, vendor contact, expiration date, and the specific identities or secrets involved. It also means token-based access, OAuth grants, API keys, and service accounts must be monitored separately because they fail in different ways. NHI Management Group’s Ultimate Guide to NHIs is useful here because it frames non-human access as a lifecycle problem, not only an authentication problem.

• Assign a named business owner for every third-party entitlement.
• Set a hard expiry for access at request time, not after renewal.
• Use joiner-mover-leaver style offboarding for vendors, contractors, and integrations.
• Log revocation proof, including timestamp, approver, and affected identities.
• Review third-party OAuth grants and service accounts separately from human user access.

Where possible, pair policy with technical enforcement such as short-lived credentials, scoped tokens, and automated removal hooks. These controls tend to break down when access is granted through shadow IT, shared admin accounts, or unmanaged SaaS integrations because there is no authoritative system to trigger revocation.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance speed for delivery teams against assurance for access governance. That tradeoff becomes sharper with consultants, managed service providers, and embedded software vendors, where access may be needed intermittently rather than continuously. Current guidance suggests that the sponsor still owns the business need, but the platform owner must enforce expiry and the security team must validate that access was actually removed.

There is no universal standard for this yet when access is inherited through application dependencies or delegated OAuth consent. In those cases, the access may survive even after the project ends because the credential is embedded in a workflow, not tied to a person. The 2025 State of NHIs and Secrets in Cybersecurity report is a reminder that lifecycle failures are common, especially when tokens and secrets are reused across systems. For a breach-driven view of what happens when access is not retired on time, the Salesloft OAuth token breach shows how third-party trust can persist long after the original purpose has ended.

Where the third party is a software agent or automation, accountability does not disappear. It shifts to the team that deployed the agent, approved the scope, and accepted the residual risk. If no one can point to a named owner for revocation, the organisation does not have a third-party access problem alone, it has an accountability design problem.

Related resources from NHI Mgmt Group

• 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 for third-party access when a vendor relationship ends?
• What breaks when third-party access is not reviewed continuously?