Mandatory MFA for the Azure Portal Begins (Oct 2024)

Retrospective: this article looks back at events from October 2024, written in 2026 with the benefit of hindsight.

Starting October 15, 2024, Microsoft began enforcing multi-factor authentication for users signing in to the Azure portal, the Microsoft Entra admin center and the Intune admin center. It rolled out gradually to all tenants as Phase 1 of a broader program tied to Microsoft's Secure Future Initiative.

1. Announcement2024: Microsoft announces mandatory MFA for Azure and admin portal sign-ins as part of its Secure Future Initiative.
2. Phase 1October 15, 2024: enforcement rolls out for the Azure portal, Microsoft Entra admin center and Intune admin center.
3. Postponement optionOrganizations needing more time can request a delay, initially into 2025.
4. Phase 2From 2025: enforcement extends to Azure CLI, Azure PowerShell and infrastructure-as-code tools.
5. Automation breaksScripts signing in as user accounts with passwords stop working; workload identities are unaffected.

Phase 2, rolling out from 2025, extended enforcement to the Azure CLI, Azure PowerShell and infrastructure-as-code tools that manage Azure resources. Organizations that needed more time could request a postponement.

For most well-run tenants, nothing changed: administrators were already using MFA. For others, Phase 2 exposed something important — automation that signed in as a person.

What the requirement covers

• Users signing in to the covered portals and tools to manage resources — not only administrators.
• Enforcement applies regardless of your Conditional Access policies or Security Defaults settings.
• Workload identities — managed identities and service principals — are not in scope.
• Users can satisfy the requirement with the Microsoft Authenticator app without additional licenses; other methods may depend on your Entra ID licensing.

What breaks

User accounts used as service accounts. Many organizations run scripts, scheduled tasks, deployment pipelines or third-party tools that sign in to Azure as a user — svc-deploy@contoso.com with a password stored somewhere. Those accounts can't complete MFA interactively, so Phase 2 breaks them.

Break-glass accounts without MFA. Emergency access accounts that were excluded from MFA need a method that works during a crisis. Microsoft's guidance points to strong methods such as FIDO2 security keys or certificate-based authentication.

Third-party tools that connect to Azure using user credentials need updates.

Why it mattered

Microsoft stopped making MFA optional for cloud administration. Attacks on cloud management access are common and damaging; Storm-2949's 2026 campaign, for example, used compromised identities' Azure RBAC permissions to reach Key Vaults, storage and virtual machines. Mandatory MFA raises the baseline.

It forced long-overdue cleanup. User-based automation is fragile and risky: passwords rarely change, the accounts often hold broad permissions, and they're hard to monitor. Workload identities are better in every respect.

What to do now

1. Find user accounts used for automation. In Entra sign-in logs, filter by applications such as Azure Portal, Microsoft Azure CLI, Microsoft Azure PowerShell and the Windows Azure Service Management API. Look for accounts signing in from servers, build agents or fixed IP addresses, accounts named like services, and accounts with Conditional Access exclusions.
2. Choose the right workload identity. Use a managed identity for automation running in Azure (VMs, Functions, App Service, Automation, AKS). Use a service principal with workload identity federation for GitHub Actions, Azure DevOps and other CI/CD — no secrets. Use a service principal with a certificate, or Azure Arc–enabled servers with managed identity, for automation running on-premises or in other clouds.
3. Grant least-privilege Azure RBAC. Assign only the roles the automation needs at the narrowest scope — resource group or resource, not subscription.
4. Update scripts. For example, az login --identity or Connect-AzAccount -Identity for managed identities; federated or certificate sign-in for service principals; OIDC or managed identity authentication in Terraform and other IaC providers.
5. Retire the old accounts. Disable user-based service accounts after verifying automation works, then delete them.
6. Prepare break-glass accounts. Register FIDO2 security keys or certificate-based authentication, store them securely and test sign-in.
7. Go further than the minimum. Require phishing-resistant MFA for privileged Azure roles through Conditional Access authentication strengths, and use Privileged Identity Management for Owner and Contributor roles.

How to monitor compliance

• MFA failures on Azure management apps in sign-in logs point to scripts or users who aren't ready.
• Non-interactive user sign-ins to Azure Resource Manager from servers suggest remaining user-based automation.
• Service principal sign-ins from unexpected IP addresses indicate workload credentials that need attention.
• Azure Activity logs show which identities make changes; any user account performing large volumes of automated changes deserves review.

Common mistakes

• Excluding service accounts from Conditional Access instead of replacing them.
• Creating service principals with client secrets that never expire. Prefer federation and certificates; set short lifetimes.
• Granting Owner to automation "to be safe."
• Forgetting third-party tools that manage Azure on your behalf.

Why MFA alone isn't the finish line

Mandatory MFA raises the floor, but identity-led attacks against Azure continue. In May 2026, Microsoft described Storm-2949, an actor that social-engineered users during self-service password reset, convinced them to approve fraudulent MFA prompts, removed legitimate MFA methods, and then used the compromised identities' Azure RBAC permissions to reach Key Vaults, App Services and storage accounts. It used VM extensions and Run Command to take over virtual machines, installed remote access software and disabled Microsoft Defender Antivirus.

Microsoft's recommended mitigations go well beyond the mandatory baseline: phishing-resistant MFA for administrators, Conditional Access with device compliance, least privilege for Azure RBAC, restrictions on VM extensions, private endpoints, immutable storage and diligent logging. Treat mandatory MFA as the starting point for Azure administration security, not the end state.

Questions for leadership

• Do any automated processes still sign in to Azure as a person?
• Do our emergency administrator accounts have MFA that will work in a crisis?
• How many people hold permanent Owner or Contributor rights in Azure?

Key takeaways

• Microsoft enforces MFA for Azure portals from October 15, 2024 and for CLI, PowerShell and IaC tools from 2025.
• Workload identities aren't affected; user accounts used for automation are.
• Migrate automation to managed identities and federated service principals with least-privilege RBAC.
• Prepare break-glass accounts with FIDO2 or certificate-based authentication.