Rolling out MFA to 40-100 users in Microsoft 365 without a lockout storm

You'll learn

• The exact Conditional Access policy structure we stand up for every 40-100 person tenant (seven policies, in a specific order).
• How to segment users into pilot / tier-2 / full-rollout cohorts so ticket volume stays predictable.
• The break-glass account setup that catches the 10% of edge cases a staged rollout won't.

Why this matters (the cost of getting it wrong)

We've done this on four different M365 tenants in the last year. On the one where a previous MSP had flipped "enforce MFA for all users" in a single change, day one produced 23 support tickets in the first four hours. The CFO couldn't log in from the hotel Wi-Fi he was traveling on; the warehouse supervisor got locked out because the Authenticator app was never enrolled on his secondary phone; the bookkeeper's iPad prompted for MFA on Outlook and she didn't recognize the app so she ignored it until the account was blocked.

None of those are unusual. What's unusual is how avoidable they were.

The business context matters too. Cyber insurance underwriters now ask for MFA attestation in the initial application; a partial rollout (admins only, everyone else "coming soon") is increasingly rejected as insufficient. Every 90-day extension costs real premium. But the Monday-morning lockout is what clients actually remember — and it's what shapes their opinion of the MSP running the change.

This guide is the playbook we use to land MFA cleanly. It's opinionated, it's specific to M365 Business Premium or higher (you need Conditional Access, which means an Entra ID P1 license or the CA rights that come with Business Premium), and it assumes you're the person driving the rollout.

The setup our field team uses

Before touching a single policy, lock down these choices:

• Authenticator method: Microsoft Authenticator with number matching. Push notifications without number matching were the target of the 2022-2024 MFA fatigue attacks; Microsoft started enforcing number matching by default in 2023. Don't allow SMS as a fallback unless you have a specific compliance reason — SIM swap attacks are cheaper than phishing now.
• Break-glass accounts: Two cloud-only admin accounts with complex passphrase-style passwords stored in your password vault, explicitly excluded from all Conditional Access policies. You will thank yourself.
• Named per-client rollout window: Three weeks, starting on a Monday. Don't try to do it over a weekend "so no one notices" — you want people online and reachable when the policy kicks in.
• Change window comms: One week before kickoff, one day before, morning-of. Phrased as operational, not as a security mandate — "starting Monday, signing in will ask for a code from your phone. Here's how to set it up."

Tools we actually use:

• Microsoft Entra admin center (no third-party CA orchestrators needed for this size tenant).
• Authenticator app enrollment link distributed via email + printed QR code in a physical handout.
• Our RMM for endpoint inventory — specifically to identify users who are on unsupported devices before Conditional Access blocks them.

Step 1 — Prep work that prevents 90% of tickets

The prep week is where 90% of the rollout succeeds or fails. Four things, in order.

1.1 Inventory identity edge cases

Pull a list from Entra of every user and flag:

• Shared mailboxes (not sign-in enabled — should be disabled for sign-in but often aren't). Confirm none are actively being used as login accounts.
• Service accounts / unattended sign-ins (scheduled tasks running as a user, legacy apps with saved credentials). These need to be moved to Workload Identities or given a specific CA exclusion — MFA on an unattended account is an operational breakage waiting to happen.
• External collaborators / B2B guests. Default CA policies typically don't enforce MFA on guests out of the tenant, but if you're hardening, explicitly policy this.
• Users on devices that can't run Authenticator. Rare at 40-100 employees, but warehouse staff with feature phones or seasonal workers with no personal mobile plan will surface here. Provision them a hardware key (YubiKey 5C NFC works for M365) or put them in a specific cohort with different requirements.

Expected outcome: a spreadsheet with every user tagged pilot / tier-2 / full / excluded. Without this, you're guessing which cohort someone belongs in when they call.

1.2 Provision break-glass accounts

Two accounts, both cloud-only, both Global Admin, both excluded from every CA policy. Example naming: [email protected] and breakglass-2@....

The passphrase should be 40+ characters and stored in two places your team can access without M365 (your password vault + a printed-and-sealed envelope in the office safe). Enable audit logging alerts for any sign-in from these accounts — if they ever get used, you want to know within five minutes.

Why two? Because Murphy. If one account is compromised or locked out during an incident, the other is your fallback. Two is the minimum; four is what a larger tenant should have.

1.3 Stand up the seven CA policies (but don't enable them yet)

The seven policies we deploy on every rollout, in "Report-only" mode initially:

1. Block legacy authentication. Basic auth is a ransomware vector; kill it before MFA. Exclude only accounts that genuinely need it (rare at this size) and plan to migrate those off.
2. Require MFA for all users. The headline policy. Targets all users, excludes break-glass + service account groups.
3. Require MFA for admins. Redundant with #2 if #2 covers admins, but scoping it separately gives you a kill switch if #2 has to be temporarily relaxed.
4. Block sign-ins from unsupported country regions. If your business is Canada + US, block sign-ins from outside North America. You can always add specific regions back for travel.
5. Require compliant or hybrid-joined device for admin access. Elevates the bar for admin accounts specifically.
6. Block Entra registration campaign from unmanaged devices. Stops drive-by app registrations in compromised-credential scenarios.
7. Require MFA for Azure management. Separate policy because the scope is the Azure portal / ARM specifically — you want this explicit.

Keep all seven in Report-only mode initially. This means Entra logs what the policy would have done without actually enforcing it. Give it 48-72 hours of production traffic and review the "Conditional Access - Report-only" report in the sign-in logs. You're looking for: which users would have been blocked that shouldn't have been (a service account you missed), and which sign-ins would have required MFA but didn't get prompted (a session that predates the policy).

1.4 User communication

Write three emails. The first goes out one week before pilot kickoff:

Subject: Starting Monday the 5th — your phone becomes part of your login

On Monday, signing into email and Teams will ask for a one-time approval from your phone. This is called MFA; it's what prevents someone else from logging in as you even if they get your password.

Before Monday, please install the Microsoft Authenticator app. We've attached the one-page setup guide. If you don't have a company phone and don't want to use your personal phone, reply to this email and we'll get you a security key.

Questions: [your ticket system]. We'll be onsite / on-call all of Monday to walk people through the first sign-in.

No jargon. No "security posture improvement initiative." Operational language. People respect that.

Step 2 — Staged rollout, cohort by cohort

Now the policies come out of Report-only in order.

Week 1: Pilot cohort (5-10 users)

Pick the pilot cohort carefully:

• Two IT or tech-comfortable staff (they'll self-troubleshoot).
• One executive (they'll raise issues that affect the wider rollout — board meeting login, hotel Wi-Fi, two laptops).
• One receptionist or front-desk (highest device-switching frequency; often the first to hit edge cases).
• One field staff (mobile-only; exposes iOS/Android differences).

Flip Policy #1 (Block legacy auth) and Policy #2 (Require MFA) out of Report-only for this group only. In the Entra policy, set the "Users" scope to a specific group; add the 5-10 pilot users to that group.

Monitor for 5 business days. Specifically track:

• Ticket volume — the pilot is a dress rehearsal. Every ticket you handle in week 1 is a ticket you don't handle with 40 users at once in week 3.
• Sign-in success rate for the cohort (Entra sign-in logs).
• App compatibility — anyone still using Outlook 2016? Legacy Mac Mail? This is when those surface.

Issues we've hit most often at this stage:

• Old iOS Mail app using basic auth — switch them to native Outlook app.
• Shared device in a break room that everyone logs into — decide now whether to treat it as a kiosk, provision a dedicated user, or retire it.
• Someone's personal Android phone where corporate policy blocks Authenticator installs — either allow it or issue a hardware key.

Week 2: Tier-2 cohort (20-30 users)

Once the pilot is quiet (no new tickets for 48 hours), expand. Add the tier-2 cohort to the pilot group. This is everyone except:

• Users flagged as needing hardware keys (provisioned separately).
• Field staff whose schedule means they'll miss the rollout comms window (roll them in week 3 with extra one-on-one time).
• Service accounts + break-glass (permanently excluded).

Monitor another 3-5 business days. Ticket volume should be higher than pilot proportionally but not alarming — maybe 2-4 tickets per 10 users.

Week 3: Everyone else + enable remaining policies

By week 3 you've stress-tested Policies #1 and #2 with a meaningful cohort. Now:

• Add remaining users to the enforcement group.
• Take Policies #3-7 out of Report-only.
• Announce the rollout is complete.

Don't skip the completion announcement. "MFA is now on for everyone — if you ever get a prompt you weren't expecting, report it immediately" primes users to be a phishing tripwire. That's the long-tail value of a rollout.

Step 3 — Monitoring and break-glass readiness

3.1 The Conditional Access audit dashboard

Build (or configure) a dashboard that shows:

• Daily count of CA policy denials (expect a baseline; watch for spikes).
• Sign-ins from new countries.
• Break-glass account sign-ins (should be zero except for drills).
• Users with repeated MFA prompt failures (usually signals phishing attempt, phone theft, or an angry ex-employee who isn't using their Authenticator).

If you're on Microsoft Defender for Cloud Apps or Sentinel, you get much of this out of the box. If you aren't, the Entra sign-in logs + a scheduled export to your SIEM suffice.

3.2 The quarterly break-glass drill

Every 90 days, one of your admins signs in using a break-glass account, documents the sign-in, and rotates the password. This does three things:

• Confirms the break-glass account still works (passwords expire, MFA exclusions sometimes get inadvertently modified).
• Creates an audit record.
• Rotates the credential on a predictable cadence.

Set a calendar reminder. This is the single most-skipped step we see when we onboard a client who "already has MFA rolled out."

3.3 Authenticator app health

Once a quarter, pull the list of users whose Authenticator registration is stale (no sign-in confirmation in 60+ days). Usually these are people who got a new phone and forgot to re-enroll. Reach out proactively — don't wait for them to lock themselves out the day they need to sign a contract from an airport.

The mistakes we see most often

1. Skipping break-glass accounts. This is the number one post-rollout emergency we get called in to fix. Someone deletes a CA policy by accident, or a policy blocks Global Admins during an outage, and suddenly the only way in is to open a Microsoft support ticket. With break-glass accounts, the fix is two minutes; without them, it's a business-day delay.

2. Rolling out to everyone at once. Even in a 40-person company, a same-day rollout produces a queue of tickets that exceeds what one engineer can resolve in real time. By the time you get to ticket 15, the first ten have reached an executive who's asking why this wasn't smoother.

3. Treating legacy auth as optional. Leaving basic auth enabled "until we can migrate Bob's ancient scanner" means every password spraying attack that would otherwise fail against MFA-protected accounts succeeds against any account still using basic auth. The scanner is easier to replace than the incident.

4. Not separating MFA for admins. Admin compromise is the worst-case path. Even within an MFA-everywhere posture, a separate admin-only policy with stricter requirements (compliant device, shorter token lifetime) gives you defense-in-depth.

5. Assuming cyber insurance will accept partial MFA. Underwriters now require attestation that MFA covers administrative and user accounts. A common shortcut — "we MFA our admins" — increasingly triggers premium surcharges or coverage exclusions.

If you want help with this

We run this play for clients on a regular cadence — usually as part of a broader managed-IT engagement but sometimes as a standalone project. The three-week timeline, the seven CA policies, and the break-glass discipline are the shape of the engagement. If you'd like us to do it (or review what you've already stood up), the fastest path is the free IT health check — a 90-minute session with a senior engineer, no sales pitch, scored roadmap yours to keep.

Further reading

• Volume 2: SOC 2 Type II for a 50-person services firm — what 12 months actually costs. MFA is one of the controls your auditor will ask for evidence of; this volume covers the rest.
• Volume 3: Microsoft 365 backup that actually restores. If MFA is your access control, backup is your recovery guarantee. Both or neither.
• Volume 7: Shadow AI and Copilot data-residency governance. The next frontier after MFA — once sign-ins are locked down, the question becomes what those signed-in users are sending to public LLMs.
• Managed Cybersecurity — the service page for clients who want all of this run as a monthly engagement.