Although Douglas Adams is probably best known for writing Hitchhiker’s Guide to the Galaxy, you’ve probably heard one of his famous, often-misattributed quotes: “I love deadlines. I love the whooshing noise they make as they go by.” Microsoft has definitely been prone to issuing deadlines that then go zooming past without any action, but over the last few years, they have generally stuck to the deadlines they set, particularly when the deadline has something to do with security. The latest example is rapidly approaching: on October 1, 2025, Microsoft will roll out the second phase of its multi-factor authentication (MFA) enforcement for Azure services.
Phase 1 of that enforcement, which enforced MFA for access to the Azure portal and the Entra and Intune admin centers, was completed in March 2025. Phase 2 expands the MFA requirement to new services, and will have a correspondingly broad impact. Now’s the time to quickly survey your existing environment and figure out what you need to do to comply with the new enforcement requirements before it’s too late.
What’s Microsoft Enforcing?
Phase 2 of this enforcement effort targets Azure Resource Manager operations performed through any client—not just the portal. That means Azure command-line interface (CLI) tools, PowerShell, the Azure mobile app, Azure REST APIs, SDK client libraries that use any of these access methods, and infrastructure-as-code tools (such as Bicep or Terraform) will all require MFA. If you have users or automation that touches Azure resources through these tools, you need to act now.
The key difference with Phase 2 is that it operates at the Azure Resource Manager (ARM) layer rather than just at sign-in. Previously, a user might authenticate once to the Azure portal with MFA and then use CLI or PowerShell tools without additional MFA challenges. That’s ending, so any service that depends on Azure Resource Manager will be affected.
Microsoft is implementing this change through changes applied by the Azure Policy service, which you might not be familiar with. (More on Azure Policy in an upcoming column!) They have said the enforcement will be “gradually applied across Azure tenants, but without any further details on what this means. Your tenant might not get hit exactly on October 1st, but the change will eventually catch up to you, and you won’t get much advance warning beyond the notifications Microsoft is already sending to global administrators in the tenants.
Workload identities aren’t affected, so your automated processes using proper service accounts should continue working without changes. For now, Microsoft isn’t saying anything about potential changes to access through the Graph API, which would cause a lot of additional upheaval if, and when, they enforce MFA there.
Your Immediate Action Items
It’s mid-September as I write this, which means you have, worst case, only a few weeks before your tenant becomes subject to this enforcement. Here’s what you need to do:
Audit Your Current MFA Posture
Before you can fix a problem, you need to understand its scope. In this case, you’ll need an accurate understanding of which accounts are already enabled for and enrolled in mandatory MFA. Microsoft has documentation that covers how to check this for individual users as well as for your tenant. You really should already be doing this type of auditing, since phishing-resistant MFA at the individual user level is the best protection you can get against a variety of attacks. That said, it’s never too late to start. Pay particular attention to users who regularly use Azure CLI, PowerShell, or other management tools. These are the accounts that will be most immediately impacted when ARM-level enforcement kicks in.
Enable MFA for all Azure Users
This is the big one, and it’s non-negotiable. Every user who needs to perform Azure resource management operations must have MFA enabled before October 1st. This isn’t just about having MFA enabled—it needs to be set as mandatory for those users. Now, it’s true that you don’t really have to do this for all users, just the ones who will be using ARM. In most tenants, that’s a fairly small subset of users. However, as long as you’re at it, you should seriously consider just enforcing MFA for all your users. Rip the Band-Aid off, suffer the pain once, and know that you won’t have to deal with it in the future.
The least troublesome way to do this is through Conditional Access policies that enforce MFA. Don’t rely on per-user MFA settings or security defaults alone; Conditional Access gives you the granular control you need for a proper rollout.
Scream-test by Using Azure Policy
Microsoft provides built-in Azure Policy definitions that let you simulate the Phase 2 enforcement before it actually takes effect. This is your chance to understand what’s going to break before it breaks in production. First, apply the policies in audit mode so you can see which operations would be blocked after the deadline. Once you understand the likely impact in your specific environment, you can gradually roll out Azure Policy in enforcement mode for different resource scopes, resource types, or regions. This staged approach lets you focus first on the areas that are most important to you, and to identify and fix issues without causing widespread disruption.
Don’t Ignore Workload Identities
For now, there are no changes required for service accounts and workload identities. However, many tenants I see have services or automations that are actually authenticated with user accounts, not proper service accounts or managed identities. Any automation that uses ARM-powered services running under a user account will be subject to the new MFA requirements, which will likely break your automated processes.
This is also a good time to review your service principal permissions and make sure they follow the principle of least privilege.
A Possible Escape Hatch
If you know you won’t be ready—or discover on October 1st that you’re not—you can always ask Microsoft to postpone the arrival. Tenant administrators can request a postponement of the enforcement date through the Azure portal. This should be a last resort, not a primary strategy, but it’s there if you need it. Note that postponement requires you first to grant your GA account full access to all resource management scopes in your Azure tenant. (Technically, you must grant the GA account you’re using the User Access Administrator role in Azure RBAC at root scope). The postponement process will check for this required change; once your postponement request is granted, you can remove this entitlement.
The Bigger Picture
While you’re focused on the immediate deadline, don’t lose sight of the broader security benefits. Microsoft’s research shows that MFA blocks more than 99.2% of account compromise attacks. Phase 2 enforcement closes a significant gap in protection by ensuring that powerful Azure management operations are protected even when they don’t go through the portal.
This change also reinforces the importance of proper identity hygiene. Users who need to manage Azure resources should have dedicated admin accounts with appropriate privileges, proper MFA protection, and clear accountability. If this rollout forces you to clean up some of your identity management practices, that’s probably a good thing in the long run.
The October deadline is approaching fast, but with focused effort on these immediate action items, you can ensure your users maintain access to the Azure resources they need while significantly improving your security posture. Microsoft’s mandatory MFA rollout isn’t just about compliance—it’s about protecting your organization from the kind of account compromise attacks that are becoming increasingly common and sophisticated.
Start with the audit, enable MFA everywhere it’s needed, test the impact, and communicate early and often. Your users will thank you for the smooth transition, and your CISO will thank you for the improved security.
