Who is accountable when vendor access remains active after a banking engagement ends?

Why This Matters for Security Teams

When vendor access stays active after a banking engagement ends, the failure is not just technical. It is an ownership gap across procurement, business sponsorship, system administration, and identity governance. The lingering account becomes a non-human identity with continuing access to sensitive data, shared tools, or privileged workflows. That is why current guidance treats offboarding as a control, not an admin task.

For practitioners, the question is who can prove that access ended when the business relationship ended. The business owner defines the end of need, the system owner confirms where access exists, and the identity process enforces revocation and evidence capture. This is consistent with the broader NHI risk picture described in the Ultimate Guide to NHIs and the control failures analysed in 52 NHI Breaches Analysis.

OWASP’s OWASP Non-Human Identity Top 10 reinforces that standing credentials and weak lifecycle control are recurring exposure points. In practice, many security teams discover vendor access only after a contract has closed, an audit has started, or a fraud review has already exposed the stale account.

How It Works in Practice

Accountability should be assigned at three layers. First, the business owner owns the decision that the vendor no longer needs access. Second, the system owner owns the technical inventory of where that access exists, including direct accounts, API keys, service principals, PAM checkouts, and shared credentials. Third, identity governance owns the control that removes access, validates completion, and retains evidence.

A workable offboarding process usually includes:

• contract termination or scope completion triggers the access review
• all vendor entitlements are mapped to named systems, secrets, and shared workflows
• JIT access is revoked and any long-lived secrets are rotated or disabled
• logs, approvals, and revocation timestamps are retained for audit

This is where NHI discipline matters. The Ultimate Guide to NHIs — Key Challenges and Risks and the Ultimate Guide to NHIs — The NHI Market both point to the same operational issue: entitlements outlive their intended business use unless there is explicit lifecycle ownership. OWASP guidance also supports treating these identities as high-risk assets that require inventory, least privilege, and revocation discipline, not informal cleanup.

For banking environments, the most important practical control is a closeout gate that blocks engagement completion until access removal is verified across cloud consoles, file shares, data rooms, ticketing systems, and any machine-to-machine credentials issued to the vendor. These controls tend to break down when vendors are embedded across multiple business units because no single owner has a complete access map.

Common Variations and Edge Cases

Tighter offboarding often increases coordination overhead, requiring organisations to balance speed of contract closure against the cost of full entitlement tracing. That tradeoff is unavoidable in complex banking engagements, especially where vendors use delegated admin rights, break-glass procedures, or shared automation tokens.

There is no universal standard for this yet, but current guidance suggests the same accountability model should still apply when access is indirect. If a vendor used a managed service account, the system owner still owns revocation. If the vendor accessed data through a platform token, identity governance still owns the lifecycle. If the vendor is replaced by another supplier, the new contract does not reset the old access review.

Two edge cases matter most. First, if the vendor performed a one-time task but retained a reusable secret, the organisation must treat the secret as an active identity until it is rotated. Second, if evidence is missing, the issue is not only access exposure but also control failure, because there is no proof that offboarding occurred. In risk terms, that means accountability sits with the named control owner, but remediation often spans procurement, security operations, and the business sponsor. The practical lesson is simple: access removal must be tied to the end of authority, not the end of inconvenience.

Related resources from NHI Mgmt Group

• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a third-party integration keeps an NHI active after the business need ends?
• Who is accountable when a workload secret remains active after compromise?
• Who is accountable for third-party access when a vendor relationship ends?