They should revoke or narrow the vendor’s access as part of the relationship change itself, not as a separate cleanup task. Offboarding, service substitution, and integration retirement all need a deliberate access removal step or old privileges will outlive the business need.
Why the vendor change itself is the control point
When a vendor relationship changes, the security decision should happen at the same moment as the commercial or operational decision. If the vendor no longer needs a system, integration, workspace, API, or support path, the access should be narrowed or revoked immediately so old trust does not linger after the business need has ended.
This is not just an administrative cleanup step. Relationship changes are the moment when scope, responsibility, and exposure change together, so access should be re-evaluated against the new reality rather than left in place until a later review cycle.
What “narrow or revoke” should actually cover
Organisations should treat vendor access as a bundle of permissions, credentials, sessions, integrations, and delegated capabilities. If the relationship shrinks but does not end, reduce access to the smallest set needed for the remaining work, remove standing access that is no longer justified, and rotate or retire any secrets or tokens tied to the old arrangement.
Where the vendor is being replaced, the old access path should be closed as part of service transition, not after the new service is stable. That includes accounts, shared admin rights, API credentials, SSO or federation trust, file shares, support portals, and any automation that still acts on the vendor’s behalf.
Good offboarding also means checking the hidden edges of the relationship: subcontractors, test environments, monitoring tools, and “temporary” exceptions that often survive the original contract. If a privilege was granted for a specific integration, it should be removed when that integration is retired, even if other parts of the relationship continue.
Risk and Threat Considerations
Leaving vendor access in place after a relationship changes creates avoidable exposure. The common failure mode is stale access outliving the legitimate business need, which can lead to unintended data access, unauthorized changes, or abuse of credentials that were never intended to remain active.
Failure mechanism: The organisation treats the relationship change as a paperwork event, but the old access paths remain technically valid. That gap lets residual credentials, delegated rights, or integrations continue to function after the vendor should no longer have them.
Impact: Excess access increases the blast radius of a dispute, mistake, compromise, or service transition. It can also complicate incident response because teams may not realise that an old vendor path is still trusted until it is used or abused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Vendor access must be removed or reduced when the relationship changes. |
| AC-6 — Least Privilege | Relationship changes should narrow access to only what remains needed. | |
| IA-5 — Authenticator Management | Vendor transitions often require rotation or retirement of credentials and tokens. | |
| Recommendation — Update accounts and disable obsolete vendor access as part of offboarding. Re-scope vendor permissions to the minimum needed for the new arrangement. Rotate or retire authenticator material tied to the old vendor relationship. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier access must be governed across relationship changes and termination. |
| A.5.20 — Addressing information security within supplier agreements | Contracts should define access scope and termination conditions for vendors. | |
| Recommendation — Ensure supplier access removal is built into supplier lifecycle procedures. Define offboarding and access-revocation duties in supplier agreements. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Relationship changes require access control changes for external vendor identities. |
| Recommendation — Remove or narrow vendor access when the business relationship changes. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Vendor offboarding is an access-control task requiring revocation and review. |
| Recommendation — Revoke stale vendor access and review remaining entitlements after transitions. | ||
| SOC 2 (AICPA) | CC6.2 — Restricts logical access to information assets | Vendor access changes support control over logical access after relationship shifts. |
| CC6.3 — Manages access rights to meet objectives | Changing vendor relationships require timely adjustment of access rights. | |
| Recommendation — Restrict access promptly when vendors no longer need it. Reassess and adjust vendor rights when the relationship changes. | ||
Practitioner Guidance
What to verify: Confirm that the access review is tied to the relationship event itself, not a later periodic recertification. For each vendor change, verify which credentials, accounts, API keys, SSO links, privileged roles, and automations must be narrowed or removed before the change is considered complete.
Decision rule: If the vendor no longer needs direct operational access, revoke it. If some access must remain, reissue it under the new scope rather than preserving the old one. Treat “we will clean it up later” as a control failure, not a workable transition plan.
What good looks like: The offboarding or transition record shows a closed-loop process: business relationship changed, technical access updated, secrets rotated where needed, and an owner confirmed there are no residual paths that still rely on the old trust relationship.
Practitioner takeaway: Vendor change management should be designed so the access change is inseparable from the business change; if the relationship is different, the permissions should be different too.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org