Vendor onboarding is the control process for granting access safely, confirming who needs it, what they need it for, and how much privilege they should receive. Vendor offboarding is the removal process that revokes access when the relationship ends or the user changes roles. Both are necessary because unmanaged access creates different but equally serious security gaps.
How vendor onboarding differs from vendor offboarding
Vendor onboarding is the controlled start of a third-party relationship. The objective is to establish the business need, define what access is justified, and make sure the vendor enters with the minimum privileges required. Offboarding is the controlled end of that relationship, when access, credentials, integrations, and approvals must be withdrawn so the vendor no longer retains paths into your environment.
That difference matters because onboarding is mainly about safe enablement, while offboarding is about safe removal. In third-party risk management, both are lifecycle controls, but they protect against different failure modes: too much access at the start versus lingering access after the relationship should have ended.
Practitioners often treat them as mirror images, but they are not identical in practice. Onboarding is a gatekeeping and scoping exercise; offboarding is a revocation and cleanup exercise. The second is often harder because access may have been propagated into shared accounts, API connections, service credentials, or business workflows that are easy to forget once the relationship is no longer active.
Why onboarding and offboarding create different control problems
Onboarding asks whether the vendor should get access at all, what level of privilege is justified, and how that access will be monitored. It is the point where you define ownership, approval, scope, and accountability. Good onboarding reduces blast radius by ensuring the vendor only receives the specific access needed for a named purpose.
Offboarding asks whether every path created during the relationship has actually been removed. That includes user accounts, federation trust, tokens, keys, certificates, VPN paths, shared passwords, and embedded application connections. If onboarding sets the boundary, offboarding is the proof that the boundary was dismantled when it should have been.
This distinction is why lifecycle discipline matters more than one-time approval. A vendor can be correctly approved on day one and still become a security problem later if access is not removed when contracts expire, services change, or a supplier relationship ends.
What good vendor lifecycle control looks like in practice
Onboarding should be driven by least privilege, business justification, and explicit time bounds where possible. The practical question is not simply whether the vendor is trusted, but whether each requested access path is necessary, traceable, and reviewable. That is especially important when the vendor uses integration credentials or delegated access rather than a human login.
Offboarding should be triggered by contract end, scope change, role change, or termination of the service relationship, not by memory or informal handoff. Effective teams maintain an inventory of all vendor access paths and test revocation, because partial removal is a common failure. A vendor offboarding process is only complete when the access no longer works, not when a ticket says it was deleted.
For teams managing third-party access at scale, the practical difference is auditability. Onboarding should leave behind approvals and scope evidence; offboarding should leave behind revocation evidence, removal confirmation, and a record of any residual risk that had to be accepted temporarily.
Risk and Threat Considerations
The biggest risk is treating onboarding as the hard problem and offboarding as an administrative afterthought. Unremoved vendor access can persist long after the business relationship ends, creating an avoidable path for misuse, account abuse, or compromise through stale credentials and forgotten integrations.
Failure mechanism: Access granted during onboarding is replicated into accounts, tokens, API connections, and support workflows, then not fully revoked during offboarding. That leaves standing access that may no longer be monitored, owned, or justified.
Impact: The organisation keeps a third-party entry point open beyond the intended relationship window, increasing exposure to unauthorized access, data leakage, and downstream compromise through the vendor account or integration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, and DORA defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Vendor onboarding and offboarding both depend on controlled account lifecycle and access revocation. |
| Recommendation — Inventory vendor accounts and revoke access promptly when the relationship ends. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding must revoke or invalidate vendor credentials, tokens, and related authenticators. |
| AC-2 — Account Management | Onboarding and offboarding are account lifecycle controls for third parties and integrations. | |
| Recommendation — Rotate or invalidate vendor authenticators when access is no longer required. Provision only approved vendor accounts and disable them at offboarding. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Vendor onboarding/offboarding centers on third-party access governance in cloud and SaaS environments. |
| Recommendation — Control third-party identities, permissions, and deprovisioning across cloud services. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Offboarding failures leave vendor secrets and access paths active after the relationship ends. |
| NHI-05 — Overprivileged NHI | Onboarding should prevent excessive vendor permissions that increase blast radius. | |
| NHI-07 — Long-Lived Secrets | Vendor onboarding and offboarding must address tokens and keys that persist beyond need. | |
| Recommendation — Revoke vendor credentials and verify no residual access remains after termination. Grant the minimum vendor privileges needed for the approved use case. Set expiry and rotation rules for vendor secrets tied to access. | ||
| DORA | GV.SC-01 — ICT third-party risk management | DORA directly governs third-party lifecycle and termination controls for regulated entities. |
| Recommendation — Apply formal onboarding and termination controls for ICT vendors. | ||
Practitioner Guidance
What to verify: Treat onboarding as incomplete until you can identify the owner, purpose, scope, and expiration condition for every vendor access path. Treat offboarding as incomplete until all of those paths have been actively revoked and tested.
Common mistake: Teams often remove the human account but forget the machine-side dependencies, such as tokens, service credentials, shared secrets, or federated trust links. In third-party risk management, that partial cleanup is usually the real exposure.
What good looks like: The vendor lifecycle is joined up, with onboarding approvals tied to a live inventory and offboarding tied to a revocation checklist that includes direct and indirect access. The most useful control is the one that can prove there is no surviving access after the relationship ends.
Practitioner takeaway: Onboarding is about making third-party access safe to begin; offboarding is about making sure it truly ends. Mature programs measure both as one lifecycle, because the security gap usually appears in the handoff between approval and removal.
Related resources from NHI Mgmt Group
- What is the difference between vendor risk management and third-party risk management?
- What is the difference between third-party risk management and a one-time vendor review?
- What is the difference between third-party risk management and NHI governance?
- What is the difference between a standalone third-party risk platform and a compliance platform’s vendor module?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
