How should organisations handle vendor and machine account offboarding?

Why Offboarding Has to Be Treated as an Access-Control Event

Vendor and machine account offboarding should be run as a controlled revocation process, not an administrative closeout. The practical question is whether the account, token, certificate, or key can still authenticate anywhere after the business relationship ends. If it can, the offboarding process is incomplete even if the contract is closed or the asset is “no longer in use.”

That framing matters because third-party and workload accounts often outlive the people who created them, especially when they are embedded in automation, deployment tooling, or partner integrations. A clean offboarding decision therefore depends on ownership, inventory, and a confirmed revocation path, not just on who requested the termination.

For readers working through identity lifecycle management, NHIMG’s NHI Lifecycle Management Guide is the most direct place to anchor provisioning, rotation, and offboarding as one continuous control process, while the Joiner-Mover-Leaver (JML) Guide shows how leaver handling should remove tokens, keys, and agents as part of the same lifecycle.

What Must Be Revoked, and How Do You Prove It?

The offboarding step should cover every identity-bearing artifact tied to the vendor or machine account: active sessions, long-lived secrets, API keys, SSH keys, certificates, refresh tokens, service credentials, and delegated access paths. In practice, the account itself is only one part of the revocation surface. If any credential can still be replayed, or if a downstream integration still trusts the old identity, the exposure remains.

A sound process also distinguishes between disabling a login path and removing the underlying trust relationship. For machines, that usually means revoking the credential at the issuing source, removing the account from application allowlists, rotating shared secrets that were exposed to that account, and confirming that scheduled jobs, pipelines, and service-to-service calls fail closed rather than silently continuing.

Internal identity governance guidance is useful here because it reinforces two hard requirements: an owner for every account and a documented offboarding path. NHIMG’s IAM and IGA Basics covers entitlement governance and machine identities, and the NHI Ownership and Accountability Guide addresses the problem of ownerless identities that survive after a contract or project ends.

What Good Offboarding Looks Like in Practice

Good offboarding is evidence-driven. The organisation should be able to show when the vendor relationship ended, who approved revocation, which credentials were invalidated, and how it verified that the account could no longer authenticate. For machine accounts, that evidence should include a test that the old credential no longer works and that any surviving access path has been removed from the target systems, not just from the identity platform.

The strongest pattern is to treat offboarding as a sequence: identify the account and all dependent systems, revoke or expire credentials, remove authorization grants, confirm no active sessions remain, and then monitor for failed authentication attempts that indicate residual trust. That is especially important for third-party access, where lingering connectivity can become an overlooked re-entry path long after the business need has ended.

For a deeper look at the control model behind those steps, the Top 10 NHI Issues highlights offboarding, ownership, and excessive permissions as recurring failure modes, while the Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs ties those concerns together in a lifecycle view.

Risk and Threat Considerations

Residual vendor and machine access is a common source of preventable exposure because the original business need disappears before the authentication path does. That creates a standing trust relationship that an insider, a former partner, or an attacker who obtains the credential can continue to use.

Failure mechanism: Offboarding fails when the organisation disables a user interface or contract but leaves a valid token, certificate, key, session, or delegated permission in place. In some cases the account is “deleted” in one system while still trusted by another system, which preserves authentication and downstream access.

Impact: The result can be unauthorized persistence, lateral movement, data access, or abuse of automation and integrations that were never designed for manual review. Credential revocation failures can also complicate incident response because teams may mistake an ended relationship for an ended trust path.

Industry standards and breach evidence both reinforce this risk pattern. The PCI DSS v4.0 requirement set is especially relevant where business-need access and system account handling must be provable, and the supplied breach references show how unrevoked service credentials and machine accounts can remain exploitable after the original event.

For external grounding, see PCI DSS v4.0 for access-by-business-need expectations, and RFC 6749: The OAuth 2.0 Authorization Framework where machine-to-machine credentials are used and therefore must be revoked as part of offboarding.

Practitioner Guidance

What to verify: Do not accept “account disabled” as the endpoint. Verify that the credential issuer, the target application, and any downstream trust store all reject the old identity, and confirm that the offboarded account has no remaining service links, scheduled jobs, or shared secrets.

Decision rule: If the identity can still authenticate to a production system, treat the offboarding as incomplete, even if the vendor relationship has ended and the ticket is closed. Prioritise revocation and blast-radius reduction before administrative cleanup.

Common mistake: Teams often rotate only the obvious password or API key and miss refresh tokens, certificates, embedded secrets, and automation runners that were authenticated through the same account. That is how “offboarded” access survives in practice.

Practitioner takeaway: Offboarding is only complete when the old identity has no remaining way to prove itself anywhere in the environment, and the organisation can prove that with a test, not just a process note.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• How do organisations operationalise NHI ownership at scale?
• How should security teams handle risks from AI browser extensions?
• When should organisations treat an NHI as a high-priority risk?