In almost every Azure project I review, I still find pipelines that authenticate with client secrets, or worse, with user accounts hardcoded into scripts. That used to be normal. Today the risks are hard to ignore: secrets sit in plain text files, get pushed to repos or hang around in environment variables. Microsoft has scheduled phase 2 of Azure MFA enforcement for October 2025, and these setups won't survive it. If you want your automation to keep running securely, workload identity federation is the way forward.

Workload identity federation replaces secrets with short-lived tokens

With workload identity federation, automation platforms like Azure DevOps and GitHub Actions authenticate to Azure with ephemeral tokens instead of long-lived secrets. The pipeline provider (GitHub Actions, for example) vouches for the job's identity, and Azure accepts it through a federated credential on an app registration or managed identity. You get rid of static secrets and get clean audit trails. Once phase 2 MFA is in place, you also won't see pipelines break because user accounts are blocked. It's a big change, and honestly, most environments should have made it long ago.

Tip from practice: A lot of teams keep putting the migration off. With mandatory MFA coming soon, doing it now is worth the effort, and Azure DevOps and GitHub have made the switch surprisingly easy.

Existing Azure DevOps service connections convert with a few clicks

If you still use classic Azure DevOps service connections (Project settings → Service connections), you'll probably see prompts to convert them to workload identity federation. Most AzureRM/ARM-type connections migrate with a few clicks:

flowchart TD
  devops["Azure DevOps pipeline"] --> oidc["Request OIDC token"]
  oidc --> entra["Entra ID: Federated sign-in"]
  entra --> spn["Service principal (federated credential)"]
  spn --> azure["Azure resources"]

Figure: Azure DevOps authenticates to Azure through OIDC and workload identity federation

In the Azure DevOps portal, open the existing connection and select 'Convert to Workload Identity Federation.' Azure then creates a federated credential on the linked service principal, usually with a subject claim like sub=system:serviceaccount:.... When I see problems after a migration, they mostly come from role assignments that are far too broad. Keep permissions granular at resource group or resource level instead of handing out Contributor at subscription scope.

Microsoft's documentation is current if you want the individual steps (Configure workload identity for Azure DevOps release pipelines).

GitHub Actions needs a federated credential in Entra ID

GitHub Actions works in a similar way, but you set it up in the Entra admin center (App registrations → Certificates & secrets → Federated credentials). Add a new federated credential and point it at a specific repository, branch or environment by writing the matching subject claim, such as repo:org/repo:ref:refs/heads/main or environment:production. If user-assigned managed identities suit your infrastructure better, this works with them too.

For more advanced setups, I'd read the Microsoft documentation (Connect GitHub Actions to Azure with OpenID Connect).

Federated identities still need least privilege

Federation doesn't fix bad habits, so don't give your federated identities broad roles. Assign the smallest role that does the job, ideally scoped to the exact resource. Each federated credential can carry its own subject claim, which makes auditing a lot easier, as long as you use a dedicated app registration or managed identity per pipeline or use case. If you need a refresher on managed identities versus app registrations and how to secure each, have a look at my earlier post Workload identities in Entra ID: Managed identities vs app registrations.

Phase 2 MFA will break automation that runs on user accounts

This is the part many admins still overlook. Once mandatory Azure MFA reaches CLI and PowerShell in phase 2, user accounts used in automation will stop working. I've come across critical deployments that still run on legacy user credentials. They will fail, and probably when it hurts most. If you want your automation to keep running, moving to workload identity federation isn't optional. For hands-on guidance on getting rid of client secrets, see Replace client secrets in Entra ID: safer alternatives.

I treat workload identity federation as the baseline

For me, workload identity federation is more than a security feature. It's the starting point for modern, reliable automation in Azure and Microsoft 365. The migration takes some work up front, but you see the benefit right away: secrets no longer expire, there are no rushed rollouts, and you get better visibility and control over access. With Azure's MFA enforcement on the way, you'll have to switch anyway. Do it now and you'll spare yourself a lot of trouble and downtime later.