We are announcing the deprecation of the Azure DevOps issuer in workload identity federation (WIF) service connections, with planned retirement on July 1, 2027. The Azure DevOps issuer uses the https://vstoken.dev.azure.com prefix in federated credentials. This change is part of Microsoft’s broader initiative to standardize on the Microsoft Entra issuer across Azure services that implement workload identity federation.
Important This deprecation only applies to service connections in Azure public cloud that use single-tenant Microsoft Entra applications or managed identities. Service connections targeting non-public clouds (for example, Azure Government, Azure China, or Azure Stack) and service connections that use multi-tenant applications (
signInAudience: AzureADMultipleOrgs) are explicitly excluded from today’s deprecation announcement. The Azure DevOps issuer will continue to be supported for these scenarios until they’re supported by the Microsoft Entra issuer.
Background: Workload Identity Federation in Azure DevOps
More than two years ago, we introduced workload identity federation support for Azure DevOps, enabling secretless authentication between Azure Pipelines and Azure resources with managed identities or app registrations. This was a significant security improvement over the use of app registrations with secrets.
Workload identity federation has proven to be an invaluable feature for our customers, with strong adoption across organizations seeking to eliminate long-lived credentials from their CI/CD pipelines.
Microsoft is standardizing on the Microsoft Entra issuer (https://login.microsoftonline.com/) for workload identity federation across services. Instead of using an OIDC token minted by Azure DevOps in the OpenID Connect (OIDC) flow underpinning workload identity federation, the flow uses an OIDC token minted by Microsoft Entra. The Microsoft Entra issuer has been used for new service connections since last year, and today more than 50% of all workload identity federation service connections use the Microsoft Entra issuer.
Timeline
Since November 2025, new workload identity federation service connections created in Azure DevOps have been using the Microsoft Entra issuer. Dates of upcoming changes are:
- July 1, 2026: The Azure DevOps issuer (
https://vstoken.dev.azure.com) is deprecated. New service connections created in Azure DevOps will continue to use the Microsoft Entra issuer by default. - July 2026 – June 2027: Existing service connections using the Azure DevOps issuer will show a warning in pipeline runs and the service connection configuration UI (see below).
- July 1, 2027: The Azure DevOps issuer will reach end of life and will no longer be supported.
What You Need to Do
Service connections that use the Azure DevOps issuer (https://vstoken.dev.azure.com) are listed at the top of the service connection list, with a warning indicating they need action:
To convert a service connection to the Microsoft Entra issuer, select the Update button:
If you don’t have access to the underlying identity and can’t create a federated credential for the Microsoft Entra issuer, select the Create federated credential in link to create the federated credential and populate it with the issuer and subject manually:
More information: Workload identity federation issuer conversion
FAQ
Q: Will my existing pipelines break immediately?
A: No. Service connections that use the Azure DevOps issuer will continue to work until retirement on July 1, 2027. We recommend planning your conversion before then.
Q: How is the Microsoft Entra issuer different?
A: The issuer is an implementation detail that’s hidden during regular use. Pipeline tasks work the same and don’t require changes. The Microsoft Entra issuer provides additional benefits by using Microsoft Entra-minted tokens and an immutable federation subject, so the federated credential is guaranteed to be used by the service connection it was created for.
Q: Can I use the Microsoft Entra issuer today?
A: Yes. All new service connections created today use the Microsoft Entra issuer by default. You can also convert existing connections by following the steps above.
Q: Is there any downtime during the conversion, and how long does it take?
A: During the conversion, the existing Azure DevOps issuer federated credential will continue to be used by pipelines that reference the service connection. After we verify that the new Microsoft Entra issuer federated credential works during conversion, pipeline jobs will start using the Microsoft Entra issuer.
Q: What if I have questions about the conversion?
A: Please review Workload identity federation conversion and Workload identity federation troubleshooting. You can also reach out to Azure DevOps Support or visit the Azure DevOps Developer Community.
Q: I create service connections in automation and need to be able to know the federated credential subject before creating it.
A: See Use scripts to automate workload identity service connections.
Q: My Azure DevOps organization has an organization-wide exception to use multi-tenant apps to prevent the error AADSTS70052: The identity must be a managed identity or a single tenant app. What will happen?
A: We’re working on an experience that will provide a service connection-specific exception for multi-tenant apps instead. Until then, you will see no difference in experience.
Is there any documentation on how to automate the migration?
I can see how to use the REST API to trigger the migration for a given service connection. But all of our migrations are failing, requiring us to manually apply the new issuer/subject to the service principal. And I don’t see how to get the new issuer/subject out of the API currently.
We have hundreds of service connections so doing them all from the web is not feasible if automated migration is not going to work.
Hi Andrew. What kind of user did you use to you execute the migration? The On-Behalf-Of access the REST API used to create a new credential in Azure/Entra works for user principals only.
We plan to make a conversion command available to the Azure DevOps CLI that will address scenario’s where there is Entra/Azure – Azure DevOps permission misaligment. We plan to have this before the autumn.
That documentation is a good starting point for trigging migrations en masse (using the MigrateToEntraIssuer operation), although I'd already gotten something very similar to that from the API docs & looking at the browser traces.
Where I'm stumbling is recovery when the migration operation fails because it could not create the new WIF credentials.
If the operation fails, the new issuer/subject combination is not returned from the operation endpoint you pointed at with that example script (only the existing one), nor is it returned from any other endpoint for gathering service connection information that I've tried.
Without the new issuer/subject combination, I can't...
You can use a similar approach to Convert multiple service connections with a script
I tried it as my organization admin user principal, both on the web & from the API.
There’s a warning message in my pipelines:
The URL in there tells me I need to be inside a Microsoft VPN to read it… You might want to make that page public / point the redirect to here.
UPDATE: I can’t even post that URL here because it returns 403. 🤦♂️ So you need to remove the spaces above…
Thanks for reporting. We will fix this link, it should be https://aka.ms/azdo-issuer.