Azure now asks your scripts for a second factor

Most people met this change in the Azure portal. One morning the sign in asked for a code, they set up the authenticator app, and that was that. Microsoft finished rolling that first phase out to every tenant in March 2025.

The second phase is the one that bites, because it is aimed at things that do not have a phone.

What phase two covers

From 1 October 2025 Azure began enforcing multifactor authentication at the resource management layer. In plain terms, that is anything that creates, changes or deletes Azure resources, whichever tool does it. The Azure CLI. Azure PowerShell. The mobile app. The REST API. The SDKs. Infrastructure as code tools. Enforcement has been applied tenant by tenant, and organizations that needed more time could ask to postpone it until July 2026. That window has now closed.

Microsoft's reason is hard to argue with. Its own research says multifactor authentication blocks more than 99.2 percent of account compromise attacks. The portal was only one door. Leaving the command line open made little sense.

Who gets hurt

Not properly built automation. Workload identities, which means managed identities and service principals, are outside both phases. A pipeline that signs in with a service principal carries on as before.

The trouble is the other kind. Years ago somebody wrote a script to stop the development machines at night, and it signs in as a real person with a password stored in a file. Or a backup job runs under the account of an administrator who has since changed roles. These are user accounts being used as service accounts, and Microsoft's guidance calls them out by name. When enforcement reaches them, they stop, usually at night, and usually the first sign is that something did not happen.

The annoying thing is that these scripts tend to be the quiet useful ones. Nobody has looked at them since they were written, which is why nobody knows how they sign in.

What to do this month

Search for them before they find you. The sign in logs in Entra show which user accounts are signing in to Azure management without any interactive session. Anything that looks like a person but behaves like a clock is a candidate.

Then move each one. If the job runs inside Azure, a managed identity is the cleanest answer, because there is no secret to store at all. If it runs somewhere else, use a service principal with a certificate, and give it only the permissions the job needs. While you are there, update the tools. Microsoft recommends Azure CLI 2.76 and Azure PowerShell 14.3 or later for the best compatibility.

Do not solve this by excluding the account from your access policies. Enforcement applies whatever your own policies say, and it was never a good idea.

Where X-Axis fits

Our consultants review Azure identity and automation as part of cloud operations work in the United States and Canada. The consulting page shows how an engagement runs.