- Verify sensitive requests through a separately established channel.
- Do not confuse number matching or one-time codes with phishing-resistant authentication.
- Test the support exception path, including what happens when the usual verifier is unavailable.
A caller says an executive has lost a phone and needs an MFA reset before a customer meeting. The caller knows the executive's manager, travel schedule, and ticket terminology. None of those details proves who is calling.
SMS, voice, QR codes, and chat can carry the same request through different channels. The useful question is what action the message is trying to authorize: a reset, a payment, a new device, a download, or an access grant.
Separate the request from its verification
For sensitive changes, verify through a channel established before the request. A phone number supplied in the suspicious message is not an independent callback destination. Caller ID, a familiar voice, and public biographical details should not be sufficient proof.
Give help-desk staff a documented path for lost-device cases. It should specify accepted verification evidence, when a second authorized person is needed, and how privileged accounts are handled. A manager's approval can establish business need, but it does not by itself authenticate the person requesting access.
Notify the legitimate account holder through an existing channel after recovery changes. Log the verification method and approver without collecting unnecessary identity documents or copying secrets into tickets.
Use a safe help-desk exercise
In a planned tabletop, present this hypothetical request: a senior employee cannot receive MFA prompts, their manager is unavailable, and they want a temporary bypass sent to a new address.
Ask support to identify the permitted next step. Can staff refuse or pause the request without being pressured by seniority? Where does escalation go after hours? What evidence would authorize a reset? If the written procedure has no answer for an unavailable manager, resolve that gap before an attacker supplies one.
Do not conduct surprise impersonation against staff or change real accounts as part of this discussion. Test technical recovery steps separately with authorized test identities.
Choose authentication with the right properties
NIST SP 800-63B-4 distinguishes phishing-resistant authentication from methods whose codes can be relayed to a false verifier. TOTP, SMS codes, and ordinary push approvals are not phishing resistant. Number matching reduces accidental push approvals, but does not make the method equivalent to FIDO2/WebAuthn.
Prioritize phishing-resistant methods for administrators, help-desk staff, and sensitive business roles. Review enrollment and recovery at the same time. A stronger sign-in method offers limited protection if support can replace it through a weak identity check. The MFA comparison explains the deployment tradeoffs.
Include the mobile handoff
A QR code in an email can send someone to a browser outside the managed desktop. Provide a reporting route employees can reach from a phone, and tell them not to approve prompts they did not initiate. Where managed-device policies apply, verify what the mobile experience actually permits.
For payment changes, use a separate finance verification process with previously recorded contact details. Successful login to email does not authenticate a changed bank account instruction.
Measure reset exceptions, unexpected factor enrollments, suspicious approval reports, and time to revoke access after a confirmed incident. Review the tickets with support staff. Repeated exceptions often point to an unusable legitimate process, which deserves fixing alongside the security control.
Turn this identity guidance into a review of MFA strength, privileged access, lifecycle controls, and audit visibility.