Microsoft's mandatory MFA page, updated on 6 October 2026, repeats a point that is easy to skip: if a user identity signs in as a service account to run automation, it needs MFA once enforcement starts. Workload identities such as managed identities and service principals are not affected. Plenty of tenants have a "svc-deploy@" user whose password sits in a pipeline variable.
What's affected
Phase 2 enforcement covers Azure CLI, Azure PowerShell, the Azure mobile app, IaC tools and the control-plane REST API for create, update and delete operations. It is enforced at Azure Resource Manager, so requests to https://management.azure.com are in scope. Microsoft Graph is generally not.
Break points to look for:
- Scripts that sign in with a username and password. The OAuth 2.0 resource owner password credentials (ROPC) flow cannot satisfy MFA, so ROPC-based calls throw exceptions once MFA applies.
- Apps using the
AZURE_USERNAMEandAZURE_PASSWORDenvironment variables withDefaultAzureCredentialorEnvironmentCredential, or theUsernamePasswordCredentialclass. Microsoft marks these as needing change. - Older clients. Microsoft recommends Azure CLI 2.76 and Azure PowerShell 14.3 or later.
How to check if you're exposed
Send sign-in logs to Log Analytics, then look for user accounts with automation-shaped behavior against the Phase 2 clients. The application IDs are listed by Microsoft: Azure CLI is 04b07795-8ddb-461a-bbee-02f9e1bf7b46 and Azure PowerShell is 1950a258-227b-4e31-a9cf-717495945fc2.
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where AppId in ("04b07795-8ddb-461a-bbee-02f9e1bf7b46", "1950a258-227b-4e31-a9cf-717495945fc2")
| summarize signins = count(), ips = dcount(IPAddress), lastSeen = max(TimeGenerated) by UserPrincipalName, AppDisplayName
| order by signins desc
A human has a handful of sign-ins from a few addresses. An account with hundreds, from a pipeline's fixed address and at odd hours, is almost certainly a service account. Also check the Conditional Access insights and reporting workbook that Microsoft points to, with your MFA policy in report-only mode.
What to do now
- List every candidate from the query plus any account whose name starts with svc, bot, deploy or ci.
- Find the owner and the script. Check pipeline variables and secret stores for the stored password.
- Replace the login. For Azure automation, use a managed identity when the workload runs in Azure, or a service principal otherwise. Microsoft documents
az loginflows for both. - For CI outside Azure, use workload identity federation instead of a client secret. See our guide on OIDC for GitHub Actions.
- Disable the user, wait one business cycle, then delete it, and remove the stored password from every pipeline.
- Apply Conditional Access for workload identities where your license allows it. Microsoft notes you can reclaim the user license and add a workload identities license.
Why it matters
A user account used as a service account has no MFA, a password that rarely rotates, a human-sounding name that gets excluded from reviews, and often broad rights because it was easier. It is the first thing an attacker with a leaked pipeline variable would try.
The MFA mandate is a forcing function. The better outcome is not "add MFA to the robot", which cannot work, but an identity that has no password at all.
Try it yourself
Run the query above for 30 days and count the accounts. Then check how many have an owner listed in your asset inventory.
Click through it at your own pace, or open it full screen.
Quick check
Are service principals subject to Azure's mandatory MFA?
No. Microsoft says workload identities such as managed identities and service principals are not affected, but user identities used for automation are.
