MFA everywhere: an honest rollout guide for small businesses

Last updated 2026-05-19.

The single highest-ROI security control you can deploy

If you do nothing else in 2026, deploy multi-factor authentication on every identity provider your business runs through. Microsoft, Google, and CISA all publish the same statistic with slight variations: turning on MFA blocks somewhere between 99% and 99.9% of identity-based attacks against an account.

Most SMBs do not have MFA on every account. Many have it on the owner's account, sometimes on the IT person's, and inconsistently everywhere else. The gap between "we have MFA" and "we have MFA everywhere, enforced, with a sensible exception process" is the gap between a breach you'll laugh about and a breach that prints in your local newspaper.

This guide is the honest rollout sequence. It assumes you're an owner or ops lead, that you've heard the term, and that you want to know what to actually do.

Where to start: the cloud identity blast radius

The single most important account in your business is the one that owns your cloud tenant — your Microsoft 365 global admin, your Google Workspace super admin, or your AWS root user. If an attacker takes that account, they own everything downstream: every mailbox, every shared drive, every customer record, every billing relationship.

Start there:

• Microsoft 365 — Enable Security Defaults if you're on a small Business plan that doesn't include Conditional Access. It enforces MFA on every user with no other configuration. Then turn off legacy authentication if you haven't already. If you have Business Premium or Entra ID P1+, build a proper Conditional Access policy (more on that below).
• Google Workspace — Admin Console → Security → 2-Step Verification → Enforce. Turn it on with a 14-day enrollment grace period so users have time to set up.
• AWS root — Hardware key (FIDO2/WebAuthn) on the root user. The root user should be locked in a drawer; day-to-day work happens through IAM Identity Center / SSO with MFA on every user, not the root.

Get those three right and you've protected the accounts that, if compromised, end your business.

Conditional Access vs. blanket policies

If you're on Microsoft 365 Business Premium or Entra ID P1+, you have Conditional Access. The conventional wisdom — "use Conditional Access, it's more flexible than Security Defaults" — is correct, but it comes with a sharp edge: misconfigured Conditional Access can lock everyone out, including you.

Practical rules:

1. Always start with a "report-only" policy for a week. CA can log what would have happened without enforcing. Use it. Look at the report.
2. Always have a break-glass account — a global admin account with a long random password, MFA enforced via a separate method (a hardware key locked in your safe), and CA exclusions configured so it can sign in from anywhere. Test that account quarterly.
3. Don't try to be clever. A policy that says "require MFA for all users on all cloud apps from all locations" is boring, correct, and unbreakable. Reach for trusted-IP exceptions and "compliant device" requirements only when you have a clear reason.

Blanket policies (Security Defaults, Google's 2SV enforcement) lose nothing meaningful for most SMBs under 100 users. The "advanced" CA features mostly matter at the 200+ user line, when you've got real device management and you want to be selective.

What to do about SMS

SMS-based MFA is the worst form of MFA. It's also dramatically better than no MFA, and it remains the easiest method to enroll for users who refuse to install an app.

Honest position:

• Avoid SMS for admin accounts. Always.
• Avoid SMS for finance / wire-authorizing accounts. A SIM-swap attack against your CFO is the trailhead of a six-figure wire fraud.
• SMS for everyone else is acceptable as a transition step. It is dramatically better than no MFA. If your alternative is "we won't roll it out because Brenda refuses to install Authenticator," ship SMS for Brenda and revisit in 90 days.

The migration path: enroll users on the authenticator app at the same time you give them the SMS fallback. Most will use the app; the holdouts use SMS. After 90 days, retire SMS for everyone with an app enrolled.

The dumb-cheap hardware key path

If you want to be done with phishing-against-credentials forever, the answer is FIDO2 / WebAuthn hardware keys (YubiKey, Google Titan, Feitian — they all work). They're physical USB / NFC devices the user has to touch to authenticate. They cannot be phished because the cryptographic handshake includes the actual origin of the request — a fake login page on a typosquatted domain can't trick the key.

The economics:

• A YubiKey 5 NFC is roughly $50. Two per user (one daily, one in the safe) is roughly $100 per identity.
• For 30 users, that's $3,000 in hardware. A single ransomware incident or BEC wire averages 10x to 100x that.
• The ongoing cost is approximately zero — the keys don't expire.

The deployment friction is real for the first month. Then it's invisible. Users tap a key once a day at sign-in, and that's it.

Realistic SMB scoping: keys for everyone who can sign a payment, send invoices, or access PHI / payment card data. Authenticator app for everyone else. Don't try to ship 100% keys on day one — start with your finance team, your owner, and your admins.

Microsoft Authenticator number matching

If you're on Microsoft and you haven't turned this on, do it this week.

The old way: user gets a "approve sign-in" prompt on their phone, taps Approve, in they go. The problem — MFA fatigue. An attacker who has the password just spams approval prompts until the user, half-asleep at 2am, taps Approve to make it stop.

Number matching adds a step: the sign-in screen shows a two-digit number, and the user has to type it into the app to confirm. An attacker triggering prompts from elsewhere doesn't see the number on their screen, so the user can't accidentally let them in. Microsoft made this the default in 2023, but tenants that pre-date it sometimes have to opt in manually. Confirm under Entra → Security → Authentication methods → Microsoft Authenticator → Configure.

How to handle the one user who refuses

There is always one. Sometimes it's the owner.

Three moves, in order:

1. Map their workflow. Most refusal is "this slows me down by 10 seconds, and I sign in 40 times a day." Solve that — fewer reauths with Conditional Access, persistent browser sessions, app passwords for legacy clients (last resort, audited).
2. Make the cost explicit. A real conversation: "Your cyber insurance underwriter asked for an attestation that we enforce MFA on all users. If you opt out, I have to tell them we don't — and our renewal premium goes up, or they decline."
3. Make it a policy. MFA enforcement is not a per-user negotiation. It is the same as wearing a hard hat on the floor of a construction site. The owner doesn't get to opt out; that's the entire point.

If after all three someone still won't comply — and you're the owner — terminate their account access. If you're the IT lead — escalate to the owner, in writing, with a one-paragraph risk summary. The "we couldn't enforce MFA because Greg" defense does not survive an incident.

What to do next

1. Run the Exposure Report to baseline your domain — it surfaces TLS, header, and email-auth issues that often correlate with where MFA enforcement is also weak.
2. Audit your three highest-blast-radius identity systems this week: M365 / Google admin, AWS root, and your finance platform. If any of them is missing MFA on any account, fix it before you do anything else.
3. Pick a 90-day rollout target — "100% MFA enforcement for all employees by the end of Q3." Put it on the calendar, assign an owner, send weekly progress to leadership. A goal without a date and an owner is a wish.

If you want help building the rollout plan for your specific stack and team size, start with your MSP or a qualified security consultant. Use the free Exposure Report first so the conversation starts from concrete external findings rather than guesswork.