Phishing-Resistant MFA Rollout Checklist: From Push to Passkeys in 15 Steps
Most organizations already have MFA. Far fewer can show an auditor, a cyber insurer or their board that it is phishing-resistant. The authenticators are not the hard part. The rollout is. This checklist is the sequence we use with clients to move from push notifications and SMS to phishing-resistant MFA without breaking the business on the way.
For the reasoning behind each phase, read our companion piece on LinkedIn, From push to passkeys. This post is the working checklist.
What counts as phishing-resistant MFA
CISA's fact sheet on implementing phishing-resistant MFA names two forms that qualify: FIDO/WebAuthn authentication, which covers security keys and passkeys, and PKI-based authentication such as smart cards. Push without number matching, one-time codes and SMS each have documented failure modes, and CISA treats SMS as a last resort. Read the CISA fact sheet.
Phase 1: Scope the first wave
Inventory every MFA method enabled today, per user group, in each identity provider. You cannot retire what you have not listed.
Name the first wave by blast radius: identity, cloud and PAM administrators, help desk staff, finance approvers and engineers with production access.
Map the applications each wave uses and confirm they authenticate through your identity provider. Anything that does not goes on the edge-case list now, not in month four.
Choose the authenticator by role: hardware keys or device-bound passkeys for administrators, synced passkeys for the broad workforce, smart cards where PKI already exists.
Phase 2: Design enrollment
Check device readiness: managed devices, supported operating systems, and a working biometric or PIN for platform passkeys.
Secure the first enrollment. Issue a temporary access pass only after identity verification, or enroll administrators in person. Never let a weaker method register a stronger one.
Require a second authenticator of equal strength at enrollment, so a lost key never forces a fallback to SMS.
Turn on authentication strength policies per application, so sensitive apps accept only phishing-resistant methods.
Phase 3: Harden recovery and the help desk
The joint FBI and CISA advisory on Scattered Spider describes attackers calling the help desk, posing as employees, and getting passwords and MFA tokens reset. Recovery is where a strong rollout is quietly undone.
Replace knowledge questions with a verified callback to a number on file or a live ID check before any MFA reset.
Require a second approver for resets on privileged accounts, including when the help desk is outsourced.
Alert security on every MFA method reset or new registration, and review them weekly during the rollout.
Phase 4: Close the edge cases and retire weaker methods
Give shared workstations and kiosks a person-bound authenticator, such as a hardware key or smart card, rather than a device-bound passkey.
Decide the contractor model: issue keys, accept their own, or restrict them to apps behind stronger conditional access.
Put legacy apps that cannot do modern authentication behind an access gateway, or document each exception with an owner and an end date. Block legacy authentication protocols everywhere else.
Disable SMS, voice and plain push for each group once it is enrolled. A group is only done when its weaker methods are gone.
How to know you are done
Every privileged user is on phishing-resistant methods only, with exceptions reported by name.
Weaker methods are disabled group by group, tracked as a percentage of the workforce.
Help desk reset volume is stable after each wave. A spike means recovery needs more design.
Frequently asked questions
Is push MFA with number matching phishing-resistant?
No. Number matching stops push bombing, but a user can still be tricked into approving a login started on a fake page. It is a sensible interim step, not the destination.
Should we choose passkeys or hardware security keys?
Usually both. Synced passkeys are easiest for the broad workforce. Hardware keys or device-bound passkeys give administrators stronger assurance and a clean recovery story.
Do service accounts need phishing-resistant MFA?
Service accounts are not people and should be governed separately, with vaulted credentials, rotation and least privilege. Keep them out of the MFA rollout so they do not become the reason legacy methods stay on.
Check where you stand in two minutes
Take our 10-question phishing-resistant MFA scorecard for an instant score and your top gaps. If you already know the gaps, our Phishing-Resistant MFA Pilot is a fixed-fee sprint that moves your highest-risk group first, with enrollment, recovery and help desk verification designed in from day one.
Built by the people who ran it.
Comments