Who is accountable when a third-party risk control fails to revoke access?

Why This Matters for Security Teams

When a third-party control fails to revoke access, the issue is not just delayed cleanup. It exposes a governance gap across procurement, identity, and operational security. In NHI programs, stale access is often how vendors, scripts, service accounts, and integrations retain reach long after the business reason has ended. That is why NHI governance has to be lifecycle-based, not ticket-based, as outlined in the NHI Lifecycle Management Guide and the Top 10 NHI Issues. The accountability question also maps to broader control expectations in NIST Cybersecurity Framework 2.0, where access governance, asset ownership, and monitoring should be coordinated rather than treated as isolated tasks. If the vendor owns the tool, security owns the policy, and operations owns the approval, the revoke step can fall between all three. That is why a named control owner matters more than a generic process owner. In practice, many security teams only discover this gap after a contract ends and the old access path is still active.

How It Works in Practice

The practical answer is to assign one accountable owner for the access lifecycle, then make every other party a participant with defined handoff points. That owner should verify three things: who approved the access, what third party received it, and what event triggers revocation. Current guidance suggests tying this to contract milestones, not just HR-style joiner-mover-leaver workflows, because third-party access rarely follows employee patterns. A workable model usually includes:

• contract owner: confirms the business relationship and termination date
• control owner: triggers revocation when risk or scope changes
• platform owner: removes the entitlement in IAM, PAM, or the target system
• verifier: checks that access is actually gone, not merely marked closed

This is where the NHI angle becomes important. Secrets, API keys, service accounts, and vendor integrations can persist outside normal user review cycles, which is why the 52 NHI Breaches Analysis is so relevant to lifecycle failures. OWASP’s OWASP Non-Human Identity Top 10 also reflects the same pattern: non-human access is often overextended, under-reviewed, and weakly owned. Best practice is evolving toward explicit ownership, automated expiry, and proof of removal, rather than relying on a single revocation request in a service desk. These controls tend to break down when vendor access is embedded in shared admin accounts or long-lived API keys because there is no reliable one-to-one record of who can actually remove what.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, so organisations have to balance speed of third-party onboarding against the cost of stronger ownership and verification. That tradeoff becomes sharper when access is shared across multiple vendors, subcontractors, or managed service providers. In those cases, the direct contract holder may not be the same party that technically administers the account, so accountability needs to be stated in the operating procedure and the contract, not inferred later. There is no universal standard for this yet, but the emerging pattern is to treat third-party access like an NHI with a defined owner, expiry, and review cadence. The Ultimate Guide to NHIs — Key Challenges and Risks and Guide to the Secret Sprawl Challenge both reinforce the same point: if access sprawl is not monitored, revocation becomes unreliable. NIST’s guidance on governance in NIST Cybersecurity Framework 2.0 supports this by pushing organisations to define responsibility, verify control performance, and learn from failures. In edge cases, such as emergency vendor support or regulatory hold periods, access may remain temporarily active, but that exception still needs a named approver and a documented end date. Best practice is to treat any exception as time-boxed, reviewed, and separately risk-accepted rather than as an open-ended approval.

Related resources from NHI Mgmt Group

• Who should own third-party access risk in a banking GRC programme?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a user grants a risky third-party app access?
• How do security teams know if third-party app access is out of control?