What happens when temporary third-party access is not revoked after a project ends?

If temporary third-party access is not revoked, the organisation keeps an unnecessary entry path into sensitive systems long after the business need has ended. That lingering access can be exploited by attackers, former partners, or compromised accounts. Access should be time-bound and removed automatically when the work is complete to prevent residual privilege from becoming a hidden security gap.

Why Unrevoked Third-Party Access Becomes a Residual Control Gap

Temporary access is only safe when the expiry is real, enforced, and auditable. Once a project ends, the access path stops being a business enabler and becomes dormant privilege, which is exactly the kind of leftover permission attackers look for. The longer it persists, the more likely it is to outlive the original assumptions about trust, ownership, and oversight.

That residual exposure is not limited to direct misuse. Unrevoked access can also survive changes in personnel, vendor operations, security posture, or account compromise, which means the original approval no longer reflects the current risk. Ultimate Guide to NHIs — Key Challenges and Risks captures the broader pattern well, including unmanaged credentials, excessive permissions, and third-party exposure.

When the access route is a token, key, shared account, or integration credential, the problem is usually not just access retention but access persistence. If the credential remains valid, the third party may still be able to reach data, workflows, or administration paths that were never intended to remain open after delivery is complete. In practice, that turns a temporary exception into an implicit standing permission.

Expired business need should mean expired access, not just expired expectation.
Any access path that cannot be time-bound should be treated as higher risk from the outset.
Where third-party access touches production systems, the offboarding step is part of the control, not an administrative afterthought.

How Organisations Avoid Leaving Behind Hidden Entry Paths

The best outcomes come from designing the access with removal in mind. Temporary third-party access should have an owner, an expiry condition, and a clear revocation method before it is ever granted. If those three things are missing, the organisation is not granting temporary access, it is creating a future cleanup problem.

Automation matters because manual revocation is easy to delay when the project closes unevenly, the vendor relationship changes, or no one feels responsible for the final cleanup. Guide to NHI Rotation Challenges is useful here because it shows how lifecycle friction, dependency mapping, and expiry discipline affect real-world access removal. NHI Lifecycle Management Guide adds the governance view: provision, review, rotate, and decommission on a defined lifecycle, not ad hoc memory.

For organisations that want a practical benchmark, the presence of formal offboarding matters more than good intentions. NHIMG notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong signal that many temporary access paths are still being left to chance.

What Failed Revocation Means for Risk, Response, and Governance

The main risk is not merely that access was once justified, but that its continued existence is now unjustified and therefore harder to defend. If a credential is still valid after the project ends, any later use is indistinguishable from normal access until someone notices it. That creates a quiet window for abuse, lateral movement, or vendor-side compromise to matter long after the original work is done.

52 NHI Breaches Analysis and OWASP Non-Human Identity Top 10 both reinforce the same practitioner lesson: unmanaged or over-retained access expands attack surface and weakens trust boundaries. For third-party relationships specifically, the issue becomes a supply-chain control problem as much as an identity problem, because a forgotten connection can become a long-lived bridge into sensitive systems.

Failure mechanism: The organisation fails to deactivate, expire, or rotate the access artefact when the project closes, so the credential, token, or account remains usable after the trust basis has ended.

Impact: Former vendors, compromised third-party environments, or external attackers can reuse that lingering access to reach sensitive data or administrative functions without having to break a fresh control.

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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-05 — Access Lifecycle and Offboarding	Lingering third-party access is a lifecycle and offboarding failure.
	NHI-03 — Credential Rotation and Expiry	Residual access often persists through still-valid tokens, keys, or accounts.
	NHI-04 — Least Privilege and Access Scope	Unrevoked third-party access often leaves excessive standing permissions behind.
Recommendation — Enforce timed deprovisioning and revoke third-party access at project end. Rotate or expire credentials so temporary access cannot persist beyond need. Restrict third-party permissions to the minimum scope required for the engagement.
CIS Controls v8	6 — Access Control Management	Third-party access must be removed when the business need ends.
	5 — Account Management	Temporary vendor accounts need lifecycle ownership and timely deprovisioning.
Recommendation — Remove unused accounts and revoke access immediately after project completion. Track third-party accounts through onboarding, review, and deprovisioning.
NIST CSF 2.0	PR.AC-4 — Access Permissions and Authorizations	Access should be limited and revoked when authorization no longer applies.
Recommendation — Revoke authorizations when the business justification ends.
NIST Zero Trust (SP 800-207)	4.1 — Policy Decision Point / Policy Enforcement Point	Time-bounded access depends on enforcement that can remove stale permissions.
Recommendation — Bind third-party access decisions to enforceable policy checks and expiry.
MITRE ATT&CK	T1078 — Valid Accounts	Stale third-party access becomes a valid account or token abuse path.
Recommendation — Detect and retire dormant valid accounts before they become an attacker foothold.

Practitioner Guidance

What to prioritise: Revoke the access path first, then validate whether it had access to production, sensitive data, or administrative actions. If the answer is yes, treat the issue as a live exposure problem, not a paperwork issue.

What to verify: Confirm that the revocation actually removed all usable paths, including tokens, keys, shared accounts, SSO app grants, and any delegated permissions that may outlive the project record. A closed ticket is not evidence of deprovisioning.

Decision rule: If the third party can still authenticate or act in a sensitive system after the project has ended, assume the control failed and escalate for immediate removal, review of activity during the residual period, and expiry of any linked credentials.

Practitioner takeaway: Temporary access is only temporary if the removal step is engineered, owned, and checked. The control objective is to make the end of the engagement mechanically visible in the access model, not merely documented in a project plan.