Treat it as an offboarding event, not a low-priority housekeeping task. Revoke the credentials, confirm they are removed from connected systems, and verify that downstream integrations no longer trust them. If the organisation cannot do that quickly, the relationship is still technically alive.
When a vendor relationship ends, why do leftover credentials matter?
A contract ending does not automatically end the trust path. If an API key, token, certificate, or shared secret still works, the vendor can still reach systems, data, or automation that were meant to be shut off. The practical question is not whether procurement is done, but whether every credential and downstream dependency has actually been cut off.
Leftover credentials are especially problematic because they often survive in places the business does not inspect during offboarding: CI/CD variables, integration platforms, partner portals, scheduled jobs, and embedded application config. A relationship can look closed on paper while the technical access remains live in production.
What does proper offboarding look like for credentials and integrations?
Proper offboarding means treating the vendor like any other identity-bearing party whose access must be revoked, verified, and documented. The sequence is simple in principle: identify every issued secret or authenticator, revoke or disable it at the source, remove it from connected systems, and confirm that dependent services fail closed rather than silently accepting old trust.
In practice, the highest-value step is proving removal, not just issuing a revocation request. A token that is “deactivated” in one console but still cached in a gateway, agent, or automation runner is still an active exposure. For that reason, offboarding should include evidence of rotation, deletion, or expiry on both sides of the relationship.
Where the credential supports machine-to-machine access, the control objective is to eliminate standing trust, not merely reduce convenience. That often means replacing shared static secrets with shorter-lived credentials and credential rotation discipline that can be executed quickly when a relationship ends.
What breaks when old vendor credentials are left in place?
Leftover credentials create a hidden dependency chain: the vendor may no longer be under contract, but systems still assume its identity is trustworthy. That opens the door to unauthorised access, unexpected data retrieval, failed audit trails, and confusing incident response when traffic continues from a party everyone believed was gone.
It also creates renewal risk through reuse. A stale key often survives in logs, scripts, export files, or copied configuration, then gets rediscovered later by an attacker or a well-meaning engineer. When credentials outlive the relationship that created them, the organisation inherits both exposure and ambiguity about ownership.
Risk and Threat Considerations
Vendor offboarding failures are a classic access control exposure because the organisation loses the ability to assume that a partner identity is still authorised, supervised, or even known. The longer a credential remains active after termination, the more likely it is to be reused, forgotten, or abused in ways that are hard to distinguish from legitimate integration traffic.
Failure mechanism: The credential remains valid in one or more connected systems, or its revocation is not propagated across all dependent platforms, so the old trust relationship continues to function after the business relationship has ended.
Impact: An ex-vendor, compromised vendor account, or third party who obtained the secret can continue accessing data or services, and the organisation may not detect the exposure until after misuse, failed reconciliation, or an incident investigation.
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, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Leftover vendor credentials are an offboarding failure for non-human access. |
| NHI-02 — Secret Leakage | End-of-relationship secrets that still exist can be reused or exposed. | |
| NHI-07 — Long-Lived Secrets | Vendor credentials that persist after termination remain standing trust. | |
| Recommendation — Revoke vendor credentials and verify all dependent systems stop trusting them. Rotate or delete exposed secrets and confirm they are no longer reachable. Replace static vendor secrets with short-lived credentials and enforce expiry. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central to revoking vendor access cleanly. |
| AC-2 — Account Management | Vendor offboarding requires disabling or removing external access paths. | |
| IA-9 — Service Identification and Authentication | Machine-to-machine vendor credentials must be invalidated across services. | |
| Recommendation — Manage issuance, rotation, revocation, and destruction of authenticators promptly. Disable external accounts and remove access promptly at relationship end. Invalidate service credentials and verify downstream systems no longer accept them. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Ended vendor access must be removed and reviewed as part of access rights control. |
| A.8.5 — Secure authentication | Persisting credentials are an authentication control weakness after offboarding. | |
| Recommendation — Remove access rights at offboarding and confirm removal in connected systems. Ensure old vendor authenticators cannot be reused after termination. | ||
Practitioner Guidance
What to prioritise: Revoke the credential first, then verify every downstream system that could still accept it. If the secret can still authenticate anywhere, treat the offboarding as incomplete until that trust path is gone.
What to verify:
- the credential is disabled or rotated at the issuing system;
- the secret is removed from pipelines, vault entries, agents, and application config;
- connected services reject the old credential;
- ownership for any replacement integration is explicitly reassigned.
Common mistake: Assuming a ticket closure, vendor notice, or contract termination is evidence of technical deprovisioning. The control only works when you can demonstrate that the old credential no longer authenticates anywhere that matters.
Practitioner takeaway: If a vendor relationship has ended but the credential still works, the relationship has not really ended from a security perspective, so offboarding must be validated as a technical control, not recorded as an administrative one.
Related resources from NHI Mgmt Group
- What should IAM teams do when a vendor relationship ends but integration credentials still exist?
- What should organisations do when a third-party or former partner may still hold historical customer data after the relationship ends?
- How can organisations reduce the risk of stale API keys and machine tokens?
- Why do short-lived credentials still leave organisations exposed?