Who should be accountable for privileged access when vendors and admins both use it?

Accountability should sit with the identity owner, the system owner, and the access governance process together. Vendor access needs a named business sponsor, a technical approver, and a revocation trigger at contract end. Without that chain, privileged access can outlive the relationship that justified it.

Why This Matters for Security Teams

When vendors and internal admins both touch privileged access, accountability often becomes fragmented across procurement, IT, security, and operations. That is a governance failure, not just an IAM issue. The practical risk is that no single party owns the full lifecycle: who approved access, why it exists, when it expires, and who must revoke it if the business relationship changes. Without that chain, privilege becomes durable by default.

For non-human and shared privileged access, the problem is magnified because access often outlives the original justification. NHIMG’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which makes vendor accountability a supply chain issue as much as an access issue. The right model assigns an identity owner, a system owner, and an approver who can actually remove access when the contract, ticket, or operational need ends. Current guidance also aligns with the OWASP Non-Human Identity Top 10, which treats unmanaged secrets and weak lifecycle control as core risk drivers.

In practice, many security teams discover shared privileged access only after a vendor offboarding or incident review has already exposed the missing revocation path.

How It Works in Practice

Accountability should be mapped to the control plane, not the convenience of the request. The business sponsor owns the need for access, the system owner owns the target environment, and the access governance process enforces approvals, expiration, and removal. For privileged vendor access, best practice is evolving toward explicit time bounds, named justification, and a revocation trigger tied to contract end, ticket closure, or change in scope.

Operationally, this works best when access is issued through privileged access management, recorded with an auditable owner, and reviewed on a schedule that matches the risk of the system. If the access is for an NHI, the same logic applies even more strictly: the access path should be tied to a workload or service owner, not a generic vendor mailbox or a shared admin group. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how excessive privilege and weak offboarding remain common, which is why the owner chain must be enforceable, not symbolic.

• Require one named business sponsor who accepts the risk and the business necessity.
• Require one technical owner who can validate scope and remove access quickly.
• Set an explicit end date or event-based expiry for every vendor privilege grant.
• Separate approval from execution so revocation does not depend on the original approver being available.
• Log the identity owner, approver, and revocation trigger in the same system of record.

Where program owners have adopted NIST SP 800-207 Zero Trust Architecture principles, the strongest pattern is to treat privileged access as continuously validated and narrowly scoped rather than permanently trusted. These controls tend to break down in environments with shared admin credentials, informal vendor support contracts, or unmanaged break-glass access because no single owner can prove when access should end.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations must balance accountability clarity against support speed and administrative friction. That tradeoff is real, especially where vendors need emergency access or where multiple internal teams share the same platform.

One common exception is break-glass access. Current guidance suggests this should still have an owner, but the approval path may differ from normal vendor access and should be documented separately. Another edge case is outsourced operations where the vendor performs daily administration. In that model, the business sponsor still retains accountability for the risk, even if the vendor executes the task. No universal standard exists for exactly how to split accountability in every outsourcing arrangement, but the principle remains the same: someone internal must own the decision to grant and renew access.

NHIMG research also shows why this discipline matters. The Ultimate Guide to NHIs reports that only 20% of organisations have formal offboarding processes for API keys, and 91.6% of secrets remain valid five days after notification. That pattern is consistent with weak ownership, not weak intent. Where vendor access is tied to shared accounts, long-lived secrets, or loosely defined support contracts, accountability often becomes impossible to enforce after the fact.

For that reason, organisations should prefer named ownership, short-lived access, and revocation tied to an auditable event. If the access cannot be assigned, reviewed, and revoked by a specific internal owner, it is already too broad.

Related resources from NHI Mgmt Group

• Who should be accountable for revoking shared credential access?
• Who is accountable when configuration drift causes an access failure or breach?
• How should organisations govern privileged access in sovereign infrastructure programmes?
• How should security teams run access reviews for non-human identities?