Why this matters
A password alone is a single secret. If it leaks, anyone can sign in as that user. MFA adds a second proof, such as a phone app approval, a FIDO2 key, or a certificate. For Azure, the user directory is Microsoft Entra ID, formerly Azure AD. Enforcing MFA there protects the Azure portal, the command line, Microsoft 365, and any app that trusts the tenant.
The hard part is not turning on MFA for one admin. It is covering every user without locking out a team or breaking an old app. Contractors, guests, shared accounts, and service accounts need a plan. Legacy protocols need to be blocked because they cannot complete an MFA prompt. A good rollout is phased: report, register, enforce, then verify.
This guide uses Conditional Access as the main control. It is the current Microsoft tool for rules like require MFA for all users. Security defaults are a simpler fallback for small tenants. Per-user MFA is the old switch and should not be your long term design.
Before you start
Confirm the license. Conditional Access needs Microsoft Entra ID P1 or higher for each user who will be covered. Check tenant properties and assigned licenses. If you do not have P1, use security defaults for a broad baseline, or buy the right license. Do not mix security defaults and Conditional Access without knowing which one is active.
Find the accounts that cannot use MFA in the normal way. List break-glass admins, service accounts, test accounts, and any shared mailbox that someone signs in to. Break-glass accounts should be cloud-only, have long random passwords, and be excluded from the all-user policy. Keep them out of daily work. Monitor every sign-in.
Decide your methods. Allow Microsoft Authenticator with number matching, FIDO2 security keys, and Temporary Access Pass for onboarding. Keep SMS and voice only if you must support users without smartphones. For admins, plan a stronger rule with phishing-resistant MFA, such as FIDO2 or certificate-based authentication.
Tell users what will change. Give a date, a short guide, and a support path. Check that your help desk can issue a Temporary Access Pass. Test with a pilot group that includes Windows, macOS, mobile, VPN, and any line-of-business app that signs in to Azure.
How to do it
Start in report-only mode. Create a Conditional Access policy that targets All users and all cloud apps, exclude your break-glass group, and grant Require multifactor authentication. Set the policy to Report-only. This shows who would be challenged without blocking them. Use the What If tool and sign-in logs to find gaps.
Run a registration campaign. In Authentication methods, enable the methods you chose and turn on the registration campaign. Set the snooze period to zero days so users cannot defer. For new users, issue a Temporary Access Pass so they can register a strong method at first sign-in. Then move the policy from Report-only to On.
Block legacy authentication with a second policy. Target All users and all cloud apps, conditions Client apps, and select Exchange ActiveSync clients and Other clients. Grant Block. Do this after you find any scanner or mail app that still uses basic auth. Then add a stricter policy for privileged roles that requires phishing-resistant MFA.
- Map users, guests, and service accounts. Export the user list from Microsoft Entra ID and mark every account that signs in interactively. Separate guests, shared accounts, and service accounts. Decide which ones will be excluded from the all-user policy and why.
- Create a break-glass group. Create two cloud-only admin accounts and put them in a dedicated group. Give each a long random password, store it offline, and exclude the group from Conditional Access. Alert on any sign-in to these accounts.
- Enable authentication methods. In Authentication methods, enable Microsoft Authenticator, FIDO2 security keys, and Temporary Access Pass. Turn on number matching and additional context for Authenticator. Disable unused methods such as SMS if your user base allows it.
- Run the registration campaign. Open the registration campaign and set it to Enabled. Set the snooze days to zero so users must register at next sign-in. Send a notice with the start date and the help desk contact.
- Build the all-user MFA policy. In Conditional Access, create a policy named Require MFA for all users. Target All users and All cloud apps, exclude the break-glass group, and grant Require multifactor authentication. Start in Report-only.
- Block legacy authentication. Create a second policy that targets All users and All cloud apps. Under Client apps, select Exchange ActiveSync clients and Other clients, then grant Block. Enable it after you confirm no critical app depends on basic auth.
- Require stronger MFA for admins. Create a policy for privileged directory roles and a group that contains Azure subscription owners. Grant Require authentication strength and choose Phishing-resistant MFA. Keep a documented exception process for any admin who cannot use a FIDO2 key.
- Turn policies on and watch. Move the all-user policy from Report-only to On during a low-risk window. Keep the legacy block and admin policy on. Watch sign-in logs and the help desk queue for the first week.
How to check it worked
Use the User registration details report in Authentication methods. Filter for users who are not MFA capable or have no method registered. Follow up with each one. Check guests separately because their home tenant may satisfy MFA.
Open Sign-in logs and filter for successful sign-ins without MFA. Look at the Authentication details tab. A user who signs in with only a password is a gap. Also check the Conditional Access tab to confirm the policy applied and was not skipped by report-only mode.
Run the What If tool for a normal user, a guest, an admin, and a break-glass account. Confirm the expected result for each. Review audit logs for policy changes. Ask the help desk for a list of MFA reset requests and look for patterns.
Test a real sign-in from a new device and from an old mail client. The new device should prompt for MFA. The old client should be blocked if it uses legacy auth. Repeat the test after any policy change.
Mistakes to avoid
Do not exclude a large group just to avoid tickets. Every exclusion is a hole. Keep the break-glass group small and review it monthly. Do not let break-glass accounts use the same password or the same phone.
Do not turn on the all-user policy before registration. Users who have no method will be blocked. Do not rely on per-user MFA as your long term control because it is harder to scope and report. Do not forget guests, because All users includes them.
Do not block legacy auth without checking scanners, printers, and old mail clients. Do not allow SMS for admins when you can issue a FIDO2 key. Do not ignore service accounts that sign in with a password. Convert them to managed identities or workload identity federation where possible.
Do not treat the rollout as finished on day one. Check the registration report each week, review sign-in logs after staff changes, and test break-glass access. If you want an outside check, the Cloud security review from Cloudverg is a fixed price of $6,500 and includes an identity and access review across up to 5 cloud accounts or subscriptions.
Frequently asked questions
Does Microsoft Entra ID P1 cover MFA for all users?
Conditional Access requires a license that includes it, typically Microsoft Entra ID P1 or higher. Security defaults are included with the free tier and can enforce MFA for all users, but they offer fewer exclusions and controls. Check each user's assigned license before you build Conditional Access policies.
What is a break-glass account in Azure?
A break-glass account is an emergency admin account that is excluded from Conditional Access so you can regain access if a policy or MFA method fails. Create two, keep them cloud-only, store their credentials offline, and alert on every sign-in. Do not use them for daily work.
Can I enforce MFA for guests in Azure?
Yes. A Conditional Access policy that targets All users includes guest accounts. Guests may satisfy MFA from their home tenant, so test a real guest sign-in before you enforce. If a guest cannot register a method, use a Temporary Access Pass or adjust the policy for that external domain.