AD1.3 Deploying MFA Without Breaking Everything

Step 1: Prepare (days 1-2)

Before you touch any policy, do four things.

Create break-glass accounts. Navigate to entra.microsoft.com → Users → New user → Create user. Create two accounts with names that don’t advertise their purpose — “svc-emergency-alpha@yourdomain.com” and “svc-emergency-bravo@yourdomain.com” work. Assign both the Global Administrator role. Set passwords to 25+ characters, randomly generated — use a password generator, not a memorable phrase. Write each password on a separate piece of paper and store them in a physical safe or sealed envelope in two different locations (one on-site, one with the IT manager off-site). Do NOT register these accounts for MFA. Do NOT use these accounts for anything except emergencies. Set up an alert for any sign-in to these accounts — any activity on a break-glass account that isn’t a planned test is a critical security event.

Audit legacy authentication. Navigate to entra.microsoft.com → Monitoring → Sign-in logs. Filter by “Client app” → select “Exchange ActiveSync,” “IMAP4,” “POP3,” “SMTP,” “Authenticated SMTP,” and “Other clients.” Set the time range to 30 days. Export the results to CSV. For each entry, record the username, the client app, and the device. This is your legacy auth dependency list. Every entry represents an authentication that bypasses MFA.

Common findings: users running Outlook 2013 or earlier (upgrade to current Outlook), multifunction printers sending email via SMTP (configure modern auth or use an SMTP relay with app password), legacy CRM or ERP systems authenticating via IMAP (contact the vendor about modern auth support), and mobile email clients using Exchange ActiveSync with basic auth (configure the native Outlook app instead).

Identify exceptions. Walk through your user list and flag accounts that will need special handling: shared mailboxes (can they be converted to Microsoft 365 groups?), room/resource accounts (do they need interactive sign-in?), service accounts (can they use managed identities or certificate-based authentication?), and users without smartphones (FIDO2 keys or temporary access passes).

Draft the user communication. Keep it brief, non-technical, and reassuring. Something like: “We’re strengthening account security across the organisation. Over the next two weeks, you’ll be asked to set up Microsoft Authenticator on your phone. This adds a second layer of protection to your account — when you sign in, you’ll confirm it’s really you by approving a notification on your phone. The IT team will be available to help with setup. If you don’t have a smartphone, please let us know and we’ll arrange an alternative.”

Step 2: Registration campaign (days 3-16)

Send the communication and start a 14-day registration window. During this window, users are prompted to register for MFA when they sign in but are not required to complete MFA for access. This is the grace period where users set up Microsoft Authenticator at their own pace.

Track registration daily. Navigate to entra.microsoft.com → Protection → Authentication methods → Activity → Registration. The goal is 95%+ registration by day 14. If you’re below 90% by day 10, send a reminder. If specific users haven’t registered by day 12, contact them individually — they may need help or may have a legitimate blocker you need to address.

If you’re currently on security defaults, users who have already registered for MFA (your current 87% at NE) don’t need to re-register. Their existing MFA registration carries over to conditional access. The registration campaign targets the 13% who haven’t registered yet.

For users who genuinely cannot install Microsoft Authenticator — no smartphone, shared device, contractual restrictions — provide the alternative you identified in Step 1. FIDO2 security keys are the preferred alternative. Temporary access passes work for short-term situations. SMS is the last resort.

Step 3: Pilot with the IT team (days 17-19)

Create a conditional access policy targeting a pilot group (the IT team). Navigate to entra.microsoft.com → Protection → Conditional Access → New policy. Configure it as follows:

Name: “CA001 - Require MFA - Pilot.” Assignments: Users → Include → Select users and groups → select your IT team group. Cloud apps: All cloud apps. Conditions: leave all conditions at default (no filters). Grant: Require multifactor authentication. Session: leave at default. Enable policy: On.

Sign out and sign back in from your admin account. You should be prompted for MFA. Test from your desktop, your phone, and a personal device. Verify the sign-in log shows “MFA requirement: MFA via conditional access policy” in the authentication details. Test from a device that isn’t enrolled in Intune — you should still be able to sign in (the device compliance policy comes later), but MFA should be required.

Test the break-glass accounts. Sign in to one break-glass account from a private browser. It should NOT be prompted for MFA because break-glass accounts aren’t in the pilot group and won’t be in the all-users policy either. Verify this works before you expand to all users — if break-glass accounts are accidentally included in the MFA policy and you haven’t registered them for MFA, you’ll lock yourself out.

Document any issues. If a specific application doesn’t work with conditional access, note it for exception handling. If the sign-in experience is confusing for any pilot user, improve the communication before broad rollout.

Step 4: Enforce for all users (day 20)

Edit the pilot policy or create a new one targeting All Users. Navigate to the conditional access policy and change the assignment from the pilot group to “All users.” Add an exclusion for the break-glass accounts group (create a group containing your two break-glass accounts and add it to the “Exclude” section).

The moment this policy is active and security defaults is disabled, every sign-in in your tenant requires MFA. Users who registered during the campaign will be prompted for MFA on their next sign-in — a smooth experience. Users who didn’t register will be prompted to register before they can access anything — which is why the registration campaign in Step 2 is critical. The fewer users who hit this forced registration, the fewer helpdesk calls you receive.

Monitor the first 48 hours closely. Check the sign-in logs for failed sign-ins — these are users who couldn’t complete MFA. Check the Defender portal for any new alerts triggered by the policy change. Keep the helpdesk informed that MFA is being enforced and give them the troubleshooting guide: “If a user can’t sign in, check whether they’ve registered for MFA. If not, walk them through registration. If they have registered but the prompt isn’t appearing, check whether their Authenticator app needs updating.”

Step 5: Validate (days 21-23)

Run the validation checks. MFA registration rate should be 100% for accounts that are actively used (navigate to Authentication methods → Activity → Registration). Legacy authentication sign-ins should be zero (sign-in logs filtered by legacy client apps — if you haven’t blocked legacy auth yet, this is the next policy you build in AD1.4). Break-glass accounts should have no MFA registration and should successfully sign in without MFA (test this).

Check the sign-in log for the first 72 hours after enforcement. Look for any failed sign-ins from legitimate users that indicate the policy is blocking something it shouldn’t. Look for any successful sign-ins without MFA that indicate a gap in the policy. A clean sign-in log with MFA on every sign-in means the deployment is complete.