If you manage a Microsoft 365 tenant. Mandatory MFA enforcement already covers key admin portals, with more services joining on a phased timeline. Verify your tenant’s current settings today, confirm that admin and in-scope user accounts are registered, and set up break-glass emergency accounts before you touch anything else. Privileged roles should move to phishing-resistant methods first, and Conditional Access gives you the control to stage the rest of the rollout safely.
TL;DR:
- Verify which MFA enforcement phases apply to your tenant, focusing on admin portals first, and confirm account registration status before making changes.
- Use security defaults for small tenants or straightforward needs, but transition to Conditional Access to enable staged rollouts and role-based authentication policies.
- Prioritize enrolling all users with a second factor before upgrading privileged accounts to phishing-resistant methods like FIDO2 keys or Windows Hello.
- Prepare emergency access accounts, communicate clearly with users, and staff support teams during initial rollout waves to prevent account lockouts and support overloads.
- Use mitigation procedures like enforcement postponement scripts temporarily if users get locked out, but only as a short-term fix while completing registration and setup.
Microsoft’s mandatory MFA enforcement rolled out in stages rather than all at once, and knowing which stage applies to your tenant tells you what to prioritize this week. The first phase covered core admin portals, including the Azure portal, Microsoft Entra admin centre, and Intune admin centre, starting in October 2024. The Microsoft 365 admin centre followed in February 2025, and enforcement for command-line tools and automation, including Azure CLI, PowerShell, and infrastructure-as-code clients, arrived in later phases.
This matters because the enforcement is service-side. Microsoft can require MFA for these sign-ins even if your tenant has no Conditional Access policy written yet. That is different from your own tenant-level MFA policy, which still needs to be built and maintained separately for durable, granular control.
A few things to confirm before you plan further work:
Licence type changes what tools you have available, which is why the next step is confirming exactly where your tenant stands.
Before changing any policy, confirm what is already active in your tenant and who still needs to register. This keeps you from duplicating controls or missing gaps that cause support tickets later.
Licence tier has a real effect here. Our Microsoft 365 licensing guide walks through how P1 versus P2 features change what verification and automation options are available to your admins. Tenants still running legacy per-user MFA alongside security defaults are the most common source of registration confusion, so resolving that overlap early saves helpdesk time down the line.
Security defaults give every tenant a free baseline: Microsoft Authenticator notifications become mandatory for registration, and tenants created after October 22, 2019 generally already have security defaults turned on, with a short grace period for new accounts to register. That baseline works well for small tenants with straightforward needs. Once you need staged rollouts, exclusions, or different authentication strength for different roles, Conditional Access is the better long-term mechanism.
For privileged accounts specifically, both Microsoft and CISA recommend phishing-resistant MFA wherever feasible. That means FIDO2 security keys, Windows Hello for Business, Entra certificate-based authentication, or device-bound passkeys. When none of those is deployable yet, CISA’s guidance is to enforce some form of MFA rather than leave the account unprotected.
Practical steps for most tenants:
Device management matters too. Requiring a managed device for MFA registration reduces the chance that an attacker registers their own authenticator on a compromised account, a point covered in our Intune device management setup guide.
Pro Tip: Treat security defaults and Conditional Access as a baseline-then-upgrade pair, not two competing systems: migrate off per-user MFA entirely before layering in Conditional Access rules.
A rollout plan with clear checkpoints prevents the two failure modes that actually hurt tenants: a helpdesk surge from confused users and locked-out accounts with no recovery path.
Mixing security defaults, legacy per-user MFA, and Conditional Access during this period is the most common planning mistake we see. Pick one mechanism as your end state and retire the others on a fixed date.
When a user gets locked out, requiring re-registration from Entra ID > Users > Authentication methods clears their stored phone numbers, Microsoft Authenticator app, and software OATH tokens, forcing a clean re-enrollment. You can also revoke active sessions from the same blade, and cross-reference sign-in logs to catch service accounts or automation that broke when MFA enforcement hit a non-interactive sign-in.
Rollouts stall for predictable reasons: pilot groups that skip unmanaged devices, a helpdesk that was not staffed for the surge, or exclusions nobody documented. As a SOC 2 Type II certified provider running a 24/7 NOC, we help teams fix exactly these gaps, from Conditional Access template design to post-rollout monitoring through our Microsoft 365 optimization work.
Enrollment first, authentication strength second: that sequencing is what keeps a rollout from turning into a helpdesk incident.
Treat this as two milestones, not one project. Milestone one is universal registration: every admin and in-scope user has a working second factor. Milestone two is strength: moving privileged roles to phishing-resistant methods and tightening Conditional Access rules. Trying to do both at once usually means slower enrollment and higher support costs, with device management dependencies adding friction neither phase actually needs yet.
— Geeshan
We built our managed IT practice around exactly this kind of identity work: Microsoft 365 optimization, Conditional Access policy design, and SOC-backed monitoring that keeps watching after the rollout is done. Several of our clients came to us mid-rollout, after a pilot group stalled or a helpdesk got overwhelmed by registration tickets.
If you want a second set of eyes on your rollout plan, our managed IT services team can scope an assessment and tell you exactly where your tenant stands.
Yes, Microsoft enforces MFA for sign-ins to specific admin portals on a phased schedule, starting with the Azure portal and Entra admin centre in October 2024, followed by the Microsoft 365 admin centre and command-line tools in later phases. This enforcement applies at the service level, independent of whatever Conditional Access policy your tenant has configured.
You can turn on security defaults for a quick tenant-wide baseline, or build Conditional Access policies for more granular control over which users, apps, and risk levels require MFA. Most tenants start with security defaults and move to Conditional Access once they need staged rollouts or exceptions.
Repeated MFA prompts usually mean your device or browser session isn’t being recognized as trusted, or your organization’s Conditional Access policy requires re-authentication more frequently for certain apps or risk conditions. Clearing cached credentials, confirming the device is registered, or checking with your administrator about session lifetime settings usually resolves it.
Supported methods include Microsoft Authenticator push notifications, SMS and voice codes, software OATH tokens, and phishing-resistant options like FIDO2 security keys, Windows Hello for Business, and certificate-based authentication. CISA and Microsoft both recommend prioritizing the phishing-resistant options for privileged accounts whenever your environment supports them.
The guidance above draws on Microsoft’s own procedural documentation and CISA’s published security baselines, both of which get updated as enforcement phases progress. Bookmark these for the exact PowerShell commands, verification steps, and policy language you’ll need when you run the rollout yourself.
%20(1).avif){kind=logo}
%201.avif)
