Every environment has them. An account named something like svc-backup or automation-prod, created years ago because a script needed to authenticate and a user account was the fastest path. It holds a password that does not rotate, it is excluded from Conditional Access because enforcement broke a job once, and it frequently carries more privilege than anyone currently employed can justify.
Microsoft's mandatory MFA programme has removed the option of ignoring these accounts. The mandate applies to all user accounts without exception, and Conditional Access exclusions do not create an exemption. Phase 2 enforcement covers create, update and delete operations through Azure CLI, Azure PowerShell, the Azure SDK, Infrastructure-as-Code tooling and control-plane REST endpoints. Any of those running under a user principal will begin failing.
The remediation is not to find a way to make a script perform MFA. It is to stop the script from being a user at all.
Step one: find them
Microsoft Entra sign-in logs are the authoritative inventory. Filter interactive and non-interactive sign-ins by the application IDs for Azure CLI, Azure PowerShell and the Azure mobile app, then group by user principal. Anything that appears with machine-like regularity, from a datacentre or build-agent IP range, or outside working hours, is a service account regardless of what it is named. Cross-reference against accounts with no registered authentication methods and accounts excluded from Conditional Access policies; the overlap is usually close to complete.
Expect the list to be longer than the platform team predicts. Automation accumulates. In most mid-market tenants we assess, the discovered count exceeds the documented count by a factor of two or more.
Step two: choose the right replacement
Where the workload runs inside Azure — a VM, an App Service, a Function, a container, an Automation account, a Logic App — a managed identity is the correct answer and requires no credential at all. The platform issues and rotates the token, there is nothing to store, and nothing to leak. This covers the majority of cases and should be the default.
Where the workload runs outside Azure, the choice is between a service principal with certificate authentication and a service principal with a federated credential. Federated credentials are the stronger option wherever the calling system supports OIDC: GitHub Actions, Azure DevOps, GitLab and Kubernetes service accounts can all exchange their own identity token for an Entra token, eliminating the stored secret entirely. Certificate authentication is the fallback where federation is not available, and it is still substantially better than a client secret because certificates can be issued short-lived and stored in a hardware-backed store.
Client secrets should be treated as a last resort with a documented expiry and an owner, not as a normal outcome.
Step three: scope the privilege down
Migration is the moment to fix the privilege problem, because you are rebuilding the identity anyway. A managed identity that only needs to read blobs should hold Storage Blob Data Reader on one container, not Contributor on the subscription. Azure's activity logs will tell you which operations the old account actually performed over the last ninety days, which is a far better basis for a role assignment than the original request ticket.
Step four: break-glass accounts
Emergency access accounts remain in scope for the mandate and cannot be migrated to workload identities, because their entire purpose is human access when everything else fails. They need an MFA method that works without a phone network, without a managed device, and without the person who set it up. FIDO2 security keys held in physical custody, or certificate-based authentication, are the workable options. Register at least two, store them separately, and test them on a schedule.
Why this is worth doing regardless
Standing credentials attached to user accounts are among the most reliably exploited footholds in cloud environments. They rarely have MFA, they rarely rotate, they usually hold excess privilege, and their sign-ins blend into normal traffic. Removing them removes an attack path that does not depend on a mandate to be dangerous. The MFA programme has simply made the deadline external.
How Lorexus engages
We produce the inventory from your sign-in telemetry, classify each account by workload location, and migrate them in priority order — managed identity first, federated credential second, certificate third — with privilege scoped from observed activity rather than from the original request. Break-glass accounts are rebuilt and tested as part of the same engagement.