Lingering third-party access creates a standing pathway into sensitive systems long after the original business need has ended. That raises the risk of unauthorised use, forgotten accounts, and privilege creep across infrastructure. Organisations should treat offboarding, check-out, and rotation for external accounts as part of the core PAM lifecycle, not as an administrative afterthought.
Why third-party access that survives project closeout is dangerous
When a vendor’s access outlives the project, the organisation has effectively kept an external trust relationship open without an active business justification. That creates a standing path into production systems, admin consoles, and data stores, which is exactly why offboarding has to be treated as a control, not paperwork. The longer it remains, the harder it is to prove who still can do what.
Lingering access also weakens accountability. Once the original project team disperses, ownership of the vendor account often becomes unclear, making periodic review less reliable and rotation easier to defer. In practice, that is how temporary access turns into durable privilege.
What failure modes typically follow
The first failure mode is forgotten access: accounts, keys, tokens, or remote support paths remain active because no one owns the closeout step. A second is privilege creep, where the vendor keeps broad rights “just in case” and those rights are never tightened after go-live. A third is reuse, where the same credential or integration path is quietly carried into a new engagement, increasing blast radius if it is ever exposed.
These problems are not theoretical. They are the same control weaknesses that show up when organisations fail to manage privileged access as a lifecycle, rather than as a one-time approval. They also align with the common need to remove standing access through just-in-time access and zero standing privilege so external users do not retain permanent rights after the work ends.
How to close the risk cleanly
Project exit should trigger an explicit access inventory: human vendor accounts, service accounts, shared credentials, API tokens, support tunnels, and emergency paths. Each item should have a named owner, a last-used signal, and a removal or expiry date. If the account still has production reach, treat it as active risk until proven otherwise.
Where vendors used administrative tooling, session controls matter as much as account deletion. If the access model included remote support or break-glass style privileges, the closeout should also revoke or re-seal those paths and confirm they cannot be reactivated informally. The point is to eliminate the path, not just mark the project complete.
For teams modernising PAM, the practical question is whether the vendor’s access was time-bound and reviewable from the start. A strong control model should make it easy to observe privileged sessions, revoke stale entitlements, and prove that checkout and rotation happened when the engagement ended. In cloud-heavy environments, this often needs to be paired with cloud privilege right-sizing so inherited permissions do not linger across accounts and subscriptions.
Risk and Threat Considerations
Lingering third-party access is attractive because it gives an attacker or malicious insider a legitimate-looking route into systems after normal oversight has weakened. If the vendor, its subcontractor, or its credential material is compromised, that residual trust can become the easiest path to lateral movement, data access, or administrative abuse.
Failure mechanism: The project ends, but the access path does not, so the organisation continues to trust a third party whose operational need, supervision, and sometimes even staff continuity have already changed.
Impact: Unused access can be abused for unauthorised changes, data exfiltration, or privileged action, and it also increases the chance that a later incident is hard to attribute because the account was never properly offboarded.
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 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Vendor access often persists through keys, tokens, and credentials. |
| AC-6 — Least Privilege | Residual vendor rights commonly remain broader than the work requires. | |
| AC-2 — Account Management | Third-party accounts must be disabled or removed when the engagement ends. | |
| Recommendation — Revoke and rotate vendor authenticators at project closeout. Strip vendor entitlements to the minimum needed and time-bound them. Disable inactive vendor accounts and confirm offboarding completion. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Project end should trigger revocation and review of external access rights. |
| A.5.15 — Access control | External access needs controlled issuance, review, and removal. | |
| Recommendation — Review and revoke third-party access rights when the project closes. Apply access control to ensure vendor access expires with business need. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Residual third-party access is the core offboarding failure pattern. |
| NHI-07 — Long-Lived Secrets | Lingering vendor access often survives through unrotated secrets or tokens. | |
| NHI-05 — Overprivileged NHI | Vendors often retain excessive access beyond the project requirement. | |
| Recommendation — Offboard external identities and credentials when the engagement ends. Rotate or delete vendor secrets instead of leaving them long-lived. Reduce vendor privileges to the narrowest role that still supports the task. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle control is the operational safeguard for vendor offboarding. |
| Recommendation — Continuously review and remove vendor accounts that no longer have a business need. | ||
Practitioner Guidance
What to prioritise: Remove access before closing the engagement record. If the vendor still needs access for warranty, support, or transition, convert it to a time-bounded exception with an owner, an expiry date, and a documented review point.
What to verify: Check that every vendor path is covered, not just named user accounts. That means tokens, SSH keys, API keys, delegated admin roles, remote support tooling, and any shared emergency access that could still authenticate after the project ends.
Common mistake: Treating offboarding as HR-style deprovisioning only. For third parties, the real control is whether the access path is revoked, rotated, and confirmed dead in the systems that matter.
Practitioner takeaway: Project closeout is the last safe moment to collapse external privilege, because once the business case ends, every remaining access path becomes residual trust without a current justification.
Related resources from NHI Mgmt Group
- What happens when temporary third-party access is not revoked after a project ends?
- Who is accountable for third-party access after a campaign or project ends?
- What happens when educational institutions allow third-party vendors or remote users privileged access without strong controls?
- What happens when third-party access is not removed after a contract ends?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
