Teams should look for a current business owner, a current task, and a current access scope. If the relationship exists only on paper, or the vendor is no longer actively delivering work, the access is likely stale. The strongest signal is whether the entitlement can still be tied to an approved operational need.
How to decide whether the access still has a live operational purpose
vendor access should be justified by a present-day business relationship, not by the fact that the relationship once existed. A current owner must still be accountable for why the vendor needs access, what task it supports, and when that task ends. If the justification cannot be tied to an active delivery, support, or maintenance need, the access should be treated as expired until proven otherwise.
The practical test is whether the access still helps the organisation accomplish a current objective. A contract alone is not enough if there is no active work, no named sponsor, or no remaining service dependency. That is why third-party access reviews need to look at both the business case and the actual entitlement, not just the vendor name on the account.
For vendor relationships, the most useful evidence is recent activity that matches the approved scope. If the access is broad, dormant, or unrelated to current work, it usually signals that the original approval has drifted away from the real operational need. NHIMG’s Third-Party, B2B and Contractor Access Guide is a useful reference point for evaluating sponsorship, time limits, and review cadence in that kind of access relationship.
What makes vendor access look stale even when the account is still active?
Stale access often hides in plain sight because the account still works, even though the work behind it has ended or changed. Common indicators are an absent business owner, no current ticket or change record, a scope that no longer matches the task, and an account that has gone unused except for occasional login checks. Vendor access can also become stale when the original project finished but the entitlement was never reduced to the smallest remaining need.
Another warning sign is when the vendor can still reach systems that are no longer part of the service they support. That mismatch matters because access scope should track the current operating model, not the historical one. If the vendor is still present in directory groups, VPN policies, shared admin workflows, or remote support channels without a current support obligation, the entitlement has probably outlived its justification.
Teams should also separate “still technically possible” from “still necessary.” A login that works, or a remote path that remains open, does not prove legitimacy. It only proves the access path has not yet been removed. NHIMG’s Privileged Session Management Guide is helpful where vendor access includes administrative or interactive remote sessions that should be monitored, time-bounded, and auditable.
How should teams review and retire vendor access without creating disruption?
Good review practice starts with a three-part check: who owns the relationship, what current task requires the access, and what exact scope is still needed. If any one of those parts is missing, the team should treat the access as a candidate for reduction or removal rather than as a default entitlement. The review should be specific enough to answer whether the vendor still needs production access, a subset of systems, or only a support window.
When access remains justified, keep it narrow and time-bound. When it does not, remove it promptly and document the business reason so the decision is repeatable at the next review. In environments with remote support, session recording, command filtering, or just-in-time approval, those controls help prove whether access is actually being used for the approved task. NHIMG’s OT and ICS Identity and Access Guide is a useful parallel for teams that must manage third-party access in highly sensitive operational environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Vendor access review depends on removing stale accounts and validating current need. |
| Recommendation — Review and remove vendor accounts that no longer map to an approved business need. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Vendor access justification is an access-control decision tied to current authorization need. |
| A.8.2 — Privileged access rights | Many vendor accounts involve elevated rights that should expire when the task ends. | |
| Recommendation — Revalidate vendor access against current business justification before retaining it. Limit vendor privileged access to the smallest current task scope and remove it when unused. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Vendor access requires ongoing account lifecycle review, disablement, and owner accountability. |
| AC-6 — Least Privilege | The question is about whether the scope remains justified and should be minimized. | |
| Recommendation — Recertify vendor accounts against active need and disable stale access promptly. Constrain vendor entitlements to the least access required for the current task. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud vendor access hinges on current sponsorship, scope, and removal of stale entitlements. |
| Recommendation — Tie vendor access approvals to current sponsor, task, and scope in IAM reviews. | ||
Practitioner Guidance
What to verify: Confirm that every vendor entitlement still has a named sponsor, a current work item, and a current system scope. If any of those three cannot be produced quickly, the access should be treated as untrusted until the owner revalidates it.
Decision rule: If the vendor cannot point to an active operational dependency, remove the access first and reopen it only if a current need is re-established. That order is safer than waiting for evidence of misuse, because stale third-party access is often discovered only after the business context has already changed.
Practitioner takeaway: The best test is not whether the vendor still can access something, but whether the organisation would still approve that access today for a current, named operational purpose.
Related resources from NHI Mgmt Group
- How can teams tell whether workload access is still too secret-driven?
- How can security teams tell whether their remote access model is still too dependent on perimeter trust?
- How can IAM teams tell whether vendor access is too broad?
- How do security teams know whether approved access is still justified?