Before resetting an employee's multi-factor authentication (MFA), a help desk should establish whether the person can still authenticate through an approved method or must use the organization's account-recovery process. Knowing an employee's name, manager, or current project is not sufficient evidence to authorize a replacement factor.
For MSPs and IT leaders, the key decision is who may establish new access when the old proof of identity is unavailable. Define that decision before an urgent call arrives. An agent needs an approved way to restore access, a clear stopping point, and someone to handle cases that do not meet the requirements.
Why an MFA reset deserves its own decision
A reset can change which device or authenticator the account accepts. If an impersonator obtains that change, the next successful sign-in may use the attacker's factor.
The FBI's April 11, 2024 social-engineering advisory describes criminals posing as employees and contacting IT or help-desk staff to change login information. It recommends educating support staff about these schemes and establishing immediate reporting routes for suspicious interactions. This is an established risk, not a claim about a new incident today.
Start with what the employee can still prove
NIST SP 800-63B-4, finalized in July 2025, distinguishes adding or replacing an authenticator from recovering an account when the necessary authenticators are no longer available. Its requirements address defined assurance levels; they should inform your design rather than be treated as a universal help-desk script.
If an approved authenticator remains available: use the identity platform's supported, authenticated replacement process at the required assurance level. Establish which methods qualify in advance. Merely having an open application window does not mean the person has completed the authentication required to register a new factor.
If the required authenticators are unavailable: follow the documented recovery route. NIST recognizes recovery codes, prearranged recovery contacts, and repeated identity proofing, with combinations determined by the account's assurance requirements. An improvised conversation should not silently substitute for that process.
The practical recommendation is to give agents a decision path for each account class. Standard employee access, privileged administration, and emergency access may need different handling. Name the team that owns those choices and the evidence it will accept.
An urgent caller is not an exception policy
Consider a hypothetical employee traveling to a customer meeting. The caller says a phone was lost, names the manager, and asks the help desk to register a new number immediately. Those details explain the request, but they do not resolve who is making it.
The agent checks for an approved remaining authenticator or recovery method. If neither is available, the case moves to the designated recovery owner. The organization may need an established identity-proofing process or another previously approved route. Sending a code to the new number supplied during the call would only show that the caller controls that number.
A manager can explain business urgency and approve operational priorities. That approval should not, by itself, replace the identity evidence your recovery policy requires. Likewise, a callback can contribute context, but its strength depends on the trusted contact record and the channel; it is not automatically sufficient proof.
Make the escalation usable after hours. Tell the employee what happens next, who owns the case, and how to reach the legitimate support channel. A secure process that offers no practical recovery route invites pressure for informal workarounds.
Make the completed change visible
NIST calls for independent notifications of authenticator binding and account recovery, with instructions for reporting an unauthorized event. Confirm how your platform sends those notices and which established addresses receive them.
For the support record, capture the requested change, verification method and outcome, approving role, time, and escalation decision. Keep passwords, recovery codes, and identity-document copies out of ordinary tickets. Use the approved protected process for sensitive evidence.
If the employee disputes a reset, treat that as a security escalation. Preserve the records and involve the identity and incident-response owners; closing the support ticket is not the same as resolving potential unauthorized access.
Train the decision, then test the handoff
Use an authorized exercise to see whether an agent can recognize the request, locate the correct recovery path, and escalate a case without acceptable evidence. Evaluate the process as well as the employee: unclear ownership and unavailable recovery options need operational fixes.
Network Box USA's Security Awareness Training helps employees recognize and report social engineering, including impersonation and credential requests. Your organization retains responsibility for its identity-verification policy and access decisions. Contact our team to discuss awareness training that supports your employees' security decisions.