Because the contract ending does not automatically remove credentials, profiles, or application entitlements. Risk persists when access is scattered across teams and systems without a single revocation record. Offboarding must close the access path, not just close the commercial relationship.
Why access can survive the end of the commercial relationship
The contract ending changes the business relationship, but it does not by itself remove the technical path into systems. Vendor users may still have active usernames, service accounts, shared credentials, federation trust, VPN profiles, API tokens, or application entitlements. If those paths are not explicitly enumerated and revoked, the access model outlives the paperwork.
That is why offboarding is an access control problem as much as a procurement or legal one. The security question is not whether the relationship ended on time, but whether every route that was created for that relationship has been identified and closed in the right systems.
Where the access path gets left behind
Access often persists because it is distributed across teams and tools. Procurement may close the contract, IT may disable one account, and application owners may never receive a revocation request for embedded permissions. In practice, this creates a gap between the commercial record and the identity record.
Shared credentials and indirect access are especially prone to being missed. A vendor may authenticate through a partner portal, but still retain access through a separate admin account, a cached session, an API key, or a delegated integration. Once access is fragmented, the absence of a single revocation record becomes the failure point.
A useful control concept is to treat vendor access as a complete inventory of identities and entitlements, not as a single account to disable. NHIMG’s Third-Party, B2B and Contractor Access Guide covers the lifecycle controls that matter here, including sponsorship, time limits, reviews and third-party offboarding. For the governance layer, IAM and IGA Basics is the right foundation because revocation has to be tied to provisioning, entitlement management and access reviews.
What good offboarding has to close
Good offboarding closes the full access path, not just the contract record. That includes human accounts, shared accounts, service accounts, tokens, certificates, remote access, and application-specific permissions. It also includes any trust relationship that allows the vendor to re-enter through federation or delegated administration.
For privileged or interactive access, the revocation step should be paired with session and credential control. NHIMG’s Privileged Session Management Guide is useful because session oversight helps confirm that access was actually used, and whether any lingering session needs to be terminated as part of offboarding. In operational environments, OT and ICS Identity and Access Guide is relevant where vendors may retain remote access paths that are difficult to see from standard IT offboarding.
Risk and Threat Considerations
Residual vendor access creates a standing exposure after the relationship is supposed to be over. The risk is not only unauthorized use by the former vendor, but also credential reuse, account sharing, and delayed detection when nobody owns the revocation trail.
Failure mechanism: Access remains active because offboarding is managed as a contract event instead of an identity and entitlement event, so credentials, sessions, and application permissions are not fully revoked.
Impact: A former vendor, or anyone who obtains the leftover access, can continue reaching internal systems, data, or admin functions after the commercial relationship has ended.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Vendor access risk persists when credentials and tokens are not revoked after offboarding. |
| AC-2 — Account Management | The question is about lingering accounts and entitlements after a vendor contract ends. | |
| AC-6 — Least Privilege | Residual vendor access is dangerous when permissions exceed current need or remain unnecessary. | |
| Recommendation — Revoke and rotate all vendor authenticators when the relationship ends. Maintain and disable vendor accounts through formal account lifecycle control. Remove unnecessary vendor permissions and confirm least-privilege access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Vendor offboarding requires access rights to be removed when the relationship ends. |
| A.8.2 — Privileged access rights | Residual vendor admin rights are a common source of post-contract exposure. | |
| Recommendation — Ensure access rights are revoked as part of supplier offboarding. Review and remove privileged vendor access promptly at offboarding. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The issue is lingering vendor access across accounts, systems, and entitlements. |
| Recommendation — Inventory, review, and revoke vendor access paths on offboarding. | ||
Practitioner Guidance
What to verify: Do not accept “the contract is closed” as evidence of offboarding. Verify that every vendor identity, every shared or service credential, and every application entitlement has an owner and a revocation outcome. If you cannot produce a complete list of active access paths, the offboarding is incomplete.
Decision rule: If the vendor touched production, privileged administration, or an externally exposed integration, treat offboarding as a controlled security change, not an administrative cleanup. Prioritise revocation confirmation, session termination, and token or key rotation before you close the business record.
Practitioner takeaway: The real control is not ending the relationship, it is proving that no usable access path remains anywhere the vendor was trusted.