Transferring a work account moves ownership or access to a colleague who still needs the tool, data, or service. Closing it down removes the account entirely so it can no longer be used. The right choice depends on whether the account supports ongoing business work or contains information that should be archived, reassigned, or deleted before departure.
What changes when you transfer a work account instead of closing it?
Transferring a work account is an ownership decision: the account remains active, but responsibility shifts because the underlying work, data, or service still has a business need. Closing it down is a retirement decision: access ends, the account should no longer authenticate, and any retained business records are handled through archive, export, or replacement access rather than the original account.
The practical difference is whether continuity or removal is the goal. Transfer preserves the account’s history and current use, while closure reduces the attack surface and prevents lingering access. That distinction matters most when the account is tied to shared systems, customer records, delegated approvals, or ongoing operational duties.
When is transfer the better option, and what has to change first?
Transfer is the better option when the account is still needed for legitimate work and the new owner can justify inheriting it. The main security requirement is not the handoff itself, but confirming that the account’s permissions, group memberships, and linked secrets still match the new role. If the account is broader than the new owner needs, transfer should include cleanup rather than a simple reassignment.
Before transfer, practitioners should verify which of these elements must move with the account and which must not:
- active sessions and device bindings
- delegated approvals or shared inbox access
- stored data, files, or workflow ownership
- API keys, tokens, or other secret material associated with the account
- audit history that must remain attributable to the original user
In practice, transfer should preserve accountability while avoiding privilege inheritance that is no longer justified by the new owner’s job function. If the account exists only as a shortcut to reach a system, it is often better to issue a fresh account or access path and retire the old one.
What does closing a work account actually accomplish?
Closing a work account removes the account as a live access path, which is the right outcome when the person no longer needs to sign in and no business process depends on that identity. It is usually the cleaner option for reducing unused access, especially where the account held elevated permissions, long-lived sessions, or secrets that could outlast the employee relationship.
Closure should be treated as more than deleting a username. Good closure also means revoking active tokens, disabling federated access, removing scheduled jobs or app connections, and confirming that any required records have been exported or reassigned. If the account is simply disabled in one system but remains active in another linked service, the closure is incomplete.
How should teams decide between transfer and closure?
The deciding question is whether the account itself still represents a needed business capability. If the answer is yes, transfer or reissue access under a controlled owner change. If the answer is no, close it and remove every residual dependency. The mistake to avoid is keeping an account alive because it is convenient, even though the actual work can be continued by a different identity or process.
A useful rule is: transfer when the business process continues, close when the business process ends. That sounds simple, but the edge cases matter. Shared mailbox-style accounts, vendor portals, admin consoles, and automation-linked accounts often require explicit review because they combine continuity, delegated authority, and retained access in ways that are easy to overlook.
Risk and Threat Considerations
Leaving a departing worker’s account open, or transferring it without cleanup, can create unnecessary access exposure. The risk is highest when the account carries broad permissions, cached sessions, or connected secrets that are not rotated during the changeover.
Failure mechanism: Old access survives the personnel change, or the new owner inherits more privilege than the role requires, allowing misuse, accidental misuse, or unauthorized continued access through the original account path.
Impact: The organisation may retain a usable entry point longer than intended, which increases the chance of data exposure, unauthorized action, and weak accountability if something goes wrong later.
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 | Account transfer and closure both depend on credential lifecycle control. |
| AC-2 — Account Management | The question is about deciding whether an account should be reassigned or removed. | |
| Recommendation — Rotate or revoke authenticators when ownership changes or access ends. Review, transfer, disable, or remove accounts based on continued business need. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Transfer versus closure is fundamentally about preserving or removing access rights. |
| Recommendation — Reassign access rights only when justified and revoke them when no longer required. | ||
| CIS Controls v8 | CIS-5 — Account Management | The topic directly concerns account lifecycle and retention of access paths. |
| Recommendation — Disable or remove accounts that no longer need access and document any exceptions. | ||
Practitioner Guidance
What to verify: Treat transfer as a controlled access change, not an administrative rename. Confirm that the account still needs to exist, that the incoming owner can explain the business purpose, and that any linked secrets, approvals, or integrations are either reissued or explicitly retained for a documented reason.
Decision rule: If the account is needed to keep work moving, preserve it only with the minimum access required for the new owner. If the account is no longer needed for an active process, close it and force the dependency to move elsewhere rather than leaving dormant access in place.
Practitioner takeaway: The safest default is to close accounts that no longer serve an active business function, and to transfer only when the account must remain a live, accountable access path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
