Vendor offboarding is the coordinated process of removing a third party’s access, credentials, data, devices, integrations, and operational dependencies when a contract, project, individual assignment, or approved access window ends.
A secure process must cover both human and machine identities across IT, cloud, OT, and industrial environments—not just disable one user account.
This vendor offboarding checklist gives security, IT, procurement, legal, and operations teams a repeatable way to revoke access, preserve evidence, and verify that no usable pathway remains.
Vendor offboarding is the formal closure of a third-party relationship from an access and security perspective.
It applies when a supplier contract ends, a project closes, an individual leaves the vendor, a role changes, a maintenance window expires, or the organization suspends access because of risk.
Offboarding is broader than deactivating a directory account. A complete process also addresses:
The goal is simple: after the approved endpoint, the vendor should have no unauthorized way to reach systems, data, facilities, or operational assets.
The strongest vendor offboarding process begins before a contract ends.
Contracts, statements of work, access approvals, and maintenance schedules should define who sends the trigger, how quickly teams must act, what evidence is required, and who can approve an exception.
Use a central case or ticket as the system of record. It should link the business relationship to vendor personnel, approved roles, systems, credentials, devices, data, and operational dependencies.
| Trigger | Source System | Accountable Role |
|---|---|---|
| Contract or statement of work ends | Contract lifecycle management | Procurement or vendor owner |
| Project or maintenance window closes | Project or maintenance system | Project manager or maintenance owner |
| Vendor employee leaves or changes role | Vendor notification and identity governance | Vendor manager and identity owner |
| Access approval expires | Identity governance or access request system | Application or system owner |
| Privileged session window expires | Privileged access platform | Privileged access owner |
| Security incident or elevated risk | SIEM, incident response, or risk system | Incident commander or security owner |
| OT work order is completed | CMMS or OT change management | Plant or operations owner |
| Physical access is no longer required | Physical access control system | Facilities or site security |
| Data-processing purpose ends | Data inventory or privacy system | Data owner or privacy lead |
Urgent cases may require disabling access before notifying the vendor. Planned cases may require coordination with production changes, data handover, or safety procedures.
The playbook should support both scenarios without weakening approval and evidence requirements.
No universal 24-hour rule applies to every vendor and every system.
Set service-level targets based on:
For a high-risk or for-cause termination, organizations may need to disable access immediately and in a coordinated sequence.
For a planned contract end, teams can prepare the inventory and approvals in advance, then execute the revocation process at the agreed cutoff time.
The following timeline is a suggested operating model—not a requirement established by NIST, ISO, or another standard.
Suggested first-24-hours sequence. Adapt each target to organizational risk, safety, change-control, and contractual requirements.
Do not rely on a single identity directory.
Vendors often accumulate access through multiple systems and machine identities that aren't cleanly linked to a person.
Reconcile at least the following sources:
Compare the approved inventory with what is actually active.
Differences are findings to resolve, not reasons to stop the process. If you can't map an account or credential immediately, restrict or suspend it safely while you confirm ownership.
Disable human access at the control point that prevents downstream authentication, then remove it from local systems and groups as needed.
Terminate active sessions so a previously issued session remains unusable after the account is disabled.
For each person, verify that:
Machine access requires a separate sweep.
Service accounts, API keys, certificates, and embedded secrets may keep working even after you disable every named user.
For each machine identity, verify that:
Safous discusses the importance of governing both identity types in Why Identity Governance Needs to Include Human and Machine Users.
Disabling an identity does not always close every route.
Remove the access mechanisms that allowed the vendor to reach the environment and confirm that no unmanaged fallback remains.
Check:
Terminate active connections and validate the result from both the identity plane and the network plane.
If the vendor used a shared account or a credential embedded in an appliance, rotate it and update the approved internal owner.
Vendor access to OT, industrial control systems, and isolated or intermittently connected environments requires coordination with plant operations and safety teams.
Directly disabling an account or rotating a credential can interrupt maintenance, monitoring, or production if you don't understand the dependencies.
Use an OT-specific branch when access depends on jump hosts, maintenance tunnels, local credentials, engineering workstations, or approved change windows.
The OT runbook should include:
For a deeper treatment of third-party access in industrial environments, see Securing Third-Party Vendor Access in OT Environments.
Synchronize security closure with procurement, legal, privacy, records management, and business owners.
Access can be fully revoked while contractual or data-handling actions remain open, so track those actions separately until completion.
Confirm that:
Do not claim deletion based only on the loss of application access.
When deletion is required, obtain appropriate confirmation and understand whether backups, archives, logs, and legal holds are handled separately.
An audit-ready record should allow an independent reviewer to reconstruct what happened without relying on memory or screenshots alone.
Include:
Protect the evidence against unauthorized alteration and deletion.
Use tamper-evident or otherwise protected storage when required by risk, policy, contract, legal hold, or regulation. Retention periods should follow the organization’s approved schedule and applicable obligations; no single retention period applies to every vendor offboarding record.
NIST SP 800-171 Rev. 3 requires covered organizations to define account-management procedures and organization-defined time periods. Its personnel termination requirement addresses disabling access, revoking authenticators, and retrieving security-related property.
The publication applies specifically to systems that process, store, transmit, or protect Controlled Unclassified Information, so use it when relevant to your environment and obligations.
Organizations using ISO standards can map the workflow to applicable access-rights, supplier-relationship, asset-return, logging, and monitoring controls.
ISO/IEC 27036-2:2022 provides additional requirements for defining, operating, monitoring, reviewing, and improving supplier and acquirer relationships.
Completion is not the same as a successful ticket update.
Validate the result using independent data sources and continue monitoring for activity that should no longer occur.
Run these checks after execution:
Record who performed each validation, the data source used, the time covered, the result, and any follow-up action.
For more on evidence and accountability, read Auditability in Zero Trust: Ensuring Secure Remote Privileged Access.
Safous helps organizations control third-party and privileged remote access with identity-based policies, centralized access control, session monitoring and recording, and audit logs across hybrid IT and OT environments.
These capabilities can make vendor access easier to inventory, restrict, observe, revoke, and verify.
Safous complements—but does not replace—your identity governance, procurement, legal, data-management, safety, and offboarding processes.
The best results come from connecting the technical control plane to an approved vendor lifecycle and a clearly owned workflow.
Explore Safous Third-Party Access or download the Privileged Remote Access Guide to learn how to reduce standing access and improve accountability for remote vendor sessions.
Employee offboarding is usually triggered by an internal HR event.
Vendor offboarding may involve multiple supplier employees, subcontractors, shared or machine credentials, contracts, data-processing obligations, and access to customer or operational environments.
Procurement, vendor owners, legal, and OT operations often have a larger role.
Revoke access at the approved end time or sooner when risk requires it.
For-cause termination, suspected compromise, or excessive privilege may require immediate coordinated action. Prepare planned contract or project closures in advance and execute them at the documented cutoff time.
One accountable coordinator should own the case, but execution is cross-functional.
The vendor or business owner confirms the relationship change. Identity, application, cloud, network, physical-security, and OT owners revoke access. Procurement and legal close contractual actions, while data owners confirm data handling.
Remove or transfer all human and machine access that is no longer required, including:
Use an evidence package containing the trigger, scope, approvals, execution timestamps, closure reports, session and credential actions, asset and data records, exception handling, validation results, and final approval.
Verify the outcome against independent identity, network, cloud, application, and OT records.
Yes.
API keys, service accounts, certificates, tokens, and other machine identities can outlive a named user account.
Revoke, rotate, or transfer them to an approved owner and test dependencies to avoid both residual access and service interruption.
Vendor offboarding works when the organization can answer four questions:
Begin with privileged and remote access, then expand the same ownership, inventory, revocation, and validation model across applications, cloud services, machine identities, physical access, and OT.
A repeatable playbook turns vendor offboarding from a last-minute cleanup task into a measurable security control.
This article provides general security guidance and is not legal, regulatory, or compliance advice. Requirements and timelines vary by organization, contract, jurisdiction, system criticality, and risk.