How to MFA in the Azure CLI

02 Nov 2026 🔖 devops
💬 EN

If you’ve got a sufficiently pricey license for Microsoft’s Visual Studio IDE, then whether or not you actually bother to install VS, one of the free perks is an Azure subscription with a few bucks a month of credits. You can’t accidentally run up a huge bill – it’s more like a prepaid gift card – it simply stops you from using it for the rest of the month when you’re out of credits.

If you’re like a lot of cloud-native infrastructure engineers and software developers, you probably play in that Azure subscription a lot.

And if you do so via some sort of secondary command-line interface (“CLI”) tool (e.g. Terraform) piggybacking on top of your logged-in state within the Azure (“az“) CLI tool, this week you might suddenly find yourself dealing with a RequestDisallowedByAzure 401 Unauthorized error, saying that your Azure resource create/edit/delete request “was disallowed by Azure: You are receiving this error because you tried to create, update, or delete Azure resources without authenticating through MFA.”

I think I’ve found a fix.

How to interactively authenticate into the Azure CLI after October 2026

The trick is not to let anything but the az CLI be the first “write” action against your Azure subscription that you attempt in a while.

The actual az CLI is the one that’ll give you the best error message – the one you actually need to get your day started and get MFA kicked off.

Here’s what worked for me:

1. Use the Azure CLI (not the Terraform CLI or any other layered-on tool!) to try to create an Azure resource group with some name that I don’t actually care about creating for real:

    az group create --location 'centralus' --resource-group 'helloworld'
   

   • I got this error message, which luckily informed my next steps (note that you’ll have a unique value where I wrote CENSORED):

       Run the command below to authenticate interactively; additional arguments maybe be added as needed.
       az logout
       az login --tenant "TENANT_GUID_HERE" --scope "https://management.core.windows.net//.default" --claims-challenge "CENSORED"
       SubError: basic_action V2Error: invalid_grant AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '797f4846-ba00-4fd7-ba43-dac1f8f63013'.
     

2. Log out & back in, this time adding the --scope & --claims-challenge flags from the error message:

    az logout
    az login --tenant 'TENANT_GUID_HERE' --subscription 'SUB_GUID_HERE' --scope 'https://management.core.windows.net//.default' --claims-challenge 'CENSORED'
   

3. Complete the single sign-on and MFA challenge that pops up (note that it might be hidden behind other open windows, or on a different monitor).
4. Finally, Terraform ran just fine against my VS Azure subscription, using my human Entra user principal:

    terraform apply
   

Be responsible

Of course, as EpiFive and Cohash point out, if you’re not actually doing interactive work where you can interactively step through the MFA process, then you have no business using a human Entra principal as your az login identity, and you’re being kicked out of bad design on purpose.

For those cirumstances, I don’t have a workaround for you.

You’ll need to fix your automations to stop lying about being a human.

Create proper Entra service principals for them to use, instead.