Why do vendor risk assessments fail when offboarding is not built in from the start?

Why This Matters for Security Teams

vendor risk assessment often focus on what access is needed to start work, then treat offboarding as a separate administrative step. That split is where exposure persists. If revocation steps, ownership, and evidence requirements are not defined up front, a vendor can leave behind active credentials, unresolved permissions, or shared tokens that outlive the engagement. That is a lifecycle failure, not just a process gap. The NHI Lifecycle Management Guide and the NIST Cybersecurity Framework 2.0 both reinforce that identity governance must include deprovisioning as part of the control design, not as cleanup.

This matters because offboarding is where many organisations discover they cannot prove who still has access, where secrets were duplicated, or which system owner must revoke them. NHIMG research has repeatedly shown that lifecycle breakdowns are common, and that is consistent with the broader pattern described in the Top 10 NHI Issues. In practice, many security teams encounter stale vendor access only after a relationship has already ended and no one can confidently say who should have removed it.

How It Works in Practice

Strong vendor assessments treat onboarding and offboarding as one control surface. The assessment should ask not only what access a vendor receives, but how that access is time-bounded, who owns revocation, what evidence proves completion, and how secrets are handled when the contract ends. Current guidance suggests building this into the workflow before approval so that access cannot be granted without a matching exit path.

Practitioners typically reduce failure by defining three things at intake:

• Ownership: a named internal approver for each vendor identity, token, API key, certificate, or shared account.
• Revocation trigger: contract end, scope change, inactivity, incident response, or supplier substitution.
• Verification: logs, ticket closure, vault audit, and access review evidence that proves removal.

That operational model aligns with the NHI Lifecycle Management Guide, which frames identity and secret retirement as part of the identity lifecycle rather than an optional aftercare task. It also fits NIST Cybersecurity Framework 2.0 principles around access governance, continuous monitoring, and controlled asset disposition. One relevant NHIMG data point is that 91% of former employee tokens remain active after offboarding, which illustrates how easily revocation falls through the cracks when lifecycle controls are not engineered from day one.

The practical test is simple: if a vendor leaves tomorrow, the organisation should already know which systems are touched, which secrets must be rotated, and which team must certify closure. These controls tend to break down when access is embedded across multiple teams and no single owner can execute revocation across identity providers, vaults, SaaS tools, and source code repositories.

Common Variations and Edge Cases

Tighter offboarding controls often increase contract, operational, and review overhead, so organisations must balance speed of onboarding against the cost of proving clean removal later. That tradeoff is especially visible with small vendors, temporary consultants, and managed service providers that rely on shared administrative accounts or long-lived integrations.

There is no universal standard for this yet, but best practice is evolving toward explicit exit criteria for every vendor class. For low-risk access, an automated expiry date and standard revoke workflow may be enough. For high-risk vendors, the assessment should require secret rotation, session termination, certificate reissuance, and confirmation that any duplicated credentials have been removed from tickets, chat, and code. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it emphasises that lifecycle controls must be designed around the full identity journey, not just the initial grant.

Edge cases often appear in multi-tenant environments, emergency support relationships, and integrations where the vendor never logs in directly but still retains API access. In those situations, offboarding can fail if the organisation assumes “no user account” means “no residual access.” That assumption breaks down when secrets are embedded in CI/CD pipelines, shared vaults, or delegated service connections, because the access path outlives the human relationship.

Related resources from NHI Mgmt Group

• Why do asset inventories fail to reduce access risk on their own?
• Why does offboarding remain a risk even when access revocation is automated?
• Why does offboarding fail even when a directory shows the account is disabled?
• Why do automated onboarding and offboarding flows create IAM risk?