Who is accountable when partner access is not revoked on time?

Why This Matters for Security Teams

When partner access stays active after a relationship ends, the failure is rarely technical first. It is usually a lifecycle ownership problem: who approved the access, who was expected to revoke it, and who can prove that it happened. That matters because partner identities often sit outside normal employee offboarding flows, yet they still connect to production systems, data stores, and administrative interfaces.

NHI Management Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which is why partner access becomes stale so often. The issue is not just lingering credentials. It is the control gap between contract termination, access review, and evidence retention, which makes accountability hard to assign after the fact. Current guidance from the OWASP Non-Human Identity Top 10 and Ultimate Guide to NHIs both point to lifecycle governance as the real control point.

In practice, many security teams discover the ownership gap only after a partner relationship has already ended and the access review trail is incomplete, rather than through a clean offboarding process.

How It Works in Practice

Accountability should be mapped to the business owner of the partner relationship, with execution split across identity governance, application owners, and the teams that operate the target system. That means the business owner defines when access must end, the access governance process enforces the revocation trigger, and the system owner confirms that credentials, roles, tokens, and integrations are actually removed. The former partner user is not the control owner; at most, they are the subject of the access.

A sound process uses a lifecycle model, not ad hoc reminders. The NHI Lifecycle Management Guide emphasises that onboarding, review, rotation, suspension, and offboarding should be linked to business events such as contract expiration, vendor termination, or scope change. In practice, teams should treat revocation as a triggered workflow with evidence, not a manual task hidden in a ticket queue.

• Assign a named owner for the relationship, the application, and the identity record.
• Link contract end dates to access review and automatic revocation where possible.
• Separate approval from execution so no single person can “assume it was handled.”
• Keep immutable evidence of revocation timestamps, approvers, and system confirmations.
• Use periodic reconciliations to catch orphaned accounts and long-lived secrets.

Where organisations manage secrets and partner integrations, the same principle applies: short-lived access is easier to prove and easier to revoke than standing credentials. The Guide to the Secret Sprawl Challenge shows why stale tokens and embedded credentials often outlive the relationship that created them, while the Static vs Dynamic Secrets section explains why dynamic issuance reduces revocation ambiguity. These controls tend to break down when partner access is embedded in shared admin accounts or unmanaged integrations because there is no reliable system of record for who owns the revocation step.

Common Variations and Edge Cases

Tighter revocation controls often increase coordination overhead, requiring organisations to balance speed of deprovisioning against contract complexity, business continuity, and evidence requirements. The hard cases are usually not simple partner logins. They involve shared service accounts, embedded API keys, outsourced operations, or access that spans multiple subsidiaries and environments. In those cases, current guidance suggests the accountability model must include both the business relationship owner and the technical custodian, because either one alone can leave a gap.

There is no universal standard for this yet, but the direction is clear: account ownership should be explicit, revocation should be time-bound, and exceptions should be risk-accepted rather than ignored. The Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce the same pattern: access usually persists because nobody owns the final mile of removal. Where partner access is delegated through third parties, accountability can also extend to the organisation that approved the delegation, but that does not remove the primary obligation of the system owner to verify revocation.

In regulated environments, audit teams should expect to see a clear trail from business termination to access closure. If that trail depends on informal email confirmation, the control has already failed.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• Who is accountable when SaaS access is not revoked on time?
• Who is accountable when temporary elevated access is not revoked on time?
• Who is accountable when vendor privileged access is not revoked on time?