Who is accountable when third-party access persists beyond its intended purpose?

Why This Matters for Security Teams

When third-party access outlives the business purpose that justified it, the risk is not just “vendor sprawl.” It is an account that still has effective authority after the control assumption changed. The organisation that approved the access, defined the scope, and owned the exception remains accountable for what that identity can still do, even if the vendor still holds the credentials.

That is why lifecycle governance matters as much as initial approval. NHIMG’s Ultimate Guide to NHIs shows that 92% of organisations expose NHIs to third parties, which turns expired relationships into an ordinary attack path rather than an edge case. OWASP’s OWASP Non-Human Identity Top 10 treats weak lifecycle control as a core failure mode because privileged machine access is often left active long after business ownership has shifted.

In practice, many security teams discover stale third-party access only after a contract ends, a supplier is offboarded, or an audit flags an account that nobody can clearly own.

How It Works in Practice

Accountability starts with treating third-party access as a governed identity lifecycle, not a one-time procurement decision. The business owner, security team, and system owner should each have explicit responsibilities for approval, recertification, expiry, and revocation. If access is granted for a project, incident response engagement, integration test, or managed service, the access record should carry a purpose, owner, start date, and forced end date.

Good practice is to use time-bound access where possible, with just-in-time elevation for privileged functions and automatic revocation when the task ends. For non-human identities, this usually means short-lived tokens, scoped API keys, or workload credentials that can be expired without waiting for a manual ticket. The identity primitive should be the workload or service account, not a person’s mailbox or a permanent shared login. This is consistent with the operational direction in Ultimate Guide to NHIs — Key Challenges and Risks, which emphasises visibility, rotation, and offboarding as baseline controls.

• Define the access purpose and the accountable internal owner before the vendor path is enabled.
• Bind each third-party identity to a review cadence and expiry date, not an open-ended exception.
• Log every privileged action so recertification is based on actual use, not assumptions.
• Revoke secrets, keys, certificates, and delegated tokens when the relationship changes, not at the next annual review.

Frameworks such as NIST SP 800-207 Zero Trust Architecture support this model by assuming access must be continuously verified, while CISA Zero Trust guidance reinforces ongoing validation rather than permanent trust. These controls tend to break down when vendors share generic accounts across multiple clients because ownership, revocation, and action-level attribution become impossible to separate cleanly.

Common Variations and Edge Cases

Tighter third-party access control often increases operational overhead, so organisations have to balance fast onboarding against stronger expiry and review discipline. That tradeoff becomes sharper in managed services, emergency support, and integration-heavy environments where teams are tempted to keep access “just in case.” Current guidance suggests that open-ended access should be the exception, but there is no universal standard for every vendor relationship model yet.

One common edge case is indirect access through a contractor’s own automation, where the human relationship ends but the service account remains active. Another is delegated access embedded in CI/CD pipelines or support tooling, where the original business purpose is obscured by technical reuse. In those cases, the accountable organisation must still verify who approved the path, who can use it, and what event will trigger revocation. NHIMG’s 52 NHI Breaches Analysis is a useful reminder that stale machine access is rarely harmless just because it was “meant for a partner.” The practical standard is simple: if no one can explain why the third-party access still exists, the access model is already out of policy.

Related resources from NHI Mgmt Group

• Who is accountable when third-party access to personal data persists too long?
• Who is accountable for third-party access that outlives its intended use?
• Who is accountable when third-party remote access is overused in public safety environments?
• Who is accountable for third-party access after a campaign or project ends?