In most tenants I've worked with this year, Azure mandatory MFA enforcement was treated as a running joke rather than a deadline. That has changed. On October 15, 2024, Microsoft started rolling out Phase 1 of enforced multi-factor authentication for interactive sign-ins to the Azure portal, the Microsoft Entra admin center and the Intune admin center. Anyone reaching these portals without MFA is now getting locked out. Microsoft is rolling it out gradually, so not every tenant is affected at the same time, but I'm already seeing enforced prompts and denied sign-ins in several production environments.

Phase 1 enforces MFA only for interactive portal sign-ins

For now, Azure mandatory MFA enforcement applies only to interactive user sign-ins to the portals listed above. Service principals, managed identities and every other kind of workload identity are explicitly excluded from this phase, so your automation keeps running as before. If you still run scripts or deployment tasks under user accounts, you need to change that. I cover the move in detail in my guide on Workload identities in Entra ID. Microsoft has also announced that phase 2 (CLI, PowerShell, IaC) will start in early 2025, so this isn't the last change.

When the rollout began, global admins could quietly request a postponement of mandatory MFA for their tenant in the Azure portal. Microsoft didn't make much noise about it, it was little more than an info banner. Honestly, in most tenants I see, pushing enforcement back just extends the risk and achieves very little. Phase 2 is close, so I'd rather spend that time cleaning up old risks and getting compliant.

The sign-in logs show who still signs in without MFA

If you run a larger environment, go through the sign-in logs now. In the Microsoft Entra admin center → Monitoring → Sign-ins, you can filter for user sign-ins to the Azure portal or Entra admin center that didn't use MFA. The fastest way is to filter on "Client app" (for example "Browser") and sign-in status. The "Required MFA" column tells you at a glance whether MFA was prompted and whether it was satisfied.

My field tip: In the sign-in logs, set the filters to “Client app: Browser” and “Resource: Azure Portal”. That surfaces every sign-in hit by the new MFA rule within seconds. Error codes such as “50076” or “50079” point to missing or failed MFA.

A short PowerShell check helps you find the most recent offenders. You'll need at least the Security Administrator role and access to the Entra admin center.

# PowerShell 7, Microsoft.Graph.SignIns module required
Connect-MgGraph -Scopes 'AuditLog.Read.All'
Get-MgAuditLogSignIn -Filter "ResourceDisplayName eq 'Azure Portal' and AuthenticationRequirement eq 'multiFactorAuthentication' and AuthenticationDetails/any(d:d/AuthenticationMethod eq null)" -Top 50

The query returns the last 50 Azure portal sign-ins where MFA was required but not completed. In real environments I'd narrow it down further to privileged accounts so you don't drown in results.

Automation should no longer run on user accounts

Automation remains a sore point in many teams. All too often, deployments and scheduled tasks run under ordinary user accounts with static passwords, and that approach is running out of time. The proper fix is to move automation to service principals or managed identities. I can't think of a valid reason to use interactive users for deployments, scripting or CI/CD anymore. Once Azure mandatory MFA enforcement reaches them, automation tied to user accounts will start failing quickly. If you still depend on client secrets, my post on replacing client secrets with workload identities walks through newer, more secure options. Workload identities don't require MFA.

Break-glass accounts need FIDO2 keys and Conditional Access exclusions

Break-glass accounts get overlooked a lot. An emergency account protected by nothing more than a password is a real risk, and enforced MFA makes that worse. Microsoft recommends keeping at least two emergency access accounts that are protected with FIDO2 security keys and excluded from Conditional Access (Microsoft emergency access guidance).

flowchart TD
    User["Admin user"] --> Portal["Azure portal"]
    Portal --> MFA["MFA check"]
    MFA -- "successful" --> Access["Access granted"]
    MFA -- "failed" --> Block["Sign-in blocked"]

Figure: MFA enforcement during Azure portal sign-in

As the diagram shows, Azure now checks for MFA on every admin portal sign-in and blocks access when the requirement isn't met. These failed attempts turn up in audit logs every week in the tenants I look after, so now is the time to track down whatever exceptions are left.

Organizations have run out of excuses for skipping MFA

In many organizations, MFA was always "urgent, but not this week". Now that Azure mandatory MFA enforcement is live for the admin portals, that attitude no longer works. Most of the tenants I work with actually gain from the pressure, because central enforcement drags long-postponed issues and insecure automation into the open. If user accounts in your tenant still reach admin portals without MFA, deal with them now. For a more structured approach, have a look at my post on Conditional Access in Entra ID: getting started.