What breaks when access is not revoked quickly during employee or contractor departure?

Why This Matters for Security Teams

Delayed revocation turns departure into a trust gap, not just an HR event. The real risk is that access often remains valid after business need ends, so former employees or contractors can still use reports, code repositories, ticketing systems, cloud consoles, and shared secrets without triggering the same scrutiny as an outsider. For NHIs, this problem is even sharper because service accounts and tokens are often overlooked during offboarding, as covered in the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide.

This is not a theoretical issue. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after a notification event. That gap creates a post-departure window where misuse can blend into normal activity, especially when access is inherited, shared, or poorly documented. In practice, many security teams discover the exposure only after data has already been accessed or copied, rather than through intentional offboarding controls.

How It Works in Practice

Effective departure handling depends on making access removal a workflow, not a manual cleanup task. The starting point is a complete inventory of human and non-human access: accounts, group memberships, API keys, SSH keys, tokens, certificates, delegated admin roles, and any privileged sessions. That inventory matters because offboarding fails most often when the organisation revokes the person’s login but forgets the connected credentials that continue to work in automation, integrations, or scripts. The OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev. 5 Security and Privacy Controls both reinforce the need for access review, least privilege, and timely revocation.

Practical offboarding usually includes:

• Immediate disablement of interactive accounts and active sessions.
• Rotation or revocation of secrets that the departed user created, stored, or could retrieve.
• Removal from groups, roles, shared drives, repositories, and privileged tools.
• Validation that downstream systems no longer trust that identity or its tokens.
• Audit logging of every revocation step for later review.

For NHIs, the same logic applies to service accounts, bots, and CI/CD identities. If a contractor configured an automation pipeline, the pipeline credentials must be reassessed, not just the contractor’s directory account. Best practice is evolving toward event-driven deprovisioning tied to HR, vendor management, and identity governance systems, but there is no universal standard for this yet. These controls tend to break down in highly distributed environments where credentials are duplicated across SaaS tools, cloud platforms, and code repositories because the revocation path is fragmented.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance security speed against business continuity. A terminated administrator may need emergency access removed in minutes, while a departing engineer may leave behind shared pipelines, break-glass accounts, or customer-facing automations that cannot simply be deleted without disruption. That tradeoff is why current guidance suggests separating personal access from workload access wherever possible and using short-lived credentials for sensitive systems.

Edge cases appear when access is indirect or delegated. Shared accounts, vault-stored secrets, long-lived refresh tokens, and federated app permissions can survive the departure of the person who originally provisioned them. The safest pattern is to pair offboarding with secret rotation, token invalidation, and ownership reassignment, especially for systems that support persistent API access. NHIMG’s analysis of the Secret Sprawl Challenge shows why revocation often fails when secrets are copied into too many places to track reliably.

When the organisation lacks full identity visibility, the question is not only who left, but what they still control. That is why offboarding should be treated as a control over residual trust, not just account closure. The process is most fragile in environments with shared admin credentials, unmanaged SaaS sprawl, or embedded secrets in code and CI/CD systems.

Related resources from NHI Mgmt Group

• What breaks when agent access cannot be revoked quickly?
• What breaks when cloud access is not revoked quickly enough?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?