Azure Login

Last spring, a deployment pipeline at a mid-sized retail company stopped working on a Tuesday morning. Nothing had changed in the code. The cause was an old script that signed in with a shared admin account and password, and Azure now required multifactor authentication for that account. The team lost half a day, and the incident exposed a bigger problem. Nobody could say who was using that account or from where.

An Azure login looks simple, but it is the front door to your whole environment. The method you pick decides who can reach your resources, how well you can audit that access, and whether your automation survives security changes. I have fixed this problem for teams in healthcare, retail, and finance, and the fix is almost always the same: match each sign-in method to the right kind of user or workload.

This guide covers every common way to sign in to Azure, from the portal to the command line to pipelines. You will learn how to choose the right method, secure it with Microsoft Entra ID, and fix the errors that block people most often.

How an Azure Login Actually Works

Every Azure login goes through Microsoft Entra ID, the identity service that handles authentication and access management. When you sign in, Entra ID checks who you are and issues a token. Azure Resource Manager, the deployment and management layer for all Azure resources, then uses that token to decide what you can do.

Two ideas matter here. Authentication proves who you are. Authorization decides what you can do after that. Authorization comes from role-based access control (RBAC), which assigns permissions through roles instead of broad administrator access. You can sign in successfully and still see nothing, because no role is assigned to you. If that confuses your team, our overview of Azure RBAC is a good starting point.

Your account also lives in a tenant, which is a dedicated Entra ID instance for your organization. A tenant can hold many subscriptions, which are billing and governance boundaries for Azure resources. Signing in to the wrong tenant or subscription causes many “I can’t see my resources” tickets. Our explainer on what a tenant is in Azure clears up the difference, and the guide to Azure subscriptions covers the billing side.

Pro Tip: In my experience, most “Azure login problems” are really tenant or subscription mix-ups. I ask people to read me the tenant name shown in the portal before I touch anything else.

Which Login Method Fits Which Job

The rule behind this table is simple. People sign in as people. Software signs in as software. Mixing the two is what broke that retail pipeline.

Azure Login With the Portal

For most people, the first Azure login happens in a browser. You go to the portal, enter your work or school account, and approve the MFA prompt. Our walkthrough on how to sign in to the Azure portal shows the exact screens, and the Azure portal overview explains what you can do once inside.

New to Azure? You need an account before any of this works. Our guide to creating an Azure free account walks through sign-up and what the free tier includes.

Make the Portal Login Safer

Turn on a few settings before you roll this out to a team:

• Require MFA for every user, not only administrators.
• Use Conditional Access to limit sign-ins from risky locations or unmanaged devices.
• Keep two emergency-access accounts that are excluded from Conditional Access, protected with strong credentials, and monitored with alerts.
• Assign roles to groups rather than individual people.

Microsoft has also made MFA mandatory for Azure sign-ins. The portal phase came first, and the next phase now covers Azure CLI, Azure PowerShell, the mobile app, infrastructure-as-code tools, and REST APIs for create, update, and delete operations. Read-only operations do not need MFA, and workload identities such as managed identities and service principals are not affected.

Check your own tenant’s status in the Entra admin center rather than assuming, because rollout has been gradual. If you want to understand the basics first, see our post on what MFA is.

Pro Tip: I once locked out an entire admin team during a Conditional Access test because I forgot to exclude the emergency accounts. Always test a new policy in report-only mode first, and keep a break-glass account that you have verified actually works.

Azure Login With the Azure CLI

The Azure CLI is a cross-platform command-line tool for managing Azure. If you are new to it, start with our primer on what the Azure CLI is, and install it using the Windows installation guide if needed.

Interactive Sign-In for People

az login

This opens your default browser so you can sign in with your Entra account and complete MFA. After sign-in, the CLI lists the subscriptions you can access and lets you choose a default. Our page on the az login command covers extra options, and the Azure CLI login guide explains common variations.

If no browser is available, such as on a remote server, use device code flow.

az login --use-device-code

The --use-device-code parameter prints a short code. You open the Microsoft device login page on another device, enter the code, and finish MFA there. This is useful, but it is also a known phishing pattern, so only use it for codes you generated yourself.

Pick the Right Tenant and Subscription

az login --tenant <tenant-id>
az account list --output table
az account set --subscription <subscription-id>
az account show --output table

The --tenant parameter signs you in to a specific tenant, which matters when you are a guest in several organizations. The az account list command shows every subscription you can reach. The az account set command chooses the active one, and az account show confirms it.

Skipping that last step is how people deploy to the wrong subscription. Our guide to setting the active account with az account set explains the details.

Pro Tip: I run az account show before every deployment script and print the subscription name in the output. It takes one second and has saved me from pushing a test change into production twice.

Azure Login With PowerShell

Azure PowerShell uses the Az module and is a natural fit for Windows administrators who already script in PowerShell. If you are choosing between the two tools, our comparison of Azure PowerShell vs Azure CLI lays out the trade-offs. Both tools use the same Entra sign-in and the same MFA rules.

$TenantId = "<tenant-id>"
$SubscriptionId = "<subscription-id>"

Connect-AzAccount -Tenant $TenantId
Set-AzContext -Subscription $SubscriptionId
Get-AzContext

The Connect-AzAccount cmdlet starts an interactive sign-in. The -Tenant parameter targets the tenant you want. The Set-AzContext cmdlet picks the subscription for later commands, and Get-AzContext confirms what you are connected to. Our guide on Connect-AzAccount goes deeper, and the comparison of az login vs Connect-AzAccount is worth reading if your team uses both.

If PowerShell says the cmdlet is not recognized, the Az module is probably missing. Our fix for the Connect-AzAccount not recognized error walks through installing it.

Pro Tip: I keep the Az module and Azure CLI updated on admin workstations. Older versions are the most common reason MFA prompts fail in scripts after a policy change.

Azure Login for Automation and Pipelines

This is where most real risk sits. A person can approve an MFA prompt. A scheduled job cannot. The wrong answer is to give a user account a password and let the script sign in as that user. Passwords get shared, they expire, and MFA enforcement breaks them.

Managed Identities for Code Running in Azure

A managed identity is an identity that Azure creates and manages for a resource, so your code never stores a secret. If your script runs on an Azure VM, in a Function App, or in an App Service, this is the right choice. Our article on managed identities in Azure explains system-assigned and user-assigned types.

az login --identity
az role assignment create \
  --assignee <managed-identity-principal-id> \
  --role "Reader" \
  --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>

The az login --identity command signs in using the identity attached to the resource, with no password. The az role assignment create command grants that identity the Reader role, scoped to a single resource group.

A resource group is a logical container for related Azure resources. Scoping the role this narrowly applies least privilege, which means giving only the access the job needs. Our post on signing in with a managed identity shows more examples.

Service Principals for Systems Outside Azure

A service principal is an identity for an application or tool. Use one when your automation runs outside Azure and cannot use a managed identity. Our guide on creating a service principal in Azure covers the setup.

Prefer a certificate over a client secret when you can. If you must use a secret, store it in Azure Key Vault, a service for securely storing secrets, keys, and certificates. See how Azure Key Vault works before wiring it in.

Never put secrets in source code, spreadsheets, shared files, or chat messages. I have found client secrets in all four places.

GitHub Actions Without Stored Secrets

For a CI/CD pipeline, workload identity federation i