They should revoke the access, confirm that connected tokens or delegated permissions are disabled, and retain evidence that the offboarding action was completed. In PCI environments, leaving supplier access in place after need ends is a control failure, not an administrative delay.
What offboarding should change when supplier access ends
When supplier access is no longer needed, the security decision is not to “leave it dormant” but to end the trust path completely. That means removing the supplier’s active access, disabling any tokens or delegated permissions that still authorize use, and confirming the account, integration, or pathway can no longer reach protected systems or data.
For third-party access, offboarding should also cover any connected identities that were created to support the supplier relationship, because access often survives in more than one place. A clean offboarding step closes the original entitlement, the federation or delegation mechanism, and any residual machine or shared access used for the engagement, as described in the Third-Party, B2B and Contractor Access Guide.
Good offboarding is complete only when the supplier no longer has a usable path back into the environment without a fresh approval and re-provisioning process. That is especially important for access granted through APIs, certificates, long-lived tokens, or delegated authorization, because those mechanisms can remain valid after a relationship ends unless they are explicitly revoked.
Why stale supplier access becomes a control problem
Expired business need does not make access harmless. A supplier account, token, or delegated grant that remains active after the work ends creates unnecessary exposure, weakens least-privilege discipline, and increases the chance that an old trust relationship can be reused, misapplied, or abused. In payment and regulated environments, this is treated as a real access-control defect, not an administrative cleanup task.
The risk is compounded when supplier access is shared, broadly scoped, or attached to service workflows that are not revisited during offboarding. If the original business owner assumes a vendor has been removed but a token, certificate, or connected permission is still live, the organization may retain hidden access paths that bypass normal review. That is why controls in sources such as PCI DSS v4.0 and ISO/IEC 27001:2022 Information Security Management emphasize access restriction and access removal as part of ongoing control hygiene.
Teams should think in terms of residual authority. If a supplier can still authenticate, exchange tokens, or act through a delegated application path after offboarding, the organization has not actually ended access, it has only changed the paperwork around it.
What evidence teams should retain after revocation
The useful evidence is not only that a request was raised, but that the offboarding action was executed and verified. That usually means retaining the revocation record, the date and time of completion, the systems affected, and the validation that any linked credentials, tokens, certificates, or delegated grants were disabled or expired.
In practice, the strongest evidence shows both action and verification: the access change was applied, and a second check confirmed the supplier no longer had working access. Where access is federated or API-driven, the evidence should show the specific account, application, scope, or connector that was removed so the offboarding can be audited later. Controls in CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support that kind of account and access lifecycle evidence.
For teams operating across many suppliers, the evidence standard should be consistent. If one supplier is offboarded by ticket closure alone while another requires proof of revocation and validation, the process is too weak to trust at scale.
Risk and Threat Considerations
Leaving supplier access in place after the business relationship ends creates avoidable exposure because the original trust decision is no longer justified. A forgotten account, token, or delegated permission can be reused for unauthorized access, lateral movement, or continued data exposure long after the supplier should have been removed.
Failure mechanism: Revocation is incomplete, so one or more authorization paths remain valid, such as a service token, OAuth grant, certificate, shared account, or federated session. An attacker or former supplier operator can then use the leftover path exactly as intended, which makes the abuse difficult to spot.
Impact: The organization retains unintended access, audit findings become harder to defend, and a stale supplier relationship can become an entry point for data theft, misuse of services, or compliance failure. In tightly controlled environments, that is a control breakdown, not a minor delay in administration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Supplier offboarding is account lifecycle and access removal. |
| Recommendation — Remove supplier accounts and confirm access is fully revoked. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The question is about disabling no-longer-needed supplier access. |
| IA-5 — Authenticator Management | Tokens, delegated permissions, and similar authenticators must be disabled. | |
| Recommendation — Deprovision supplier accounts and validate termination of access. Revoke or expire supplier authenticators and shared access material. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Supplier access removal is an identity lifecycle control. |
| A.5.18 — Access rights | The answer centers on revoking access rights after need ends. | |
| Recommendation — Ensure supplier identities are removed or disabled when no longer required. Review and revoke supplier access rights at offboarding. | ||
Practitioner Guidance
What to verify: Treat offboarding as complete only after the supplier’s direct account access, delegated permissions, and any connected tokens or certificates have been confirmed inactive. If the supplier used more than one integration path, verify each one separately rather than assuming a single revoke action covered everything.
Decision rule: If the supplier can still reach production, sensitive data, or an admin function after the business need has ended, prioritize revocation and validation before any cleanup or documentation task. Do not wait for the next periodic review to discover that access remained active.
Practitioner takeaway: The real test of supplier offboarding is whether every usable access path has been removed and proven dead, because partial revocation leaves a live trust relationship behind.
Related resources from NHI Mgmt Group
- What do teams get wrong about revoking MySQL permissions after access is no longer needed?
- What is the difference between rotating a secret and revoking access?
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How should security teams handle third-party access that looks legitimate after a supplier breach?