A caller knows the employee's name, manager, project, and upcoming travel. They say their phone is broken and a customer meeting starts in ten minutes. None of that establishes that the caller should receive control of the employee's account.
Account recovery is a business process with an authentication outcome. Treat it with the same care as the sign-in it can replace.
Define proof before the urgent call
NIST's authenticator-management guidance addresses recovery as part of an account's lifecycle. Translate that principle into an organization-specific process approved by the identity and support teams.
A recovery procedure should state which verified channels are acceptable, what the technician may change, and when a second approver is required. A phone number supplied during the request is not an independently established contact channel.
Do not make publicly discoverable information the only check. Names, department details, and work addresses can be known to people outside the organization.
Separate assistance from credential collection
A support technician can help a person navigate an approved recovery flow without asking for a password, live verification code, or recovery code.
For a hypothetical remote employee, the safe response may involve a previously established channel and an identity administrator. The exact evidence will depend on the organization's enrollment and recovery design. The important point is that the caller cannot redefine the procedure through urgency.
Make escalation available. A process that offers no practical option when the standard method fails invites improvisation.
Write down the privileged changes
Record the account, verification method used, approving role, action taken, and time. Do not put the secret itself into the ticket.
Distinguish resetting a password from replacing an authenticator, adding a recovery destination, or changing a registered contact. Each can affect who controls the next sign-in.
OWASP's recovery guidance provides a useful technical companion for the application flow; the help-desk process still needs its own authorization and accountability.
Test the process without tricking employees
Use an announced exercise with approved participants and fictional accounts. Ask technicians how they would handle a lost phone, inaccessible mailbox, or request from an executive's assistant.
Evaluate consistency across shifts, not how convincingly someone can impersonate a colleague. The exercise should improve the process rather than shame the person following it.
For related planning, read recovery codes and account control and emergency access readiness. A recovery path succeeds when the legitimate user regains access and the organization can explain why that transfer was authorized.