Roll out phishing-resistant MFA in order of damage if the account is taken: administrators first, then email and identity, then source control and cloud consoles, then everyone else. CISA says any MFA is better than none, but phishing-resistant is the standard to aim for.
What counts as phishing-resistant
CISA's archived guidance calls FIDO and WebAuthn the only widely available phishing-resistant authentication, and says the protocol blocks the attempt when a user is tricked into logging in to a fake website. The Scattered Spider advisory adds PKI based MFA and says such methods resist push bombing and SIM swaps. SMS, one-time codes and push approvals are better than nothing but can be relayed or socially engineered.
Step 1: administrators
Cloud, identity and registry admins. One takeover here unlocks everything. Issue two keys each, one spare stored safely. Remove SMS and push as fallbacks for these accounts, otherwise an attacker simply picks the weaker route. Microsoft recommends requiring phishing-resistant MFA for admins.
Step 2: email and identity provider
Mailboxes are where resets land and where payment fraud is staged. See what business email compromise means for engineers. Protect the identity provider itself, since it gates everything else.
Step 3: source control, CI and package registries
Repository owners, release managers and anyone who can publish. The damage here travels downstream. See npm maintainer account security.
Step 4: production and cloud consoles
Break glass accounts, database admins and anyone with production access.
Step 5: everyone else
Passkeys on managed devices cover most staff. Decide the recovery path early, because recovery is the usual weak point. See passkey recovery design.
Interim steps while you roll out
CISA's archived guidance says that if phishing-resistant MFA is not possible yet, consider number matching to help block push bombardment. See MFA fatigue and number matching. Also add conditional access so a stolen session meets more checks.
Common snags
- Shared accounts, which cannot hold a personal key. Remove sharing first.
- Legacy apps that only accept passwords. List them and set an end date.
- Help desk resets that skip the key. See help desk controls.
- Contractors on personal devices. Decide whether a managed key is issued.
Measure progress
Track the share of each tier enrolled with a phishing-resistant method, the number of accounts that still allow SMS or push as a fallback, and the number of resets handled by the help desk each month. A dashboard with three numbers is enough. Review it monthly with the owner of each tier, and set a date for turning off the weaker fallback once enrolment passes a threshold you choose. Without the date, the weak path stays open indefinitely.
Quick check
Should we wait until everyone can move?
No. Start with the highest risk accounts, since those are the ones attackers want most.
Is TOTP acceptable in the meantime?
It is better than no MFA, and CISA says any MFA beats none, but it can be relayed by a proxy phishing page. Plan to replace it.
Sources
- CISA: More than a Password (archived)
- CISA advisory AA23-320A, Scattered Spider
- Respond to a compromised email account in Microsoft 365 (Microsoft Learn)
Last reviewed: 19 October 2026.
