Azure DevOps WIF: Moving Service Connections to the Entra Issuer

Workload identity federation (WIF) service connections in Azure DevOps come in two flavours, depending on who signs the token the pipeline presents to Entra ID. Older connections use the Azure DevOps issuer. Newer ones use the Microsoft Entra issuer. Microsoft announced in June that the Azure DevOps issuer is going away:

Eight and a half months sounds like a lot. In an organisation with a few hundred service connections, owned by different teams, some of them created by Terraform, it isn’t.

What actually changes

The service connection keeps its ID, name and pipeline authorizations. What changes is the federated credential on the identity behind it (app registration or user-assigned managed identity):

The new subject no longer contains the organization, project and connection name. That fixes an old annoyance: renaming a project or a manually created service connection used to break the federation with AADSTS70021, because the subject on the identity no longer matched. With the Entra issuer the subject doesn’t change when you rename things.

Pipeline YAML and tasks don’t change. AzureCLI@2, AzurePowerShell@5 and friends keep referencing the same service connection.

Scope

The retirement applies to service connections in Azure public cloud that use a single-tenant app registration or a managed identity. It isn’t limited to Azure Resource Manager connections: Docker registry connections and connections created by extensions are included if they use WIF with the Azure DevOps issuer.

Out of scope for now, and still supported on the Azure DevOps issuer:

• Azure Government, Azure operated by 21Vianet and Azure Stack
• Multi-tenant app registrations (signInAudience: AzureADMultipleOrgs). The Entra issuer rejects these with AADSTS70052. If you depend on one, for example for cross-tenant VNet peering, nothing changes yet.

Finding affected connections

The UI lists affected connections at the top of Project settings > Service connections with a warning, and pipeline runs that use them show a deprecation warning. That works per project. To get the full picture across an organisation, query the issuer directly:

ORG="https://dev.azure.com/contoso"

az devops project list --org "$ORG" --query "value[].name" -o tsv |
while IFS= read -r project; do
  az devops service-endpoint list --org "$ORG" --project "$project" \
    --query "[?authorization.scheme=='WorkloadIdentityFederation' && starts_with(authorization.parameters.workloadIdentityFederationIssuer || '', 'https://vstoken.dev.azure.com')].[name, id]" \
    -o tsv |
  while IFS=$'\t' read -r name id; do
    printf '%s\t%s\t%s\n' "$project" "$name" "$id"
  done
done

The output is a tab-separated list of project, connection name and connection ID. Connections that already use the Entra issuer report https://login.microsoftonline.com/... and drop out of the filter.

That list is the inventory. The harder part is the second column you need next to it: who owns the identity behind each connection.

Converting a connection

For a single connection the path is short:

1. Open the flagged service connection.
2. Select Update and confirm.
3. Azure DevOps creates the new federated credential on the identity and switches the connection over. The old credential stays in use until the new one is verified, so running pipelines aren’t interrupted.

This only works if the person clicking has permission on both sides: service connection administrator in Azure DevOps, and owner of the app registration (or a role that can write federated credentials on the managed identity, such as Managed Identity Contributor) in Azure. In most enterprise setups those are different people.

When the automatic step can’t create the credential, Azure DevOps shows the new issuer and subject. Someone with access to the identity adds them as a federated credential (scenario Other issuer, explicit subject identifier), and you select Try again in Azure DevOps.

For bulk conversion, Microsoft documents a script that calls the REST API. Note that it uses On-Behalf-Of access, which only works for user principals. You can’t run it as a service principal from a pipeline.

When Terraform manages the connection

This is where it gets uncomfortable. If you create WIF service connections with the microsoft/azuredevops provider, the usual pattern looks like this:

resource "azuredevops_serviceendpoint_azurerm" "this" {
  project_id                             = azuredevops_project.this.id
  service_endpoint_name                  = "sc-platform-prod"
  service_endpoint_authentication_scheme = "WorkloadIdentityFederation"
  azurerm_spn_tenantid                   = var.tenant_id
  azurerm_subscription_id                = var.subscription_id
  azurerm_subscription_name              = var.subscription_name

  credentials {
    serviceprincipalid = azurerm_user_assigned_identity.this.client_id
  }
}

resource "azurerm_federated_identity_credential" "this" {
  name                = "fic-sc-platform-prod"
  resource_group_name = azurerm_user_assigned_identity.this.resource_group_name
  parent_id           = azurerm_user_assigned_identity.this.id
  audience            = ["api://AzureADTokenExchange"]
  issuer              = azuredevops_serviceendpoint_azurerm.this.workload_identity_federation_issuer
  subject             = azuredevops_serviceendpoint_azurerm.this.workload_identity_federation_subject
}

workload_identity_federation_issuer and workload_identity_federation_subject are computed attributes. You can’t set the issuer type in configuration, and the provider has no in-place convert. The only Terraform-native way to get a connection onto the Entra issuer is terraform apply -replace, which destroys and recreates the service connection. That gives it a new ID and drops pipeline authorizations, approvals and checks. There’s an open feature request for an in-place update (terraform-provider-azuredevops#1573). Microsoft says it wants to support Terraform but hasn’t given a timeline.

What I’d do until then:

1. Convert in the portal, not with -replace. The connection keeps its ID and everything attached to it.
2. Run terraform plan straight after. The refresh picks up the new issuer and subject from the service connection, and they flow into the federated credential resource. Expect Terraform to want to change azurerm_federated_identity_credential (or azuread_application_federated_identity_credential for app registrations). Read the plan before applying it.
3. Check for duplicates. If the portal conversion already added a credential with the new values, Terraform now wants to write the same issuer and subject into the credential it manages. Decide which one Terraform owns: either delete the portal-created one and let Terraform apply, or import it and drop the old one. An app registration or managed identity can hold at most 20 federated credentials, so leftover ones also count against that limit.
4. Do one connection in a test project first. Run a pipeline against it after the apply, not just after the conversion.

For new connections created by Terraform today, you get the Entra issuer by default, so this is only a migration problem for the existing ones.

Errors you might see

A plan until July 2027

• Run the inventory script above and put the result in a table with an owner per identity.
• Convert the connections where one person has rights on both sides right away. That’s usually the bulk.
• Go through the Terraform-managed ones deliberately, one stack at a time, with the plan check from above.
• Leave multi-tenant and sovereign-cloud connections alone, but write them down. They’re out of scope today, not forever.

Sources: Microsoft announcement, Convert service connections, Automate workload identity service connections.