If you opened a pipeline run this week and saw a yellow banner on one of your Azure service connections, this is what it’s about. Microsoft is retiring the Azure DevOps issuer for workload identity federation, and the clock started ticking on July 1, 2026.
The good news: nothing breaks on that date. The deprecation is a warning, not a hard cutoff. The actual end of life is a full year out — July 1, 2027. So you have time. But “you have time” is exactly the framing that gets a migration parked in a backlog until someone’s deploy fails twelve months from now, by which point nobody remembers what the banner said.
Here’s the whole thing: what’s changing, who’s actually affected (it’s narrower than the banner makes it look), how to find every at-risk service connection across your org, and how to convert them without a deploy outage.
What’s actually being retired
Workload identity federation (WIF) is how your Azure DevOps pipelines authenticate to Azure without a stored secret. Instead of a service principal client secret rotting in a variable group, the pipeline presents a short-lived OIDC token, and Azure trusts it because of a federated credential you set up ahead of time. That federated credential includes an issuer — the URL Azure uses to decide whether to trust the incoming token.
Until recently, Azure DevOps minted those tokens under its own issuer: https://vstoken.dev.azure.com. That’s the piece going away. Since November 2025, every new WIF service connection has been created against the Microsoft Entra issuer instead — tokens minted by Entra, under https://login.microsoftonline.com/<tenant-id>. The Entra issuer also pins the federation subject to an immutable identifier, so a federated credential can only ever be used by the exact service connection it was created for. That’s a real security improvement, not just a plumbing change — the old subject could theoretically be reused if a connection was recreated with the same name.
So the migration is issuer-to-issuer: same WIF mechanism, same OIDC flow, different issuer and a tightened subject. If you stood up your service connections in late 2025 or 2026, you may already be on the Entra issuer and have nothing to do. The banner tells you which ones aren’t.
The dates that matter
- July 1, 2026 — The Azure DevOps issuer is deprecated. Existing connections that still use it start showing a warning in pipeline runs and in the service connection settings UI. They keep working.
- July 2026 – June 2027 — The warning window. This is your migration runway.
- July 1, 2027 — End of life. The Azure DevOps issuer is no longer supported. Connections that still rely on it stop authenticating.
Twelve months of runway sounds generous, and it is. The trap is that the failure mode at the end is silent until it isn’t — a connection works right up until it doesn’t, and then every pipeline that touches it fails at once. Better to drain the list early.
Who’s affected — and who can ignore this
This is the part the banner doesn’t make obvious, and it’s worth getting right before you scope the work. The retirement only applies to service connections that are all of:
- In the Azure public cloud, and
- Using a single-tenant Entra application or a managed identity.
Explicitly excluded, at least for now:
- Multi-tenant applications (
signInAudience: AzureADMultipleOrgs). These still need the Azure DevOps issuer because the Entra issuer doesn’t yet support minting tokens that work across tenants in one atomic operation — think cross-tenant peered virtual networks deployed in a single task. - Sovereign and non-public clouds: Azure Government, Azure China, Azure Stack.
For those excluded cases, the Azure DevOps issuer keeps working past July 2027 until the Entra issuer closes the feature gap. Microsoft has said it’ll announce a separate retirement for them later. So if your platform is heavy on multi-tenant deployments, don’t force those connections over yet — you’ll just hit the gap the exclusion exists to protect you from.
For everyone else — which is most teams running a normal single-tenant setup in Azure commercial — the conversion is on you before July 2027.
Find every at-risk service connection
You can’t convert what you can’t see, and the UI warning only helps one project at a time. If you’ve got service connections scattered across dozens of projects, you want a list.
The UI does surface them: connections still on the Azure DevOps issuer float to the top of the service connections list with a warning indicator. Fine for a small org. For anything bigger, query the REST API.
List the endpoints in a project:
ORG="https://dev.azure.com/yourorg"
PROJECT="YourProject"
curl -s -u ":$AZDO_PAT" \
"$ORG/$PROJECT/_apis/serviceendpoint/endpoints?type=azurerm&api-version=7.1" \
| jq '.value[] | {name, id, scheme: .authorization.scheme, issuer: .authorization.parameters.workloadIdentityFederationIssuer}'What you’re looking for is connections where authorization.scheme is WorkloadIdentityFederation and the issuer parameter still points at vstoken.dev.azure.com. Anything already showing login.microsoftonline.com is done. Connections still on ServicePrincipal with a stored secret are a different (and more urgent) problem — they should move to WIF entirely, which I’ll come back to.
To sweep the whole org, enumerate projects first (GET _apis/projects?api-version=7.1) and loop. A short script that dumps org / project / connection / issuer to CSV gives you the actual work list, and it’s the artifact you’ll want to track against — check off each connection as it flips to the Entra issuer.
If you’d rather not write the loop yourself, the community devopsshield/azure-devops-workload-identity-federation tooling on GitHub wraps the audit-and-convert flow across an org and is worth a look before you reinvent it.
Converting a connection
The conversion itself is genuinely a button. On a flagged service connection, open its settings and select Update. Azure DevOps creates a new federated credential against the Entra issuer, keeps the old Azure DevOps issuer credential in place, and only switches pipeline jobs over after it verifies the new credential actually works. That overlap is the important detail — there’s no window where the connection is half-migrated and deploys fail. If the new credential can’t be validated, the old one stays live and you stay on the warning.
There’s a catch worth planning for: the Update button assumes Azure DevOps can write the new federated credential into your identity for you. That needs permission on the underlying Entra app registration or managed identity. If your identities are locked down — and in a decent platform setup they should be — the person clicking Update in Azure DevOps may not have that access.
For that case, the UI gives you a “create federated credential in” link that hands you the issuer and subject values to apply yourself. You (or whoever owns the identity) add a federated credential to the app registration / managed identity with:
- Issuer:
https://login.microsoftonline.com/<your-tenant-id> - Subject:
sc://<org-name>/<project-name>/<service-connection-name> - Audience:
api://AzureADTokenExchange
The subject format is the immutable one I mentioned — it encodes the exact org, project, and connection name. Get it from the UI rather than hand-typing it; a typo here means the token exchange fails validation and the connection won’t verify.
Once the federated credential exists on the identity, go back and complete the Update in Azure DevOps. It validates, flips the jobs, and the warning clears.
Rolling back, and testing first
Because the old credential isn’t deleted during conversion, rollback is mostly free until you clean up. If a converted connection misbehaves, the Azure DevOps issuer federated credential is still sitting on the identity. The cleaner safety net, though, is to not convert your most critical connection first.
Pick a low-stakes connection — a sandbox subscription, a non-prod deploy — convert it, and run an actual pipeline against it. Not a dry run; a real job that authenticates and touches Azure. Confirm the token exchange works end to end. Then work outward to production. Order matters less than having proven the flow once in your own tenant before you touch the connection that ships your product.
After everything’s converted and stable, you can remove the leftover vstoken.dev.azure.com federated credentials from your identities. No rush on that — they’re inert once jobs are using the Entra issuer — but it’s tidy, and it closes the door on the old subject.
Automating it across a large estate
A handful of connections? Click Update, done. Hundreds across many projects and you’ll want this scripted, and this is where I’ll be honest about the rough edges.
The supported, well-documented conversion path is the UI Update flow and the audit you can do over the REST API. Azure DevOps does expose a ConvertAuthenticationScheme operation on the service endpoint PUT — but read carefully, because that operation converts a secret-based service principal connection to workload identity federation. It’s the right tool if your audit turned up old ServicePrincipal connections with stored secrets (which you should be migrating regardless), but it is not the issuer-to-issuer conversion the July 2026 retirement is about. Don’t conflate the two.
If you manage service connections as code with the Terraform azuredevops provider, the practical move is to let the provider recreate the affected azuredevops_serviceendpoint_azurerm resources so they’re provisioned fresh against the Entra issuer, paired with the matching azuread_application_federated_identity_credential (or managed identity equivalent) carrying the new issuer and subject. Test that on one workspace before you run it across all of them — there’s a known history of the provider behaving differently as Azure DevOps shifted the default issuer underneath it, so pin your provider version and read the plan output before applying.
For everyone in between — too many to click, not yet fully IaC — the org-wide audit script plus the devopsshield tooling is the pragmatic middle path. Generate the list, convert in batches by project, re-run the audit to confirm the issuer flipped, and keep going until the list is empty.
A checklist before July rolls around
- Run the REST audit across every project and produce a list of connections still on
vstoken.dev.azure.com. - Filter out the genuinely excluded ones: multi-tenant apps and any sovereign/non-public cloud connections. Leave those alone.
- Confirm who has write access to the underlying app registrations and managed identities — that’s the actual bottleneck, not the Azure DevOps side.
- Convert one non-prod connection, run a real pipeline against it, verify the token exchange.
- Batch through the rest, re-auditing after each batch.
- Once stable, prune the leftover Azure DevOps issuer federated credentials.
One thing worth doing while you’re in here anyway: if the audit turns up any service connections still authenticating with a stored client secret, those are a bigger liability than the issuer change. The retirement is a nudge to get the whole estate onto secretless WIF, not just to swap one issuer URL for another. You’re already in the service connections list — might as well drain both.
Start with the audit script today. Even if you don’t convert a single connection this week, knowing the real size of the list — and how much of it the exclusions wipe out — turns a vague July deadline into a finite, schedulable task.
Sources: Azure DevOps Blog — Retirement of Azure DevOps issuer, Microsoft Learn — WIF Azure DevOps issuer retirement, Microsoft Learn — Configure a workload identity service connection, devopsshield/azure-devops-workload-identity-federation.