You roll out MFA, everyone groans, and then someone still gets tricked by a “sign in to view the document” link. That is the frustrating truth about a lot of MFA: it helps, but it can still be phished.
Passkeys and FIDO2 security keys change that, because they are designed to only work with the real site you meant to sign in to. The trick is rolling them out in a way that does not strand your team or blow up your helpdesk.
Why phishing-resistant MFA is worth the effort
Most “classic” MFA methods are really just “enter a code” methods. If someone is tricked into typing that code into a fake login page, the attacker can use it right away.
Phishing-resistant MFA (FIDO2/WebAuthn, including passkeys) is different. When it is working as intended, the login is bound to the real domain, so a lookalike site cannot successfully replay the sign-in.
That is why CISA calls FIDO/WebAuthn the only widely available phishing-resistant authentication approach, and why NIST points to WebAuthn as an example of phishing-resistant authentication.
Decide what “good” looks like for your business
Before you touch settings, decide what you are rolling out, who gets what, and how you will support it.
A simple, realistic target for a growing business looks like this:
- Admins go first. Your Microsoft 365 and line-of-business admin accounts are the keys to the kingdom. They should be the first to move to phishing-resistant methods.
- Two passkey paths, one standard. Allow passkeys stored on a user’s device (for example via Microsoft Authenticator) and, where it makes sense, a physical FIDO2 security key for higher-risk roles.
- SMS is a phase-out, not a same-day cutover. NIST restricts the use of SMS and voice for out-of-band authentication, but you still need a practical off-ramp. Plan a timeline.
- Fewer prompts, not more. A big win with passkeys is reducing MFA fatigue. Your goal is fewer interruptions, while still protecting sensitive apps.
Start with admins, and keep two tested break-glass accounts
This is the part small businesses skip, and it is how you end up locked out after one “tiny” Conditional Access change.
Do these in order:
- Create two emergency access accounts. Microsoft’s guidance for emergency access (break-glass) accounts exists for a reason. You want two, so one is still available if the other is disabled or misconfigured.
- Exclude them from Conditional Access, on purpose. The point is to have a way back in if a policy blocks everyone. These accounts should be tightly controlled and almost never used.
- Store credentials like you mean it. Put the credentials in a secure vault with a documented access process (who can retrieve them, under what conditions, and how you log it).
- Test them on a schedule. A break-glass account you have never tested is a comforting story, not a control. Pick a cadence (for example quarterly) and document the result.
Once you have that safety net, move your real admin accounts to phishing-resistant MFA first. In Microsoft Entra, that usually means enforcing a phishing-resistant MFA authentication strength for admin roles, not just “any MFA”.
Build an enrolment flow that does not create tickets
Most rollout pain is not “security”, it is enrolment and recovery. You can avoid a lot of churn with a clean setup path.
Here is a practical flow that works well in small IT teams:
- Use Temporary Access Pass for first-time setup and recovery. Temporary Access Pass (TAP) is designed to let a user sign in long enough to register stronger methods, without you resetting passwords repeatedly.
- Standardise on 10-minute enrolment appointments. For the first wave, book short slots. In that time you can verify the user, register the passkey, and confirm they can sign in from the devices they actually use.
- Require two working methods for key people. For owners, finance, and admins, aim for two phishing-resistant options (for example a device passkey plus a FIDO2 security key) so one lost phone does not become an outage.
Update your helpdesk scripts for the real-world problems
If you want this rollout to feel smooth to your team, your helpdesk needs scripts that match what users will actually say.
A solid “day one” script pack includes:
- “I got a new phone.” Steps to sign in, register a new passkey, and remove the old one. If the user cannot sign in, the script should pivot to issuing a TAP.
- “My passkey prompt never shows up.” Check basics first: the user is using the right account, the device has a screen lock set up (PIN/biometric), and the browser supports WebAuthn.
- “I’m being asked for SMS again.” This is usually a policy gap or an app that is not covered by the rule you think it is. The script should collect the app name, the sign-in method offered, and the time of the sign-in so you can trace it.
- “I’m getting too many prompts.” This is your MFA fatigue alarm bell. The fix is often better Conditional Access scoping (which apps, which locations, which devices), not telling people to “just deal with it”.
If you do nothing else, train your team to treat “I’m getting unexpected prompts” as a useful report, not a nuisance.
A realistic timeline to replace SMS and reduce MFA fatigue
If you try to rip out SMS in a week, you will either (a) break access for someone important, or (b) quietly add exceptions until the whole project is pointless.
A calmer timeline for most small businesses is:
- Weeks 1 to 2: Admins and break-glass. Create and test emergency access accounts, then move all admin roles to phishing-resistant MFA.
- Weeks 3 to 6: Pilot group. Pick a cross-section: one exec, one finance user, a few sales and operations users, and at least one “least technical” person. Fix the enrolment and support issues you discover.
- Weeks 7 to 10: Company-wide enrolment. Roll out in waves, and set a firm date when SMS stops being the default option.
- Weeks 11 to 12: Tighten policies. Reduce SMS use further, enforce phishing-resistant methods for higher-risk apps, and tune Conditional Access to cut down unnecessary prompts.
This is also when you measure success in plain business terms: fewer compromised accounts, fewer “I can’t log in” tickets, and fewer daily MFA interruptions.
Want a second set of eyes before you flip the switch?
Phishing-resistant MFA is one of those upgrades that pays off, but only if you roll it out with a plan and a safety net. If you would like help building your rollout plan, setting up break-glass access properly, and moving your business from SMS to passkeys in a sensible timeline, the Flexnet Networks team can help.
Sources
- Implementing Phishing-Resistant MFA (PDF), Cybersecurity and Infrastructure Security Agency (CISA)
- NIST SP 800-63B: Digital Identity Guidelines (Authentication and Lifecycle Management), National Institute of Standards and Technology (NIST)
- Passkeys (FIDO2) authentication method in Microsoft Entra ID, Microsoft Learn
- How to enable passkeys (FIDO2) in Microsoft Entra ID, Microsoft Learn
- Manage emergency access admin accounts, Microsoft Learn



