DEV Community: Leo

Azure DevOps issuer in WIF service connections heads for July 2027 retirement

Leo — Mon, 22 Jun 2026 16:24:27 +0000

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.com credential 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.

`headingoffset` is not the outline algorithm coming back

Leo — Mon, 22 Jun 2026 16:09:15 +0000

The way most screen-reader users navigate a long page is by jumping heading to heading. Get the hierarchy right and the page becomes a table of contents you can step through with a single key; get it wrong, and the page collapses into one undifferentiated wall.

Reusable components have always made that hierarchy harder. Drop a card component into a sidebar and an <h2> inside it suddenly outranks its parent. Drop the same card under an <h3> somewhere else and the levels need to shift again. The pragmatic answer for years has been: pick a level and live with the result.

Firefox has now shipped (behind a flag, per Adrian Roselli's write-up) a small HTML attribute that takes some of that pain away — and a much larger conversation about what it does not do.

What the attribute actually does

Per the source, headingoffset lives on a container and shifts the heading levels of its descendants in the accessibility tree. Put headingoffset="2" on a wrapper and an <h1> inside that wrapper is exposed as a level-3 heading; an <h2> becomes a level-4 heading; and so on. The DOM stays as you wrote it, but the level the assistive tech announces is the offset version.

The values are constrained. Per the source, headingoffset accepts non-negative integers from 0 to 8, and any value greater than 8 is specified to max out at heading level 9.

The reusable-card case is the obvious win. You write the card once with its own internal heading order (an <h1> title, an <h2> subhead) and the page that drops the card in declares where that internal order should sit. No more shipping a component that is wrong everywhere except its first home.

The escape valve: `headingreset`

There is a partner attribute. Per the source, headingreset is a boolean attribute that tells the browser to ignore any inherited headingoffset for the node it sits on and that node's descendants. If a card lands inside a region that has already been offset and you do not want a second offset stacking on top, headingreset puts that subtree back to its raw DOM levels.

That is a small piece of API surface, but it matters. Without a reset, nested offsets compound, and the meaning of "level 2" on the page becomes a function of every ancestor a component happens to land under.

Why this is not the outline algorithm coming back

Here is the part worth saying out loud, because the temptation to read it that way is real.

Per the source, the proposed Document Outline Algorithm, the idea that sectioning elements would shoulder the heading hierarchy for authors automatically, was never part of a finalised HTML specification, and has been abandoned. A brief implementation in JAWS exists in the historical record; the source's verdict is that the implementation demonstrated the algorithm was unworkable.

headingoffset is not that. It does not look at structure. It does not infer. It is an explicit, author-set value that says: shift the levels under this node by this many. If you do not set it, nothing happens. The responsibility for the page's overall heading structure stays with you, exactly where it was last week.

In other words: an <h1> inside a <section> is still an <h1> unless you tell the browser otherwise.

A caveat the source flags hard

One detail not to skip. Per the source, computed heading levels above 6 still trip bugs in JAWS and TalkBack at the time of writing, and the author's advice is to avoid producing computed levels above 6 until those bugs are fixed. That is a hard constraint on how you use the attribute, not a footnote.

So headingoffset="3" on a wrapper whose internal headings start at <h4> produces a computed level of 7, and that is exactly the range the source is telling you to avoid for now. Walk that math through every component before you ship.

Where this leaves you

The judgement from the source is that headingoffset is a useful primitive for component reuse and nothing more. It does not turn <section> into a structural tool. It does not absolve the author of getting the document's heading order right.

For your next PR with this enabled:

Treat headingoffset as a property of where the component lands, not of the component itself.
Use headingreset whenever you carry a subtree across boundaries and want its inner levels restored.
Keep computed levels at 6 or below until the screen-reader bugs the source flags are fixed.
Leave the document's spine, the page's own <h1> and section headings, as ordinary hand-authored HTML. The new attribute complements that work; it does not replace it.

The platform has given you a small, honest tool. Use it for the job it actually does.