The Azure DevOps Issuer Is Deprecated: Find Yours Before 2027

If a pipeline run showed you a yellow banner on an Azure service connection sometime after 1 July, this is what it was about. Microsoft is retiring the Azure DevOps issuer for workload identity federation, and the published timeline is deprecation on 1 July 2026 and end of life on 1 July 2027.

Nothing breaks on either of those dates except the second one. That is the entire difficulty. A year of warnings is long enough for the banner to become wallpaper, and the failure at the end is a pipeline that cannot authenticate to Azure, discovered by whoever is on call.

What is changing, precisely

Workload identity federation is how a pipeline authenticates to Azure without a stored secret: it presents a short-lived OIDC token, and Azure trusts it because a federated credential on the identity says to. That credential pins two strings, an issuer and a subject, and both are changing.

The issuer goes from https://vstoken.dev.azure.com/<organization id> to https://login.microsoftonline.com/<tenant id>/v2.0. The subject goes from a path built out of names to one built out of identifiers.

That second change is the security argument, and it is a real one rather than plumbing. The old subject was sc://<org>/<project>/<connection name>, which meant a deleted connection could be recreated under the same name and inherit the same trust. It also meant renaming an organization or project quietly invalidated the credential, which is the cause behind the AADSTS70021 errors people have been hitting for years.

Who is actually in scope

Narrower than the banner implies. The deprecation covers eligible connections in the Azure public cloud that use single-tenant Entra applications or managed identities. Explicitly out of scope, with the Azure DevOps issuer continuing to work:

• Connections targeting Azure Government, Azure operated by 21Vianet, or Azure Stack.
• Connections using multitenant applications, whose retirement is scheduled separately and later.

Wider in one respect, though. This is not an Azure Resource Manager story. Any workload identity federation connection using the old issuer is affected, including Docker registry connections and connections created by Marketplace extensions. The rule is the issuer, not the connection type, and the extension-created ones are the connections nobody remembers owning.

Finding them is the part with no tool

Microsoft documents the conversion but not the inventory. The obvious move is to filter service connections by issuer through the REST API, and that does not work, because the ServiceEndpoint schema types both data and authorization.parameters as untyped objects. There is no documented field name to query.

So grep the response instead. The issuer prefix is a distinctive string and it either appears in the blob or it does not:

ORG=yourorg
export AZURE_DEVOPS_EXT_PAT=$(cat ~/.ado-pat)   # or use az login

az devops project list --org "https://dev.azure.com/$ORG" \
  --query 'value[].name' -o tsv |
while read -r PROJECT; do
  az devops invoke --org "https://dev.azure.com/$ORG" \
    --area serviceendpoint --resource endpoints \
    --route-parameters project="$PROJECT" \
    --api-version 7.1 -o json |
  jq -r --arg p "$PROJECT" '
    .value[]
    | select(tostring | test("vstoken\\.dev\\.azure\\.com"))
    | "\($p)\t\(.type)\t\(.name)"'
done

Run it with a token that can read service endpoints across every project, and treat an empty result as “this token could not see everything” until you have confirmed otherwise. Shared connections show up in each project that references them, so deduplicate on the endpoint id if you want a true count.

The output is your work queue. It is also usually shorter than the banner count suggests, because the same shared connection generates a warning in every pipeline that touches it.

The conversion, and where it stalls

In the portal, affected connections sort to the top of the service connection list with a warning. Open one, choose Update, confirm, and Azure DevOps adds the new federated credential to the identity and repoints the connection. It takes a few minutes. Convert rather than recreate, because a new connection means editing every pipeline that names the old one.

The automatic path fails for exactly one reason, and it is organizational rather than technical: permission on the service connection is not permission on the identity. Being a service connection administrator in Azure DevOps grants nothing in Entra. To add the federated credential you need owner access on the app registration, or a role like Managed Identity Federated Credential Contributor on the managed identity, and in most companies that is a different team.

Azure DevOps handles this reasonably. When it cannot write the credential, it shows you the Issuer, Subject identifier, and Audience values, and someone with Entra access adds a federated credential of type Other with those three strings. You then return to the connection and select Try again once the credential has propagated. The values have to match exactly; a mismatch on any of the three surfaces as AADSTS700211 or AADSTS700213, which tell you which half is wrong.

Budget for that handoff. The conversion itself is a few minutes and the ticket to the identity team is the schedule.

One error worth knowing in advance

If a connection uses a multitenant app registration, that is signInAudience: AzureADMultipleOrgs, conversion returns AADSTS70052: the identity must be a managed identity, a single tenant app, or a service account. The Entra issuer does not support multitenant apps today.

The documented answers are to switch to AzureADMyOrg and use a separate service connection per tenant, or, if you genuinely depend on operations that reach several tenants in one request such as cross-tenant virtual network peering, to contact support and have your organization stay on the Azure DevOps issuer. That second option exists precisely because those connections are out of scope for this retirement.

What to do with the eleven months

The temptation is to wait for the conversion experience to get better, and there is a version of that argument. There is also a version where the inventory script is fifteen minutes and the answer is four connections, two of which belong to a team that no longer exists.

Run the sweep now and put the number somewhere visible. If it is small, convert them this month and stop reading banners for a year. If it is large, or if half of them point at identities nobody claims, that is not a conversion project. That is an ownership problem with a hard date attached, and eleven months is roughly how long those take.