Starting October 1, 2025, Microsoft will require multi-factor authentication (MFA) for managing Azure resources to enhance security. This change will affect administrators and developers who perform specific actions within the Azure environment.
Table of Contents
What is Multi-Factor Authentication?
Think of your password as the first key to your house. It works well, but what if someone steals it? They could get right in. Multi-factor authentication, or MFA, is like adding a second, different kind of lock to your door. Even if someone steals your first key (your password), they still cannot get in without the second key.
This second key could be:
- Something you have, like a code sent to your phone.
- Something you are, like your fingerprint or face scan.
By requiring a second proof of identity, MFA makes it much harder for unauthorized people to access your account. It provides a vital layer of security. This is especially important for powerful accounts that can manage cloud resources, like those for Microsoft Azure. This change is a key part of Microsoft’s plan, called the Secure Future Initiative, to make its products safer for everyone.
Who Is Affected by This Change?
This new rule does not apply to every single person who uses Azure. It is specifically for accounts that have the power to change things within Azure. If you are an administrator, a developer, or anyone who manages Azure resources, you need to pay close attention. The change targets accounts that log in to perform administrative tasks.
The new MFA requirement will be enforced when you use certain tools to connect to Azure. These tools are often used by technical staff to build, configure, and manage cloud services. The main tools impacted are:
- Azure CLI: A program that lets you type commands to control Azure.
- Azure PowerShell: A tool that uses scripts and commands for Azure management.
- Azure mobile app: The official app for managing Azure from your phone or tablet.
- Infrastructure as Code (IaC) tools: Tools like Terraform or Bicep that manage Azure resources through code.
- REST API endpoints: A way for different software programs to talk directly to Azure.
If your job involves using any of these tools to manage Azure, this MFA enforcement will apply to you. Regular users who only view information or use Azure services without changing them will not be impacted by this specific rule.
Understanding the Specific Operations
Microsoft is being very specific about when MFA is needed. You will not be prompted for a second authentication factor every time you log in. The requirement is tied to actions that create, change, or remove resources in Azure.
MFA will be required for the following operations:
- Create: When you build something new, like a new virtual machine or a database.
- Update: When you change an existing resource, such as modifying its settings or size.
- Delete: When you permanently remove a resource from your Azure environment.
MFA is not required for read operations. A read operation is when you are only looking at information. For example, if you log in simply to check the status of your services or view a report, you will not be required to use MFA for that action. This distinction ensures that security is tightened around the most sensitive actions without adding friction to routine monitoring tasks.
A Better Way to Handle Service Accounts
Some organizations use a regular user account to act as a “service account.” A service account is used by applications or automated scripts to interact with Azure, not by a person. Using a person’s account for this purpose is a security risk. If that account’s password is stolen, it could be used by an attacker to run automated tools and cause significant damage.
Microsoft strongly advises against this practice. The company recommends moving away from these user-based service accounts. Instead, you should use a more secure method designed specifically for applications and scripts. This recommended method is called a workload identity.
A workload identity is a special identity created just for a piece of software or an automated process. It is not tied to a human user. This is much safer for several reasons. It has specific permissions and cannot be used for general logins. Migrating to workload identities reduces the risk of your service accounts being misused if a user’s credentials are compromised. This is a key step in preparing for the new MFA enforcement and improving your overall security.
How to Prepare for the Change
You can take several steps now to ensure a smooth transition when Microsoft begins enforcing MFA. Being proactive will prevent any interruption to your work and keep your Azure environment secure.
Identify Your Accounts
First, figure out which of your accounts will be affected. Look for any user accounts that are being used as service accounts for automation. Also, identify all the administrator and developer accounts that use the tools mentioned earlier (CLI, PowerShell, etc.) to manage Azure.
Update Your Tools
To avoid compatibility problems, you must update your Azure management tools. Microsoft has stated that you need to be on specific versions or newer.
- Update Azure CLI to version 2.76 or higher.
- Update Azure PowerShell to version 14.3 or higher.
- Running older versions of these tools might cause them to fail when MFA is enforced.
Plan Your Migration
Start planning the move from user-based service accounts to workload identities. This may take time. You will need to identify all the applications and scripts using the old accounts and reconfigure them to use the new, more secure workload identities. Microsoft provides documentation to guide you through this process.
Enable MFA for Users
Do not wait for Microsoft to force the change. Start enabling MFA for all your administrative users now. This will help your team get used to the process and will immediately improve your security.
What If You Need More Time?
Microsoft understands that some large organizations might need more time to prepare for this change. For this reason, an option to postpone the enforcement is available, but it is limited.
Only users with the Global Administrator role can request an extension. If you are a Global Administrator, you can delay the mandatory MFA start date for your organization until July 2026. This gives you extra time to update tools and migrate service accounts. However, this is just a postponement. The MFA requirement is not going away. It is best to use this extra time to become fully compliant instead of delaying the inevitable. This extension is a safety net, not a long-term solution. The most secure approach is to adopt MFA as soon as possible.