When someone can no longer manage accounts, access should be transferred or revoked through a formal recovery process, not by sharing passwords informally. Trusted contacts can help verify identity, trigger account recovery or request closure, but they should have only the minimum access needed and only for the shortest time possible. Any saved sessions, recovery codes and app passwords should be reviewed and removed.
What happens to access when someone can no longer manage accounts?
The right outcome is a controlled transfer or removal of access through a formal recovery path, with the goal of preserving account continuity without leaving unmanaged access behind. The key decision is not whether another person can help, but whether that help is bounded, logged, time-limited, and reversible. Informal password sharing is the wrong control pattern because it blurs ownership and weakens accountability.
Why formal recovery is safer than informal sharing
Account recovery should separate identity verification from ongoing access. A trusted contact may help prove that the account holder can no longer act, or may request closure, but that role should not become open-ended administrative control. Where recovery is designed well, the helper can unblock the process without inheriting broader visibility into messages, files, or linked services.
The practical reason is that recovery often becomes the moment where an account is most vulnerable to misuse. If access is transferred without a documented process, it can survive longer than intended, be reused across services, or be left in place after the original need ends. That is why the safest design is minimal access for the shortest possible time, followed by explicit revocation or reassignment.
What should be reviewed before the account is closed or transferred
When an account can no longer be managed, the review should cover more than the login itself. Saved sessions, recovery codes, app passwords, device trust, delegated access, and any linked sign-in methods should be identified and removed or reset where appropriate. If the account was used to manage other services, those downstream connections should be checked so that the old access path does not remain active by accident.
It is also important to decide whether the account should be transferred, archived, or closed. A transfer makes sense only when the receiving party has a legitimate operational need and the account history must be preserved. Closure is the better option when continued access would create unnecessary exposure. In both cases, the decision should be recorded so later support teams can see what was done and why.
Risk and Threat Considerations
Unmanaged accounts can become a long-lived access path after the original owner can no longer control them. The main risks are account takeover, unauthorized reuse of recovery methods, and continued access through sessions or app-specific passwords that were never revoked.
Failure mechanism: Recovery is handled informally, so control over the account shifts without a formal handoff, leaving credentials, sessions, or delegated access active longer than intended.
Impact: Sensitive content, linked services, and administrative capabilities can remain exposed, and the organisation may lose the ability to prove who still had access at the time of a later incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The topic hinges on removing or resetting recovery methods and app passwords. |
| AC-2 — Account Management | The question is about transferring, disabling, or closing accounts when they can no longer be managed. | |
| Recommendation — Revoke or replace authenticators and recovery secrets when account control changes. Disable, reassign, or remove accounts through a documented lifecycle process. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account transition and revocation are core account-management safeguards. |
| Recommendation — Enforce account lifecycle controls for transfer, disablement, and removal. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Access must be limited and removed as part of formal recovery or closure. |
| Recommendation — Apply access control rules that restrict and revoke unmanaged access paths. | ||
Practitioner Guidance
What to prioritise: Treat identity verification and access removal as separate steps. First confirm who is authorised to request recovery or closure, then remove or reissue anything that can still authenticate to the account or its linked services.
What to verify: Check whether the account has persistent access paths such as remembered sessions, app passwords, recovery codes, device tokens, or delegated permissions. If any of those remain live, the account is not fully under control yet.
Practitioner takeaway: The safest recovery outcome is not continued convenience, it is a bounded transition that preserves needed records while eliminating every unnecessary path back into the account.
Related resources from NHI Mgmt Group
- What breaks when organisations manage service accounts like human users?
- How should security teams manage certificates when manual renewal no longer scales?
- How should teams stop SaaS apps from being renewed after the business no longer needs them?
- How should security teams manage Linux user accounts across many systems?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org