Only when the identity still has an active business need, a current sponsor and a defined end date. If any of those conditions are missing, the account should be treated as stale access and removed. Preserving unused third-party access for convenience is a common governance failure.
When should contractor access stay, and when should it be removed?
The safe default is that contractor or vendor access should stay in place only while the business relationship is still active, the access is explicitly sponsored, and the end date is current. That means someone inside the organisation remains accountable for the access, and the account is still tied to an operational need rather than left behind as legacy convenience.
Preserving third-party access without those three conditions turns a live entitlement into stale access. The practical test is simple: if no one can name the current business owner, justify the access, and confirm the expiry date, the account is no longer being governed as a controlled exception.
What makes third-party access safe enough to keep temporarily?
“Safe enough” does not mean permanent, and it does not mean broadly trusted. It means the access is narrow, time-bound, and still under an explicit approval chain. In practice that usually includes a sponsor who can answer for the access, a scope that is limited to the actual service or engagement, and a review point that forces renewal or removal rather than silent continuation.
For contractor and vendor identities, the risk rises quickly when access is reused across projects, shared across teams, or granted once and then forgotten. The longer an external account survives beyond the original need, the more likely it is to drift into unnecessary privilege, orphaned ownership, or unreviewed authentication material that nobody is actively watching.
Good governance also distinguishes between active operational access and merely “still working” access. An account can continue to authenticate while the underlying contract, purchase order, project, or support obligation has already ended. In that case the account is technically functional but no longer justified.
How do you tell genuine need from stale access?
The most reliable signal is whether the access can be defended in three layers at once: current task, current sponsor, and current expiry. If any one of those is missing, you do not have a stable entitlement, you have an incomplete ownership story. That is usually enough to start removal, or at minimum to force a reapproval before the access remains active.
Third-Party, B2B and Contractor Access Guide is the most direct reference for sponsorship, least privilege, time limits, and reviews in external access governance. For lifecycle cleanup across the broader identity estate, Joiner-Mover-Leaver (JML) Guide is useful because stale contractor access is often just leaver hygiene that was never completed.
Where contractor accounts include administrative reach or remote support capability, Privileged Session Management Guide is relevant because the question is no longer only whether access exists, but whether that access is supervised, attributable, and still justified for the session being performed.
Risk and Threat Considerations
Unreviewed contractor and vendor access creates two problems at once: unnecessary exposure and weak accountability. If the external party no longer needs the access, every additional day it remains live increases the chance that credentials, tokens, or support paths can be misused, inherited by the wrong person, or exploited after the relationship has effectively ended.
Failure mechanism: Access persists after the business need has lapsed, ownership has gone stale, or the sponsor has changed hands, so the account remains valid even though the control assumption behind it is no longer true.
Impact: The organisation keeps an active external pathway that can be abused for unauthorised access, privilege creep, audit failure, or harder-to-contain compromise if the vendor environment or contractor endpoint is exposed.
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 and CIS Controls v8 set the technical controls, and 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 | Third-party access depends on account lifecycle control and removal when no longer needed. |
| AC-6 — Least Privilege | Contractor access should be limited to the minimum rights required for the current task. | |
| IA-5 — Authenticator Management | Stale contractor access often persists through unused credentials, keys, or tokens. | |
| Recommendation — Review and disable contractor accounts when sponsorship or business need ends. Restrict vendor access to the minimum permissions needed for the active engagement. Rotate or revoke contractor authenticators when access is no longer justified. | ||
| CIS Controls v8 | CIS-5 — Account Management | This question is fundamentally about controlling and removing stale external accounts. |
| Recommendation — Inventory and remove contractor accounts that lack active ownership or need. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | External access needs periodic review, approval, and timely withdrawal when no longer required. |
| Recommendation — Review and revoke contractor access rights on a defined schedule. | ||
| SOC 2 (AICPA) | CC6.2 — Restrict Logical Access | Vendor access must be restricted to authorised, business-justified use and removed when it lapses. |
| Recommendation — Enforce approved, time-bound access for contractors and third parties. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Leaving contractor access in place after need ends is a classic offboarding failure. |
| NHI-05 — Overprivileged NHI | Legacy vendor access often accumulates excess privilege beyond the active need. | |
| NHI-07 — Long-Lived Secrets | Contractor access commonly persists through secrets, tokens, or keys that outlive the work. | |
| Recommendation — Revoke third-party access promptly when the engagement ends. Reduce contractor permissions to the smallest current business scope. Expire and rotate contractor secrets on short, enforced timelines. | ||
Practitioner Guidance
What to verify: Before allowing access to remain, verify the named sponsor, the current business justification, the expiry date, and whether the account still maps to the actual person or vendor function that needs it. If any of those cannot be confirmed quickly, treat the account as a removal candidate rather than a pending exception.
Decision rule: If the access is not tied to an active deliverable, support obligation, or funded engagement, remove it. If it is still needed, renew it explicitly with a shorter time limit and a named owner who is responsible for the next review.
Common mistake: Teams often confuse “the vendor may need it again” with a present need. That is exactly how dormant third-party access becomes normalised and escapes periodic review.
Practitioner takeaway: External access is safe to keep only when ownership, purpose, and expiry are all current, because once any one of those disappears the account stops behaving like a controlled exception and starts behaving like unmanaged exposure.