About a year of lead time, then a forced move. Microsoft announced on June 22 that the Azure DevOps issuer used in workload identity federation (WIF) service connections will be retired on July 1, 2027, per the Microsoft DevOps Blog. Azure Pipelines that already abandoned long-lived secrets in favour of WIF now have a follow-up migration on the calendar: switching the federated credentials on their service connections from the Azure DevOps issuer (the https://vstoken.dev.azure.com prefix) to the Microsoft Entra issuer.
The issuer that's being retired
WIF lets a workload exchange a signed OIDC token from a trusted issuer for an Azure access token, no client secret on disk. Today an Azure DevOps service connection can wire that trust up under either of two issuer URLs in the federated credential on the Entra side: the Azure DevOps issuer, with the https://vstoken.dev.azure.com prefix, or the Microsoft Entra issuer. After July 1, 2027, only the Entra issuer will be accepted. The change is part of a wider Microsoft initiative to standardize on the Entra issuer across Azure services that implement workload identity federation, the blog says.
The blog frames this as a deprecation, not a behaviour change. The protocol stays the same, the trust relationship stays the same, only the issuer URL on the federated credential moves.
Which connections are actually in scope
The deprecation is narrower than the headline reads. It applies only to service connections in Azure public cloud that target single-tenant Microsoft Entra applications or managed identities. Microsoft explicitly excludes three categories from this announcement:
- Service connections to Azure Government, Azure China, or Azure Stack.
- Service connections backed by multi-tenant Entra applications, the ones registered with
signInAudience: AzureADMultipleOrgs. - The default federated identity flow on those excluded clouds and multi-tenant apps remains as it was.
If every WIF connection in your estate is in one of those bands, this announcement does not touch you yet. If you run a mixed estate, you will be holding two issuer policies in parallel until 2027 and possibly beyond.
How the migration shape looks
For everyone in scope, this is a federated-credential rewrite, not a service-connection rebuild. The federated credential on the target Entra application or managed identity needs an issuer URL pointing at the Entra issuer instead of the vstoken.dev.azure.com prefix, and a subject that matches what the Azure Pipelines side sends under the Entra issuer. The Azure DevOps service connection itself stays in place.
The blog's framing is that platform teams have roughly a year to do this on their own schedule rather than under a force-cutover. The practical sequence is the same one any federated-credential migration follows:
- Inventory every service connection in the affected clouds, by Entra-application or managed-identity target.
- Add a second federated credential on each target, pointed at the Entra issuer, alongside the existing Azure DevOps issuer credential.
- Cut Azure Pipelines over to the Entra-issued credential in a low-stakes pipeline first, watching for auth failures.
- Remove the old
vstoken.dev.azure.comcredential once nothing is using it.
A code example with placeholders for the credential body, because every tenant will produce different real values:
# Federated credential on the target Entra app / managed identity
issuer: https://<entra-issuer-url>
subject: <subject-from-azure-pipelines-side>
audiences:
- api://AzureADTokenExchange
Do not copy a subject value from another tenant. Read it from a test pipeline against your own tenant first.
Where this catches you
This is a year of lead time, but the catch is upstream of the change-window math. Federated credentials live in two places at once: the Entra side (on the application or managed identity) and the Azure DevOps side (on the service connection). Platform teams discover that asymmetry the first time they try to migrate one pipeline and find the team that owns the Entra application sits in a different tenant, or a different change-management process. Inventory both ends before scheduling the cutover, otherwise the change-freeze you thought you had only covers one side of the trust.
The exclusion list is the second snag. A platform team that standardized on multi-tenant Entra apps for cross-tenant pipelines, or that runs CI in Azure Government, gets a partial migration: the public-cloud single-tenant connections move, the rest sit on the Azure DevOps issuer indefinitely. That is two WIF configurations to keep documented, two break-glass procedures, two on-call run-books.
Continuity caveat
Microsoft is keeping multi-tenant applications and sovereign clouds out of scope for this announcement, which means the vstoken.dev.azure.com issuer is not going away in absolute terms on July 1, 2027, only on the most common configuration. Teams running mixed estates need to track the same WIF policy in two flavours through the deadline and out the other side, until or unless Microsoft brings the excluded categories into the same standardization.