Implement multi-factor authentication by protecting the riskiest accounts first, choosing factors that resist phishing, planning account recovery before launch, and treating SMS codes as a weaker fallback. Roll out in stages, measure lockouts, and support users. NIST SP 800-63B-4 defines assurance levels you can use as a target.
Which accounts come first?
CISA's guidance for organizations says to require MFA for access to your systems whenever possible, for all users, but to start with privileged, administrative and remote access users. That ordering is sensible. A compromised administrator or VPN account does more damage than a compromised ordinary mailbox, and these groups are small enough to support well.
Email and identity provider accounts come next, since they unlock password resets for everything else.
What do the factors mean?
CISA describes the classic three: something you know, such as a password or PIN; something you have, such as an authenticator app or a phone; and something you are, such as a fingerprint. MFA requires two or more of these. NIST's guidelines set this out as authenticator assurance levels. At AAL2 a claimant must prove possession and control of two distinct authentication factors. At AAL3 the bar is higher: a phishing-resistant authenticator with a non-exportable key.
Why does phishing resistance matter?
Because codes can be typed into a fake site. NIST SP 800-63B-4 says applications assessed at AAL2 must offer a phishing-resistant authentication option, and that federal agencies must require their staff, contractors and partners to use phishing-resistant authentication to access federal information systems. It also recommends phishing-resistant authentication at AAL2 whenever practical, since phishing is a significant threat vector.
The document is also clear about the weaknesses of other methods. For SMS out-of-band codes it lists attacks such as an attacker convincing the mobile operator to redirect the victim's number, and a malicious app on the phone reading the code. It also describes authentication fatigue, where an attacker causes repeated requests to be sent in the hope the user approves one. Push approvals without a number match or context are exposed to that.
Practical order of preference: hardware security keys or passkeys, then authenticator apps with number matching, then SMS or voice as a last resort for those who have nothing else.
What breaks rollouts?
Recovery. If a user loses a phone and the only recovery is a help desk with weak identity checks, attackers will go through the help desk. Decide beforehand how recovery works: a second registered factor, backup codes stored safely, or an in-person check for high-risk roles.
Service accounts and old protocols are the next problem. Scripts and legacy mail clients that cannot do MFA need a different control, such as removal, token-based access or network restriction.
Last is user support. Expect a surge of tickets in the first week. Plan staffing and write a one-page guide with screenshots from your own setup.
A constructed example
A 200-person firm starts with its 12 administrators, giving each a hardware key and a second key as backup. In week two it moves the finance team, who handle payments, to authenticator apps with number matching. In week four, all staff are enrolled, with a deadline. Help desk recovery requires a video call with the manager and a code sent to a second registered factor. The team finds eight legacy scripts that use a shared mailbox password and replaces them with scoped tokens. Lockout tickets peak at 30 in the first week and fall under five a week by the second month.
How to check or apply this
- Inventory accounts by risk: administrators, remote access, finance, email and identity, everyone else.
- Pick the target factors per group. Aim for phishing-resistant for administrators.
- Write the recovery process and test it, including an attacker's attempt to abuse it.
- Find service accounts and legacy protocols. Fix or isolate them.
- Enroll in stages, with deadlines and support hours.
- Turn on number matching or context for push approvals, and alert on repeated denied prompts.
- Measure enrollment, lockouts, recovery requests and help desk volume.
- Review SMS users every quarter and migrate them to stronger factors.
Quick check
Is SMS MFA better than no MFA?
Yes, it blocks many simple password attacks. NIST documents its weaknesses, so use stronger factors where you can and treat SMS as a fallback.
Who should be enrolled first?
Privileged, administrative and remote access users, according to CISA, followed by email, identity and finance accounts.
Sources
- NIST SP 800-63B-4, Authentication and Authenticator Management
- NIST SP 800-63B-4 full text
- CISA, More than a Password
- CISA Cyber Essentials
Last reviewed: 18 October 2026.
