Phishing-resistant MFA succeeds when a lost device does not become a bypass

A worker arrives for an early shift without their security key. The helpdesk wants to restore access quickly; the identity team wants the new authentication policy to mean something. How that request is handled is part of the rollout design, not an awkward exception to resolve after launch.

For an identity lead, phishing-resistant MFA is an operational change spanning users, applications and support. The programme succeeds when people can enrol, work and recover access through understood routes, while applications enforce the intended protection. Counting registered authenticators alone misses those conditions.

Be precise about what phishing resistance provides

NIST SP 800-63B-4 describes phishing resistance as preventing authentication secrets or valid authenticator outputs from being disclosed to an impostor verifier without relying on the user’s vigilance. WebAuthn provides an example through binding credentials to the verifier’s domain. NIST does not consider manually entered one-time authentication codes phishing-resistant: an impostor can relay the output to the genuine service.

This distinction helps explain the investment to application owners. The aim is to change the authentication exchange, rather than depend solely on staff spotting convincing sign-in pages. It also explains why an emergency one-time code should not be reported as providing the same protection as the intended method.

Choose the authenticator and policy configuration for the required assurance and working environment. A product supporting WebAuthn does not, by itself, demonstrate that every deployment meets a particular NIST assurance level. Keep the assessment tied to the configuration you will operate.

Choose the pilot by working conditions

A pilot consisting only of office-based administrators with new laptops will answer too little about the workforce. Include the conditions most likely to expose a support problem: shared workstations, mobile work, remote onboarding, restricted device ports, accessibility needs and people who cannot use a personal phone for work.

Test the real applications as well as the identity portal. Confirm the expected sign-in route, what happens to existing sessions, and whether another route still permits access with a weaker method. Ask the application owner to demonstrate the complete task, including any separate administrative interface or legacy client.

Budget for spare equipment, replacement logistics and support coverage alongside licences. A hardware choice can be technically suitable yet operationally poor if a remote worker cannot obtain a replacement within the time the business can tolerate.

Design enrolment as an identity decision

Before registering a new authenticator, the process must establish whose account it should control. Specify who authorises enrolment, what evidence they use and how the registration instructions reach the intended person. A request appearing in the support queue should not itself establish identity.

Microsoft Entra’s Temporary Access Pass documentation provides a concrete onboarding and recovery mechanism. A TAP is a time-limited passcode configurable for single or multiple use, and can help a user register passwordless methods. Microsoft documents that registration of a passwordless method using a one-time TAP must finish within ten minutes of signing in with it.

That detail matters to rollout planning. The user needs the supported device and instructions ready, and the helpdesk needs to know what to do if registration fails or time runs out. The passcode’s availability does not decide whether the requester is the legitimate employee. Issuance and delivery remain decisions the organisation must design and control.

Agree who can issue temporary credentials, how their use is recorded and how the route ends. Prefer the narrowest duration and use pattern that supports the task. Check the chosen platform’s actual behaviour before writing support instructions that imply a temporary credential is restricted to one application or activity.

Walk through the lost-device case before enforcing the policy

Consider a hypothetical warehouse worker who loses their only enrolled key before a shift. The supervisor knows the worker is expected, but that fact alone does not establish that a remote caller requesting a reset is that person.

The support process should lead through a defined sequence:

1. Establish the recovery evidence. Follow the agreed identity-verification route for this account and location. Do not let urgency substitute for the required evidence.
2. Control the missing authenticator. Determine which credential is lost and take the account-specific action prescribed by the incident and recovery procedure.
3. Enable a replacement through the approved route. Use authorised equipment and, where appropriate, a controlled temporary onboarding mechanism.
4. Verify normal access and close the temporary route. Confirm the application journey works, notify the legitimate user through the agreed channel and remove or expire the temporary access as designed.

Run the scenario with the people who will actually support the shift. Can they obtain a replacement, reach the authorised recovery staff and follow instructions if the user’s usual device is unavailable? Record where the process stops. A successful demonstration by the identity engineer does not establish that the out-of-hours support team can execute it.

Where an additional authenticator is appropriate, test how it is enrolled, stored and revoked. It can reduce recovery disruption, but should not become an unmanaged credential that nobody remembers exists.

Expand by application coverage, with bounded exceptions

Some applications will need a transition arrangement. Give each exception an application owner, affected user group, interim control and review trigger. Describe the weaker route accurately. An enrolment campaign that leaves old authentication paths open indefinitely has not achieved the same result as enforcing the new method.

Track the number of users enrolled, the applications enforcing the intended route and the sign-ins using it as separate measures. Review failed enrolments, recovery duration and support escalations too. These show whether the design is becoming sustainable or merely transferring work to the helpdesk.

Use those findings to choose the right enterprise passkey deployment model. The selection should follow the workforce, device and recovery requirements already tested, so expansion brings a working access service as well as a stronger authenticator.