Who is accountable when a vendor account is over-permissioned or not revoked after offboarding?

Why This Matters for Security Teams

Vendor accounts are not low-stakes exceptions. Once an external party is granted access, that account becomes part of the organisation’s identity attack surface and must be governed like any other privileged non-human identity. The accountability problem is usually not about who clicked the button, but about who owned the approval, review, and revocation process across security, IAM, procurement, and the business sponsor.

When a vendor account is over-permissioned, the risk is often cumulative: access expands for a project, then remains in place after scope changes, contract renewals, or personnel turnover. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why entitlement drift becomes a repeat failure pattern rather than a one-time mistake.

Security teams should treat this as a governance gap, not a vendor-only problem. The baseline expectation in OWASP Non-Human Identity Top 10 is that non-human access must be scoped, reviewed, and retired with the same discipline as any other privileged identity. In practice, many security teams encounter over-permissioned vendor access only after a contract has ended or a misuse alert has already fired, rather than through intentional offboarding controls.

How It Works in Practice

Clear accountability starts with assigning a business owner for the vendor relationship, an IAM or security owner for access administration, and a control owner for periodic review. The vendor may operate the account, but the organisation still owns the risk created by granting access. That means approval should be based on least privilege, access should be time-bound where possible, and revocation should be triggered by contract end, scope change, or inactivity.

In operational terms, this usually requires three mechanisms working together:

• Pre-approval with documented business justification and data scope.
• Periodic revalidation of access against current need, not original need.
• Automated offboarding that removes entitlements, secrets, API keys, and session access at exit.

This is where identity governance and NHI lifecycle controls overlap. NHIMG’s NHI Lifecycle Management Guide and Top 10 NHI Issues both reinforce the same operational lesson: access that is not continuously revalidated will outlive the vendor relationship. In parallel, NIST SP 800-53 Rev 5 Security and Privacy Controls supports disciplined access review, separation of duties, and account management controls that can be mapped directly to vendor offboarding.

Contracts should specify who notifies whom, how quickly access must be removed, what evidence is required for closure, and what happens if the vendor fails to respond. The organisation still needs an internal kill switch, because contractual language does not revoke an active credential. These controls tend to break down in multi-department procurement environments because no single team owns the full lifecycle from onboarding through termination.

Common Variations and Edge Cases

Tighter revocation controls often increase administrative overhead, requiring organisations to balance fast vendor onboarding against stronger assurance that access will not linger after offboarding. That tradeoff becomes sharper when vendors support production systems, shared platforms, or emergency support arrangements.

There is no universal standard for this yet, but current guidance suggests treating different vendor types differently. A break-glass support account may need stronger monitoring and shorter TTLs, while a low-risk reporting account may be reviewed less frequently but still require formal offboarding. The important point is that “vendor-owned” does not mean “vendor-governed.”

Two edge cases deserve special attention. First, shared vendor accounts make accountability harder because a departure may not map to a single person, so the account itself must be treated as high-risk and preferably eliminated. Second, delegated administrative access often survives contract changes because the business owner assumes IT or procurement will handle it. In reality, the risk remains with the organisation that granted access, and the accountability chain should be explicit in the access register and offboarding checklist.

For organisations with large third-party estates, lifecycle failures often surface alongside broader NHI hygiene issues described in NHIMG’s Guide to the Secret Sprawl Challenge and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. In practice, the hardest failures happen when vendor access is spread across SaaS apps, cloud consoles, and service tickets, because revocation must happen everywhere at once.

Related resources from NHI Mgmt Group

• Who is accountable when SaaS access is not revoked after offboarding?
• Who is accountable when a vendor account remains active after the work ends?
• Who is accountable when a service account or AI agent keeps access after offboarding?
• Who is accountable when a non-human identity is over-privileged or left active after offboarding?