Vendor offboarding is an identity governance problem, not admin cleanup

At a glance

What this is: This is a vendor offboarding checklist that frames termination as an identity and access governance problem, with access revocation as the critical control.

Why it matters: It matters because third-party access spans NHI, human, and physical touchpoints, so weak offboarding can leave hidden privilege behind in IAM, SaaS, and compliance workflows.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Zluri's vendor offboarding checklist for access removal and lifecycle control

Context

Vendor offboarding is the point where a third party should stop acting as an extension of your identity surface. In practice, the hard part is not closing the contract, but making sure access, data copies, devices, and application entitlements are actually removed across every system the vendor touched.

That is why offboarding belongs in IAM and lifecycle governance, not only in procurement or legal checklists. If organisations cannot reliably track what a vendor could access, they cannot prove that access was revoked when the relationship ended. The result is residual access that outlives the business relationship.

For teams building a broader programme, the same lifecycle issue appears in service accounts, SaaS users, and privileged accounts. The control problem is consistent even when the identity subject changes, which is why lifecycle discipline must cover every actor type.

Key questions

Q: What breaks when vendor offboarding is treated as paperwork instead of lifecycle governance?

A: Access remains active after the contract ends, which means the vendor can still reach systems, data, or devices that should have been removed. The organisation also loses auditability because no one can prove that revocation happened across every system. That creates both security exposure and compliance risk.

Q: Why do third-party vendors create more offboarding risk than many internal users?

A: Vendors often touch multiple systems for a short period, which makes their access harder to track and easier to forget at exit. They may also retain data copies, device access, or shared SaaS entitlements outside normal employee lifecycle processes. The longer the offboarding gap, the larger the residual exposure.

Q: How do teams know whether vendor offboarding is actually working?

A: They should be able to show a complete list of vendor entitlements, evidence that each one was revoked, proof that devices were returned, and records that data deletion or retention decisions were approved. If any of those artefacts are missing, offboarding is not under control.

Q: Who is accountable when vendor access is left behind after termination?

A: Accountability should sit across security, legal, finance, and the system owners who granted the access in the first place. Offboarding is cross-functional because it spans access removal, contract closure, payment settlement, and compliance evidence. If ownership is unclear, residual access usually survives the process.

Technical breakdown

Vendor offboarding as lifecycle deprovisioning

Offboarding is a deprovisioning problem because the organisation must remove every form of access the vendor accumulated during the relationship. That includes SaaS entitlements, VPN access, application accounts, API access, device access, and any residual data copies. The control failure usually starts earlier than termination, when access is granted without a complete inventory of where it lives. If the environment lacks a central record of vendor entitlements, offboarding becomes a manual hunt instead of a governed workflow.

Practical implication: maintain an authoritative vendor access inventory before termination so revocation is complete, not partial.

Why data backup and deletion need separate controls

Backing up vendor-related data and deleting it from the vendor side are not the same action. A backup preserves organisational continuity, while deletion reduces the chance that the vendor retains post-contract access to sensitive information. The article also points to written consent for deletion, which is a governance control as much as a legal one because it creates evidence that data handling expectations were explicit. Without that separation, teams often keep copies for resilience but fail to remove the original exposure path.

Practical implication: separate retention, deletion, and evidence capture into distinct offboarding steps with named owners.

Third-party access revocation and compliance evidence

Vendor offboarding intersects with compliance because regulators care about whether access was removed, data was handled properly, and obligations were met after termination. The article’s focus on finance, security, and legal involvement shows that offboarding is cross-functional, not a single-team task. In operational terms, the control gap is usually not a missing termination event but missing proof that every access path, contract dependency, and device return was closed. That proof matters when a dispute, audit, or breach follows the termination.

Practical implication: require documented revocation evidence for each system, device, and contract term before closing the vendor record.

Threat narrative

Attacker objective: Maintain access to systems or data after vendor termination so the relationship outlives the controls meant to end it.

1. Entry occurs when a vendor is granted legitimate access to internal systems, SaaS tools, devices, and sensitive data as part of the contract. That access becomes the initial foothold if the relationship is not tightly inventoried.
2. Escalation happens when the contract ends but access remains active across applications, physical assets, or stored data. At that point, the vendor can continue to reach information that should have been removed at offboarding.
3. Impact is the possibility of data misuse, compliance failure, reputational damage, and unnecessary license exposure after the business relationship has ended. The objective is continued access beyond the authorised lifecycle.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vendor offboarding is lifecycle governance, not contract administration. The article describes a familiar failure pattern: organisations close the commercial relationship but leave the identity relationship unfinished. That gap spans SaaS access, device return, data deletion, and legal evidence, which means offboarding has to be governed as a full lifecycle event. Practitioners should treat vendor termination as a controlled deprovisioning process, not an administrative afterthought.

Residual third-party access is a standing privilege problem with a different name. The same control weakness appears whether the identity is a vendor user, a service account, or a privileged admin. Once access persists beyond the business need, the organisation loses the ability to explain why that access still exists. The practical consequence is not just exposure, but weak accountability across procurement, security, and legal teams.

Centralised vendor visibility is the named concept this article points to. Without a central record of every vendor account, entitlement, device, and data location, offboarding becomes guesswork. That is a governance failure, not a tooling inconvenience, because no team can revoke what it cannot see. The implication is that vendor lifecycle programmes must begin with inventory discipline, not termination scripts.

Security and compliance fail together when offboarding is fragmented. The article correctly ties access removal to compliance obligations such as GDPR and CCPA because the same missing proof causes both operational risk and audit risk. If one team deletes data while another retains access records, the organisation can still be exposed. Practitioners should understand that offboarding control quality is measured by evidence, not intent.

Automated offboarding only works when the underlying identity model is complete. The article’s automation pitch is directionally right, but automation cannot compensate for incomplete discovery. If the vendor list, app inventory, or device register is wrong, the workflow simply accelerates the wrong outcome. The practitioner takeaway is to fix identity coverage first, then automate revocation and validation.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly revocation can lag behind exposure in practice.
• For a broader lifecycle lens, review NHI Lifecycle Management Guide for the provisioning, rotation, and offboarding controls that reduce residual access risk.

What this signals

Centralised visibility will become the dividing line between defensible and informal vendor offboarding. As organisations continue to spread access across SaaS, devices, and external collaborators, the ability to prove what was removed will matter more than the intent to remove it. Teams that already maintain a single inventory of identities and entitlements will close faster and audit cleaner. The practical signal is to align vendor offboarding with the same governance discipline used for lifecycle processes for managing NHIs.

The next maturity step is to connect offboarding evidence to broader identity controls such as access reviews, entitlement reconciliation, and device recovery. That gives security, legal, and procurement a shared record instead of three partial versions of the truth. In NHIMG terms, lifecycle governance is only effective when the organisation can see the full identity surface before it tries to shrink it.

Standing access will keep reappearing until offboarding is tied to account closure, not just contract closure. The programme implication is that identity teams will need tighter linkage between vendor records, entitlement systems, and revocation workflows. Where that linkage is missing, residual privilege becomes a recurring operational debt rather than a one-time mistake.

For practitioners

• Build a complete vendor access inventory Map every SaaS app, VPN, internal system, device, and physical access point a vendor can touch before offboarding begins. A central inventory is the only reliable way to prove that revocation was complete.
• Separate data retention from data deletion Decide which vendor-related data must be retained, which must be deleted, and who signs off on each action. Capture written consent or equivalent evidence so deletion is auditable.
• Require cross-functional offboarding ownership Assign finance, security, legal, and system owners clear tasks for settlement, entitlement removal, contract closure, and compliance evidence. Offboarding fails when revocation is treated as one team’s job.
• Document every revocation and device return Record which systems were reviewed, when access was removed, and which devices were recovered, including missing parts or unresolved exceptions. If it is not documented, it is not defensible in an audit.

Key takeaways

• Vendor offboarding is an identity lifecycle control, not a paperwork exercise, because access that survives termination becomes residual privilege.
• The scale of the risk is visible in lifecycle data, including the fact that 91% of former employee tokens remain active after offboarding.
• The control that matters most is provable revocation across systems, devices, and data locations, backed by clear ownership and evidence.

Key terms

• Vendor Offboarding: The controlled process of ending a third party’s access to systems, data, devices, and contracts when the business relationship ends. In identity terms, it is deprovisioning across every place the vendor touched, with evidence that access was actually removed.
• Residual Access: Access that remains active after the business need has ended. It is a lifecycle failure, not just an administrative oversight, because the identity can still reach resources that should have been closed, revoked, or destroyed.
• Lifecycle Governance: The set of controls that manage identities from onboarding through active use and offboarding. For vendors, it includes inventory, approval, review, revocation, data handling, and proof that the identity surface has been reduced.
• Entitlement Inventory: A complete record of what a user, vendor, service, or device can access across applications and environments. Without it, offboarding becomes guesswork because teams cannot reliably revoke what they cannot see.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Vendor Management 4-Step Vendor Offboarding Checklist. Read the original.