Who is accountable when vendor privileged access is not revoked on time?

The organisation that granted the access remains accountable, even if the vendor held the credential. PAM governance has to include explicit onboarding, access limits, and offboarding evidence for external identities. If contractor access survives the relationship, the failure sits in lifecycle governance, not in the vendor’s behaviour alone.

Why This Matters for Security Teams

When vendor privileged access is not revoked on time, the exposure is rarely limited to a single missed ticket. It becomes a governance failure across procurement, PAM, joiner-mover-leaver workflow, and third-party risk management. The organisation that granted the access remains accountable, because vendor behaviour does not override the duty to constrain, monitor, and remove privilege. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a useful indicator of how often lifecycle control is missing, not just delayed.

This question matters because privileged vendor access often sits outside the same scrutiny applied to employees. Teams may assume the contract, the vendor, or the system owner will handle revocation, but accountability does not transfer with the credential. Current guidance from the OWASP Non-Human Identity Top 10 treats unmanaged credential lifecycle as a core identity risk, not an edge case. In practice, many security teams discover the access was never fully removed only after a vendor dispute, audit request, or incident review has already surfaced the gap.

How It Works in Practice

Accountability should be assigned to the business function that approved and provisioned the access, then reinforced through PAM ownership, identity governance, and vendor management controls. That means the access request should name an internal owner, define scope, set expiry, and require evidence of revocation at termination or contract change. If the access is privileged, the revocation workflow should be tied to the same control path that granted it, rather than left to a manual email exchange.

Practitioners usually implement this with a combination of role-based approvals and time-bound access. But for privileged third parties, static RBAC alone is weak because the credential can outlive the business need. Better practice is to pair RBAC with explicit expiry, ticket-linked approvals, and automated deprovisioning through the PAM platform. NHIMG’s NHI Lifecycle Management Guide and Lifecycle Processes for Managing NHIs both emphasise that lifecycle evidence matters as much as initial approval.

• Assign a named internal control owner for each vendor identity or shared privileged account.
• Set an expiry date at issuance and require renewal based on business justification.
• Use PAM to enforce checkout, session recording, and automatic credential revocation.
• Trigger offboarding from HR, procurement, or contract status changes, not only from vendor notice.
• Validate removal with logs, not just an attestation email.

Where possible, use short-lived secrets instead of long-lived static credentials, because TTL creates an enforced end state even when process discipline slips. The real failure mode appears when vendor access is embedded in legacy systems, shared administrator accounts, or environments with no automated deprovisioning path because manual revocation cannot keep up with contract churn and operational exceptions.

Common Variations and Edge Cases

Tighter vendor access control often increases operational overhead, requiring organisations to balance auditability against service continuity. That tradeoff becomes more visible in emergency support arrangements, managed service provider access, and shared break-glass accounts, where immediate access is necessary but still must be constrained. There is no universal standard for every exception yet, but current guidance suggests the exception process should be more tightly governed than the normal path, not less.

A common edge case is when the vendor no longer has contract authority but their credential still works in a downstream system. In that situation, accountability usually sits with the internal owner of the system of record, the PAM administrator, and the procurement or vendor management process that failed to close the loop. Another recurring issue is third-party access embedded in automation. Those secrets are often treated as operational plumbing, but if they are not rotated or revoked at the end of service, they become standing privilege by another name. NHIMG’s Guide to the Secret Sprawl Challenge is especially relevant here.

For evidence-based control design, organisations should also review the Top 10 NHI Issues alongside the OWASP guidance. The practical rule is simple: if the organisation created the access path, it owns the revocation path. These controls tend to break down when vendor access is shared across teams and no single owner is accountable for closing it.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access controls do not meet Part 500 expectations?
• Who is accountable when privileged access causes a production incident?
• Who is accountable when a vendor or partner uses remote administrative access?
• Who is accountable when revoked access is not removed after certification?