Access can persist longer than it should, especially across devices and shared folders. That creates a clear offboarding gap because former users may still hold usable credentials or shared secrets. Mature controls should wipe vault access, remove permissions, and ensure admins can verify that shared passwords and related data are no longer reachable.
When Stored Passwords Outlive the Employee
The core problem is not just account deletion, it is credential persistence. If a leaving user can still reach a password vault, synced folder, browser store, shared file, or exported sheet, the organisation has an offboarding control gap. That gap can leave systems reachable after employment ends, and it often persists until someone finds and rotates every affected secret.
Stored passwords are especially risky because they can be copied, cached, or shared outside the original owner’s account. In practice, clean revocation requires both access removal and credential replacement, since deleting the person’s account does not invalidate every place the password may already exist.
Why Clean Revocation Is Harder Than It Looks
Revoking stored passwords is difficult when the organisation never knew where the passwords lived, who else could read them, or which systems depended on them. Shared operational files, unmanaged password stores, and ad hoc exports create hidden dependency chains, so a single offboarded user may leave behind multiple paths to the same protected service.
This is why mature offboarding is part identity hygiene, part secrets hygiene, and part inventory discipline. The question is not only whether the user is disabled, but whether every shared secret, backup copy, and delegated access path has been identified and retired or rotated.
At scale, the problem becomes timing. If a team relies on long-lived shared passwords, revocation can break integrations, so administrators delay cleanup and widen the exposure window. That delay is a signal that the underlying access model is too dependent on static credentials for shared operational use.
What Good Offboarding Looks Like for Shared Passwords
Good practice separates three actions: remove the user’s ability to reach the vault or store, remove any direct permissions tied to the user, and rotate the credentials that may already have been exposed. A clean process should also verify that any shared repository or password manager no longer contains accessible copies of the departing user’s data.
For organisations that still use shared passwords, verification matters as much as revocation. Admins need an auditable way to confirm that the shared secret was changed, all downstream copies were updated, and any access that depended on the old value has been retired or reissued.
When the same password is used across multiple devices or folders, the operational answer is rarely a single delete action. The effective control is a controlled replacement cycle, with ownership assigned for each secret and a clear end state for every location where the secret had been stored.
Risk and Threat Considerations
When stored passwords are not revoked cleanly, the main exposure is continued access by a former user or anyone who can reach a leftover copy. The risk is highest when the password unlocks production systems, shared admin tools, or unattended repositories that were never designed for individual attribution.
Failure mechanism: the organisation removes the person but not the secret. Cached copies, synced folders, browser stores, exports, and shared vault items can preserve usable credentials after departure, allowing access to persist until the password is rotated everywhere it exists.
Impact: unauthorized access can continue after offboarding, and the blast radius can extend from a single account to multiple systems if the same password was reused or broadly shared. That creates both security exposure and audit uncertainty, because the organisation may no longer know who can still authenticate.
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 NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stored password revocation gaps are a classic offboarding failure mode. |
| NHI-02 — Secret Leakage | The issue centers on credentials persisting in shared folders and stores after departure. | |
| NHI-07 — Long-Lived Secrets | Long-lived stored passwords increase the window where former users can still authenticate. | |
| Recommendation — Revoke vault access, rotate exposed secrets, and verify no leftover copies remain usable. Treat any shared or exported password as leaked until it is rotated and confirmed removed. Replace static shared passwords with shorter-lived, centrally managed credentials where possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The question is about revoking and replacing stored authenticators cleanly. |
| AC-2 — Account Management | Offboarding requires disabling user access paths tied to departed personnel. | |
| Recommendation — Manage credential lifecycle so offboarding triggers revocation and replacement of exposed authenticators. Disable accounts promptly and confirm all associated access paths are removed. | ||
Practitioner Guidance
What to verify: Confirm that offboarding closes both the user path and the secret path. If the organisation cannot prove where the password was stored or copied, treat the secret as still live and assume rotation is required before the user’s exit can be considered complete.
Decision rule: If a credential was shared, exported, or stored outside a centrally managed vault, do not rely on account termination alone. Rotate the secret first, then validate that each dependent system, folder, and team workflow has been updated to the new value.
Practitioner takeaway: Clean offboarding is not just revoking a person’s access, it is proving that no recoverable copy of the credential can still be used to reach the organisation’s systems.
Related resources from NHI Mgmt Group
- What happens when a user changes jobs or leaves the organisation without automated access updates?
- What breaks when passwords and sensitive data are stored without proper organisation or encryption?
- What happens when an organisation is in scope for NIS2 but cannot prove its security controls are effective?
- What happens when an organisation cannot determine effective permissions in Active Directory?