# Which MFA types should MSPs use to protect clients?

> Which MFA types should MSPs deploy? Compare FIDO2 passkeys, authenticator apps, push, and SMS using CISA and NIST guidance, plus a client rollout plan.

MSPs should standardize on phishing-resistant MFA, meaning FIDO2/WebAuthn security keys or passkeys, for technician and client-admin accounts, use authenticator apps with number matching for everyday users, and treat SMS codes as a last resort. That ordering comes straight from [CISA's MFA guidance](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf), and the payoff is well documented: a [Microsoft study of Azure Active Directory accounts](https://arxiv.org/abs/2305.00945) found that enabling MFA cut the risk of account compromise by 99.22% overall, and by 98.56% even for accounts whose passwords had already leaked. This guide compares the main MFA types and lays out a rollout order that scales across a client base.

![How multi-factor authentication protects MSP client accounts](/images/cms/68e009deb7bbf997ad1e04ca_img-g7qqob7s2dpzphbhz8myr0at.png)

## What are the main types of MFA?

Every MFA method combines two or more independent proofs of identity. [CISA groups them](https://www.cisa.gov/MFA) into something you know (a password or PIN), something you have (a security key, phone, or authenticator app), and something you are (a fingerprint or face scan).

For an MSP, the category matters less than how each concrete method holds up under attack. CISA's [Implementing Phishing-Resistant MFA fact sheet](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) ranks the common forms from strongest to weakest:

| MFA type (strongest first) | Examples | Weak against |
|---|---|---|
| Phishing-resistant MFA | FIDO2/WebAuthn security keys, passkeys, PKI smart cards | None of the common MFA bypasses |
| App or token OTP, push with number matching | Authenticator apps, hardware code fobs | Phishing that relays codes in real time |
| Push without number matching | One-tap "Approve" prompts | Push bombing and accidental approvals |
| SMS or voice codes | Text message or phone call | Phishing, SIM swap, and SS7 interception |

Any row on this table beats a bare password. The goal is to move each client as far up it as their apps and budget allow.

## Which MFA types count as phishing-resistant?

Only two, according to CISA: FIDO/WebAuthn authentication and PKI-based authentication (smart cards like the US government's PIV and CAC). PKI demands mature identity infrastructure, so for nearly every MSP client the practical option is FIDO. CISA is blunt about this: "The only widely available phishing-resistant authentication is FIDO/WebAuthn authentication."

FIDO works because the credential is cryptographically bound to the real site's origin: on a fake login page the protocol simply refuses to respond, and there is no code to hand over. Authenticators come as roaming devices (USB or NFC security keys) or platform authenticators built into laptops and phones.

Passkeys are FIDO credentials that can sync across a user's devices. The current revision of [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html) accepts syncable authenticators at AAL2, its standard two-factor level, while reserving its highest level (AAL3) for device-bound, non-exportable keys. In plain terms: synced passkeys give clients phishing resistance without buying hardware, and hardware keys remain the ceiling for the most sensitive accounts.

## Are authenticator apps good enough for everyday users?

For most client users, yes. CISA calls app-based OTP, hardware token OTP, and push with number matching "the best options for small- and medium-size business that cannot immediately implement phishing-resistant MFA."

Know the gap, though. A six-digit TOTP code can be [phished](/learning/what-is-phishing): the user types it into a fake page and the attacker relays it to the real site before it expires. Number matching (typing the number shown on the sign-in screen into the app) stops push bombing, but not that relay trick. So authenticator apps are the sensible default tier, not the finish line.

## Why are SMS codes the weakest MFA type?

CISA's fact sheet lists three reasons. SMS codes can be phished like any other code. They can be stolen through SIM swapping, where an attacker convinces the carrier to move the victim's number to a new SIM. And they can be intercepted through weaknesses in the SS7 telephone signaling protocol. [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html) classifies OTPs delivered over the phone network as a "restricted" authenticator for exactly these reasons.

CISA still says SMS "should only be used as a last resort" rather than never: it beats a bare password, which matters when [billions of leaked passwords](/learning/msp) are circulating. Treat it as a temporary bridge, then migrate clients up the table.

## How do attackers get around MFA?

Knowing the bypasses tells you which type to deploy where:

- **Real-time phishing relay.** A proxy site captures the password and the OTP code together and replays them instantly. Defeats app codes, token codes, and SMS. Only phishing-resistant MFA stops it.
- **Push bombing.** The attacker already has the password and floods the user with approval prompts until one gets tapped. Number matching shuts this down.
- **SIM swap and SS7 interception.** Affect SMS and voice codes only.
- **Sidestepping the login entirely.** [Device code phishing](/learning/device-code-flow-exploitation) and [OAuth consent abuse](/learning/shinyhunters-oauth-vishing) trick users into authorizing an attacker's session or app on the real login page, so MFA is satisfied by the victim rather than bypassed. Even phishing-resistant MFA does not block it.
- **Weak recovery paths.** If the helpdesk resets MFA after one persuasive phone call, the recovery flow becomes the real authentication method.

## What MFA should MSP technicians use themselves?

Treat your own staff as the highest-value accounts you manage, because attackers do. The joint [CISA/NSA/FBI advisory on MSP threats](https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-131a) (written with UK, Australian, Canadian, and New Zealand agencies) tells MSPs to enforce MFA on every account that touches customer environments, treat those accounts as privileged, and watch for unexplained failed logins. One compromised technician login or [hijacked RMM console](/learning/msp) opens dozens of client networks at once.

Some of this is no longer optional. [Microsoft now enforces MFA](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication) for sign-ins to the Azure portal, Microsoft Entra admin center, and Intune admin center (since October 2024), the Microsoft 365 admin center (since February 2025), and for write operations through Azure CLI, PowerShell, and REST APIs (rolling out since October 1, 2025). Even break-glass accounts get no exemption; Microsoft recommends a passkey (FIDO2) or certificate-based authentication for them. Give technicians the same.

## How should an MSP roll out MFA across clients?

1. **Inventory sign-ins first.** Find the apps that only support legacy authentication; they will shape the plan.
2. **Rank targets using CISA's two questions:** which resources would hurt most if compromised (email, file servers, remote access, identity servers), and which users are high-value targets (system administrators, attorneys, HR staff).
3. **Match the method to the tier.** Phishing-resistant MFA for admins, technicians, and high-value users; authenticator apps with number matching for everyone else.
4. **Disable weak fallbacks.** An account with a FIDO2 key but SMS still enabled is only as strong as the SMS.
5. **Write the recovery process before enrolling anyone.** Require two registered factors per user and a documented identity-verification step for resets.
6. **Monitor after go-live.** Unexplained failed logins are an early warning sign the joint MSP advisory explicitly says to monitor for; treat unexpected MFA prompts with the same urgency, since they usually mean the password is already stolen.

## What does MFA not protect against?

Be honest with clients about the limits. MFA guards the login event. It does not clean malware off an infected laptop, stop a user from approving a malicious OAuth app, or block fraud that never touches a sign-in page.

The clearest example is email spoofing. When a criminal sends invoices "from" your client's domain to that client's customers, no login happens and no MFA prompt fires. That lane belongs to [SPF, DKIM, and DMARC](/learning/what-is-email-authentication-and-why-does-it-matter), which you can verify for any domain with a [DMARC lookup](/tools/dmarc). DMARC has its own honest limit too: it cannot block [lookalike domains](/learning/how-can-i-take-down-lookalike-domains) that merely resemble the client's. Identity protection and email authentication are separate layers; Palisade automates the DMARC layer across client domains the same way your identity platform enforces MFA across tenants.

## Common issues with MFA rollouts

### Why did some apps break after MFA was enforced?

Legacy authentication flows that submit only a username and password, such as the OAuth ROPC grant, cannot complete an MFA challenge, and Microsoft is deprecating its ROPC-based sign-in APIs. Move those integrations to modern authentication. For systems that cannot support MFA at all, CISA recommends planning an upgrade or migration and escalating the remaining risk to leadership rather than quietly exempting the system.

### What do we do when a user loses their phone or security key?

Handle it through a pre-written recovery procedure, not an improvised helpdesk favor. Require every user to register at least two factors at enrollment so one lost device is an inconvenience, not an outage. Resets should require real identity verification, because attackers actively target helpdesks with impersonation calls to get MFA re-enrolled on their own device.

### Why are users approving MFA prompts they never requested?

That is push bombing in progress: the password is already stolen, so reset it. Turn on number matching, which CISA recommends wherever phishing-resistant MFA is not yet in place, and train users to report unexpected prompts. [Regular phishing simulations](/learning/why-run-regular-phishing-simulations) keep that reflex sharp.

### Do service accounts need MFA too?

Interactive MFA does not fit automation. Microsoft's mandatory MFA policy deliberately excludes workload identities (managed identities and service principals) and recommends migrating any user account used for automation to a workload identity. That is better than exempting a human-style account from MFA policy and hoping nobody finds it.

## Frequently asked questions

### Is 2FA the same as MFA?

2FA is MFA with exactly two factors, so every 2FA setup is MFA. The count matters less than the type: a single FIDO2 passkey resists phishing better than a password plus an SMS code, even though both are "two factors."

### Do passkeys on their own count as MFA?

In practice, yes. Using a passkey requires the device that holds it (something you have) plus the biometric or PIN that unlocks it (something you are or know). NIST SP 800-63B accepts syncable passkeys at AAL2; only its highest assurance level requires device-bound keys.

### Should MSP contracts mention MFA?

Yes. The joint MSP advisory recommends that customer contracts explicitly require MFA on the services delivered and on every MSP account that accesses the customer environment. Writing it into your MSA sets expectations and closes an audit gap.

### Do clients still need password managers once MFA is on?

Yes. MFA does not fix weak or reused passwords, and some legacy apps still cannot enforce a second factor, so password quality remains the only control there. A [password manager fits MSP operations](/learning/which-password-manager-is-best-for-msps-to-streamline-operations) alongside MFA rather than instead of it.

### Is weaker MFA still worth deploying if we cannot roll out FIDO2 everywhere?

Yes. CISA's position is that any MFA beats no MFA, and Microsoft's account data backs that up across methods. Deploy the strongest option each system supports today, and keep a migration path toward phishing-resistant MFA for the accounts that matter most.

## Related reading

- [How should MSPs respond to the FBI email phishing surge?](/learning/mspemailphishingfbireport2024)
- [How can IT teams prevent credential theft?](/learning/threats)
- [How can MSPs use AI to stop social engineering?](/learning/msp)