Revoke every active token and session immediately, reset the password, and create a fresh credential set before the account is used again. Then review whether the shared-account model itself is appropriate, because persistent shared access makes it hard to prove who did what and increases the chance of unauthorized use after departure.
Why shared access becomes a departure risk the moment someone leaves
Shared accounts and still-active sessions turn offboarding into a trust problem as much as an access problem. If the former employee can continue authenticating, the organisation cannot reliably distinguish authorised use from residual access, which creates avoidable exposure to misuse, impersonation, and post-departure data access. That is why cleanup must be immediate, not deferred to a later review.
Persistent shared access also defeats accountability. When multiple people use the same login, it becomes much harder to attribute actions, investigate suspicious behaviour, or prove whether a change was made before or after departure. The access model may have been tolerated for convenience, but once employment ends, the security and audit consequences become much more material.
For identity and lifecycle handling, the primary issue is not only whether the account exists, but whether any active credential, token, browser session, remote session, or cached authentication still grants effective access. A removed user with a live session can sometimes retain access even after the password is changed, so the offboarding step must treat sessions and tokens as first-class exposure, not secondary cleanup.
What needs to be revoked, reset, and reissued
The correct response is to invalidate every active path into the shared account, then re-establish the account only if it still has a legitimate business purpose. That usually means revoking sessions and tokens, resetting the password or secret, reviewing any linked authentication material, and issuing a fresh credential set before the account is used again. If the account spans multiple systems, each one needs the same treatment because stale access often survives in more than one place.
This is also the point to ask whether the shared account should continue at all. Shared credentials are a weak control for anything that needs attribution, separation of duties, or after-the-fact investigation. If the account is truly necessary, limit its scope as tightly as possible and ensure there is a clear operational owner who can prove when and why it is used. NHIMG’s Ultimate Guide to NHIs and the NHI Lifecycle Management Guide both emphasise offboarding, rotation, and visibility as lifecycle controls, which are exactly the controls that break down when shared access is left untouched.
A useful benchmark is that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. That figure is not specific to employee departures alone, but it shows how often organisations underestimate credential cleanup as a lifecycle activity rather than a one-time HR event.
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-01 — Secrets and Credential Management | Shared accounts and active sessions hinge on credential revocation and rotation. |
| NHI-02 — Lifecycle and Offboarding | The question is fundamentally about removing access at departure and reissuing safe access. | |
| NHI-04 — Access Governance and Least Privilege | Shared access should be reviewed for necessity and reduced where attribution matters. | |
| Recommendation — Revoke stale credentials and rotate shared secrets immediately after departure. Treat offboarding as a mandatory lifecycle step that disables all residual access paths. Replace shared credentials with least-privilege, attributable access where possible. | ||
| CIS Controls v8 | 6.3 — Data Recovery, Backups, and Offboarding Access Removal | CIS prioritises timely removal of access for departing personnel and cleanup of residual access. |
| 5.3 — Account Management | Shared accounts require controlled provisioning, review, and deprovisioning after departure. | |
| Recommendation — Remove departing-user access promptly and validate that no residual sessions remain. Review and disable shared accounts through a formal account management process. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Residual shared access is an access-control failure affecting authentication and session validity. |
| Recommendation — Enforce timely deprovisioning and session invalidation for departed users. | ||
| NIST Zero Trust (SP 800-207) | SC-10 — Resource Access Management | Zero Trust requires continuous access decisions, including revocation when trust changes after departure. |
| Recommendation — Reevaluate and revoke access dynamically when the user context changes. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Stale shared accounts and live sessions are a classic valid-accounts abuse path. |
| Recommendation — Hunt for and close valid-account access that remains after offboarding. | ||
Practitioner Guidance
What to verify: Confirm that the former employee’s access is removed from every place the shared account can be used, not just the primary login screen. Check for active sessions, long-lived tokens, saved browser sessions, API credentials, and any delegated access that may still authenticate independently.
Decision rule: If the shared account can still reach production systems, treat it as live exposure until proven otherwise. Revoke first, then investigate whether any activity occurred during the residual-access window; do not wait for evidence of misuse before closing the access path.
Common mistake: Resetting the password without killing existing sessions or reissuing dependent credentials. That leaves a gap where the old user may still be able to act, and it also leaves the organisation unable to tell which actions belong to which person.
Practitioner takeaway: Offboarding is complete only when no previous user can still authenticate, and the shared account can support clean attribution or be retired in favour of a better access model.
Related resources from NHI Mgmt Group
- How should security teams govern Active Directory service accounts?
- What breaks when a former employee still has access to shared cloud root credentials?
- How should security teams secure AWS access when employees still rely on on-premises Active Directory accounts?
- Why does password-only access create outsized risk for Salesforce accounts and similar SaaS platforms?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
