When I look through customer tenants, I still regularly find user accounts that can sign in to the Azure portal without multifactor authentication. Usually these are break-glass accounts nobody touches, the odd technical user, or automation that still runs interactively under a privileged user. Microsoft's latest announcement targets exactly these gaps. Starting in the second half of 2024, Azure mandatory MFA will be enforced for the Azure portal, the Entra admin center and the Intune admin center. MFA enforcement for CLI, PowerShell and IaC tools will come later.

Microsoft rolls out Azure mandatory MFA in two phases

It's now official. Access to the main admin portals will soon require MFA, with no exceptions (announcement on the Azure blog, official docs). The rollout is planned to start in the second half of 2024, but Microsoft hasn't given a firm date yet. The first phase only covers browser-based access to the Azure, Entra and Intune admin centers. Azure CLI, PowerShell and infrastructure-as-code interfaces follow afterwards. Workload identities (service principals and managed identities) are explicitly not part of this change. Microsoft wants to shut down the remaining paths to admin access without MFA, independent of whatever Conditional Access policies you have configured yourself.

In my experience, the real problems show up wherever someone once made an exception: admin accounts that are hardly ever used, break-glass identities, automation scripts running under user credentials. Attackers like to go after exactly these weak spots, so Microsoft is addressing a risk that plenty of organizations still carry.

User accounts, automation and break-glass identities are where things break

Once mandatory MFA is in place, any standard user who signs in to an admin portal without MFA gets blocked. That sounds obvious on paper. In real environments it can still cause some unpleasant surprises.

Practical tip: Check your Entra sign-in logs and filter for successful logins without MFA. You'll quickly see which accounts still get around MFA, and the list is often longer than you'd think.

Break-glass (emergency access) accounts deserve extra care. They now have to be secured with FIDO2 security keys or certificate-based authentication. If they aren't, you could be locked out right when you need them. Microsoft's own guidance is to protect these accounts as strongly as possible (see the emergency access docs).

Automation is the other trouble spot. Tasks or scripts that authenticate to the portal with user credentials will simply stop working after the change. Move that automation and scripting to service principals or managed identities instead. I've described how to get from client secrets to workload identity federation in Replace client secrets: Workload identity federation in Azure.

Conditional Access stays relevant, but the baseline moves up

Many organizations already enforce MFA through Conditional Access, sometimes with exceptions for particular user groups. The new Azure mandatory MFA policy applies on top of any Conditional Access rules, which means MFA exceptions for the admin portals are no longer possible. Your own policies are still worth keeping, for example for session controls, device compliance or geographic restrictions. This is how the two fit together:

flowchart TD
    Login["User Login"] --> Portal["Azure/Entra/Intune Admin Portal"]
    Portal --> MFAMandatory["Microsoft MFA Enforcement"]
    MFAMandatory --> CA["Own Conditional Access Policy"]
    CA --> Access["Access Granted"]
    CA --> Blocked["Blocked"]

Figure: Sign-in flow with Microsoft's mandatory MFA followed by your own Conditional Access policy.

Mandatory MFA becomes the floor. Any Conditional Access policy that still allows user-based exceptions for portal access loses that effect. For now this only concerns the admin portals, and your own CA logic continues to control access to other apps and APIs.

A few steps belong on your list for the coming weeks

You can already do quite a lot to make the transition painless. This is how I usually approach these projects:

  • Audit sign-in logs for successful logins without MFA
  • Review and upgrade break-glass accounts (FIDO2/CBA required)
  • Migrate automation away from user accounts to service principals or managed identities
  • Review and, if needed, tighten up Conditional Access for admin portals

Migrating older scripts and automation often takes more effort than planned, particularly when old PowerShell modules or interactive logins are still in use. And don't leave the break-glass accounts for last. If you do, you may be locked out at the worst possible moment.

I think a bit of pressure from Microsoft does some good here

Ideally, every admin portal would already require MFA. In reality, many environments, especially larger or older tenants, still have exceptions that nobody notices anymore. The new Azure mandatory MFA policy pushes things in the right direction and finally closes the last insecure routes to admin access. If you're already prepared, there's nothing to worry about, but now is a good moment to verify that. For most tenants, this is the last nudge needed to clear out what's left of older security practices.

If you review your environment regularly and already use approaches like Temporary Access Passes and modern authentication, you're well placed. I welcome mandatory MFA in the admin portals, and it's a good reason to take another look at how you handle admin access in general.