What should organisations do first when they discover a contractor may still have access after termination?

What to do first when contractor access may still be active

The first move is to treat the termination as an access-control incident, not an HR paperwork issue. Inventory every identity, entitlement, token, shared credential, and privileged path tied to the contractor, then revoke access centrally and verify it across directories, groups, file shares, SaaS apps, VPN, and privileged systems. If supplier or integrator access exists, include those trust paths as well because termination gaps often survive in the places teams do not check first.

The practical reason for starting with inventory and revocation is that residual access is often distributed across multiple systems, including accounts created for temporary work, delegated admin roles, and shared operational tools. A single disabled login can leave other valid paths intact, so confirmation matters as much as the revocation itself. Current guidance on identity lifecycle management also treats offboarding as a control point, not a one-time administrative step, because hidden access can persist after the contract ends. This is exactly why organisations that manage NHI lifecycle discipline well are better positioned to catch stale access before it becomes an incident. NHI Lifecycle Management Guide

In practice, many teams discover the problem only after an external review, a helpdesk escalation, or suspicious activity has already surfaced.

How to verify revocation across the access stack

Effective offboarding means checking every place authority can live, not just the primary directory. That includes identity providers, security groups, application roles, secrets managers, privilege elevation tools, collaboration platforms, file systems, API tokens, and any service or workload access the contractor may have provisioned while working. If the person used shared credentials or approval-based access, those paths need separate review because they are often missed when people focus on the named account alone.

A good workflow is to confirm the account list first, then disable or remove entitlements in the source systems, and then validate the effect from the outside. The verification step should answer whether the person can still authenticate, whether any session remains active, and whether any standing permission was inherited through a group, role, or delegated admin relationship. For teams managing identity and access at scale, this is where a formal offboarding checklist matters more than informal follow-up, because the issue is usually breadth rather than complexity. OWASP’s guidance on non-human identities is useful here because it frames the wider problem of residual machine and delegated access that persists beyond the original user context. OWASP Non-Human Identity Top 10

Preserving logs is also part of the first-pass response because you need a reliable record of what was still reachable before revocation completed. That evidence supports both containment and later investigation if the contractor touched supplier-facing systems or sensitive repositories. These controls tend to break down when access was granted through nested groups, partner portals, or long-lived shared credentials because those paths are easy to overlook during a hurried offboarding.

Common offboarding edge cases teams miss

Tighter revocation often increases operational friction, so organisations have to balance speed against the risk of breaking legitimate handoffs. The hardest cases are not the obvious named accounts; they are the delegated privileges, temporary tokens, cached sessions, and cross-system entitlements that do not disappear when payroll ends. There is also a genuine tradeoff between immediate shutdown and preserving continuity if the contractor was supporting a live production dependency, but that tradeoff should be handled by temporary emergency ownership, not by leaving access in place.

One common failure is assuming that disabling a user in one directory automatically removes all access. That assumption fails when a contractor authenticated through a second identity provider, a federated SaaS trust, a local admin account, or a shared operational secret. Another is forgetting that access may have been extended to third parties, which means supplier systems can remain reachable even after the direct relationship ends. The NIST control catalogue is helpful for structuring the verification mindset around account management, access enforcement, and auditability. NIST SP 800-53 Rev 5 Security and Privacy Controls

At scale, the biggest underestimation is how often offboarding depends on people remembering every place access was created instead of on a system that can prove revocation end to end.

Risk and Threat Considerations

Residual contractor access creates a direct exposure window because the person may still be able to reach production systems, shared files, secrets, or supplier portals after termination. The risk is not limited to malicious intent; stale access also enables accidental misuse, unresolved privilege, and delayed containment if the account is later compromised by someone else.

Failure mechanism: Access persists when termination is handled in one system but not across all identity, group, token, and session layers. Attackers and insiders can exploit that gap by reusing still-valid credentials, session cookies, API keys, or delegated permissions before revocation propagates or is fully verified.

Impact: Sensitive data exposure, unauthorized changes, persistence in trusted systems, and harder incident response because investigators must separate legitimate historical access from active post-termination access. In supplier-connected environments, the blast radius can extend beyond internal systems into shared operational or partner-facing services.

Practitioner Guidance

What to prioritise: Revoke from the source of authority first, then verify downstream systems separately. If you only disable the visible login, treat the result as untrusted until groups, tokens, sessions, and delegated rights have been checked.

What to verify: Confirm that the contractor cannot authenticate, cannot inherit access through another role, and cannot reuse any active session or secret. The control is not complete until the revocation is observable in the places where work actually happened, especially collaboration tools, file systems, and privileged admin paths.

Decision rule: If any contractor access reached production, secrets, or supplier-facing systems, escalate immediately to contain sessions and review recent activity before assuming the account was harmless. That is the point where stale access becomes a possible exposure, not just an administrative cleanup item.

Practitioner takeaway: The safest offboarding posture is one that can prove absence of access, not merely the issuance of a disable request.

Related resources from NHI Mgmt Group

• What breaks when a contractor account still has privileged access after termination?
• Why do organisations still accumulate access risk even after they invest in SSO coverage?
• What do organisations get wrong about contractor access governance?
• What do organisations get wrong when they treat physical access badges and digital authentication as separate controls?