Treat it as an incident-ready access gap, not an administrative oversight. Revoke the account, review its privileges, check for dependent automations or integrations, and verify whether the account was used after departure. The objective is to close the access path without breaking legitimate production dependencies.
Why this is an access-control incident, not just a cleanup task
A former employee account that remains active is an identity and access control failure because the account still represents an authorised path into live systems. The practical question is not whether the person has left, but whether any standing permissions, tokens, sessions, or delegated access still let that account act in production. That is why offboarding and access review need to be treated as operational controls, not HR paperwork, and why lifecycle discipline matters in lifecycle processes for managing NHIs as well as workforce access.
For cloud and IAM teams, the first decision is whether the account is merely stale or still able to reach anything sensitive. If it can authenticate, assume it is live until proven otherwise. If it has federated trust, role chaining, API tokens, or group-based access, the reachable blast radius can be wider than the original user account suggests.
The same issue appears across identity programmes, which is why strong offboarding is usually tied to discovery, ownership, recertification, and revocation rather than one-time deactivation. NHIMG’s Identity Security Programme Guide is useful here because it frames leaver handling as a governed process with clear accountability, not an ad hoc ticket.
What cloud and IAM teams should check before disabling the account
Disable the account quickly, but do not stop at the toggle. The important follow-up is to identify what the account could access, whether it was used after departure, and whether any automation still depends on it. That includes console access, API access, SSH or CI/CD credentials, mailbox forwarding, role assumptions, shared group membership, and app-to-app trust that may have been attached to the identity.
In cloud estates, the hidden risk is often not the user session itself but linked credentials and permissions. A role, access key, service principal, or vault-stored secret can survive the user’s departure and continue to work even after the human login is disabled. Cloud teams should therefore review both privilege and dependency, especially where the account was used to operate infrastructure, deploy code, or approve privileged changes.
That is also why cloud workload identity matters: teams need to distinguish between human access and machine or workload access so they can revoke the former without accidentally breaking the latter. If the account was used to bootstrap pipelines or access cloud resources, replace it with an owned service identity before removing the old one.
When the account has broad permissions, review the effective permissions before you assume deactivation is enough. In practice, least privilege and privilege right-sizing are what limit the damage if an offboarding step is missed. NHIMG’s Cloud PAM and CIEM Guide is relevant because it focuses on unused permissions, escalation paths, and safe right-sizing in cloud environments.
How to close the access path without breaking production
The cleanest response is usually a controlled sequence: revoke direct access, confirm what downstream systems depend on the identity, migrate any legitimate automation to a replacement identity, and then verify that no residual path remains. This is especially important where the account owned secrets, participated in approval workflows, or had administrative roles that were reused informally by the team.
If the account touched cloud administration, configuration, or secrets, inspect whether there are attached tokens or vault permissions that also need rotation. A disabled login does not necessarily invalidate every credential artifact associated with the account. That is why teams should verify session invalidation, key rotation, and role detachment rather than assuming account disablement is equivalent to complete removal.
For broader identity architecture, offboarding is best handled as a lifecycle event with inventory and ownership attached. NHIMG’s NHI lifecycle management guide is useful as a lifecycle reference because the same operational discipline, discovery, ownership, rotation, and decommissioning, helps prevent abandoned access from lingering after a person leaves.
Risk and Threat Considerations
An active former employee account creates a direct opportunity for misuse if the account, its tokens, or its group memberships were not fully revoked. The most common failure mode is not a dramatic breach at first, but quiet continued access through an overlooked credential, delegated role, or automation hook that survives the person’s departure.
Failure mechanism: The account remains able to authenticate or inherit access through linked permissions, so an attacker, or the former employee if access was not formally withdrawn, can continue to reach systems, read data, or trigger administrative actions.
Impact: Exposure ranges from unauthorised data access to privilege abuse, hidden persistence, and broken accountability, especially when the account is reused in scripts, CI/CD jobs, or cloud role assumptions.
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 and risk surface, while CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Cloud account offboarding and access revocation are core IAM controls. |
| Recommendation — Revoke stale access and verify dependent identities or roles before closure. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Former employee accounts often leave behind passwords, tokens, or keys that must be invalidated. |
| AC-2 — Account Management | Leaver handling requires disabling, reviewing, and documenting account status and ownership. | |
| Recommendation — Rotate or invalidate every authenticator tied to the departed account. Disable the account, review its privileges, and confirm revocation evidence. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale active accounts and forgotten access paths are the core offboarding failure mode. |
| NHI-05 — Overprivileged NHI | Reviewing post-departure permissions addresses excessive standing access on the account. | |
| Recommendation — Audit offboarding gaps and remove any surviving identity or secret path. Right-size permissions before reissuing access to any replacement identity. | ||
Practitioner Guidance
What to verify: Confirm that disablement actually removed all active sign-in paths, including sessions, refresh tokens, API keys, mailbox rules, and any role trust relationships. If any dependency still needs the identity, replace the identity before removing the old one.
Decision rule: If the account can still access production, treat the event as a security incident until you have proven the residual access path is closed and any suspicious post-departure use has been ruled out.
What good looks like: The account is revoked, linked secrets are rotated, dependent automations have been re-homed, and the team can show who approved the offboarding, when access was removed, and what evidence confirms there is no remaining live path.
Practitioner takeaway: The goal is not just to delete the leaver account, it is to remove every surviving authority edge while preserving any production workflow that should continue under a new, explicitly owned identity.
Related resources from NHI Mgmt Group
- How should security teams respond when a stolen laptop still has active cloud sessions?
- What should security teams do when a former employee account is still present in hybrid identity systems?
- What breaks when a former employee still has access to shared cloud root credentials?
- How should security teams decide whether IAM backups belong inside their own cloud account or outside the identity perimeter?