Azure Pipelines Workload Identity Federation: Secure Service Connections and Migrate the Issuer

An Azure Pipelines service connection is more than a convenient name for a credential. It is a protected resource that determines which pipeline can request access to an external system. For Azure Resource Manager deployments, workload identity federation (WIF) lets a pipeline exchange a short-lived Azure DevOps-issued identity assertion for Microsoft Entra-backed credentials instead of storing a client secret in the project. The security result depends on both sides of that exchange: the federated identity trust in Azure and the service-connection permissions and checks in Azure DevOps.

There is also a time-sensitive migration issue. As of October 5, 2026, Microsoft documents that eligible WIF service connections using the Azure DevOps issuer, https://vstoken.dev.azure.com, are deprecated and will retire on July 1, 2027. New WIF service connections use the Microsoft Entra issuer, https://login.microsoftonline.com/, by default. The conversion requirement is based on issuer, not service-connection type: Microsoft specifically lists Azure Resource Manager, Docker, and extension-created connections when they use the deprecated issuer. The retirement scope is not universal: the notice excludes connections for non-public clouds and multitenant applications. Inventory the actual issuer and eligibility of each connection rather than assuming all federated connections are affected.

Keep the credential exchange and the authorization boundary separate

The federated credential is the trust decision: it states which issuer, subject, and audience can obtain a token for an app registration or managed identity. Azure role assignments then decide what that identity can do. Azure DevOps adds another boundary by deciding which pipelines can consume the service connection and which checks must pass first. A correct trust relationship with broad subscription Contributor access is still broad access; a narrowly scoped Azure role attached to a service connection open to every pipeline is still an unsafe pipeline boundary.

Use a distinct identity and service connection for each application and deployment environment where the permissions differ. Assign only the Azure role and scope the deployment requires, ideally a resource group or individual resource rather than a subscription, and separately authorize only the intended YAML pipelines. Avoid a shared production identity that every project can invoke.

Create or convert the connection using its generated trust values

For a new Azure Resource Manager service connection, choose workload identity federation with the appropriate identity type (app registration or managed identity) and Azure cloud. The exact issuer and subject identifier are generated for the service connection. Use those displayed values to create the federated credential; do not copy an issuer/subject tuple from another project or invent one from a blog example. The connection name participates in the subject identifier, so renaming or recreating the connection is an identity-trust change, not just UI housekeeping.

For an existing connection marked as using the deprecated issuer, first use Azure DevOps’s supported automatic conversion when available. Microsoft recommends converting the existing connection rather than replacing it, which avoids editing every pipeline that refers to its name. If automatic conversion cannot complete, follow the service-connection conversion workflow and add the issuer, subject, and audience values that Azure DevOps shows to the identity’s federated credentials. Azure DevOps and Azure/Entra permissions are separate: an endpoint administrator may edit a connection but still need an identity owner to add federation or an Azure administrator to assign the target role. Plan that coordination before the deadline.

After conversion, run a real pipeline using that service connection and validate the effective identity and scope. A successful “verify” button is useful configuration evidence, but the deployment job should also demonstrate the intended operation and a denied operation outside its scope. Keep a rollback plan that does not silently reintroduce a static secret.

Put controls on the service connection, not only in editable YAML

Approvals and checks are managed on protected resources outside the pipeline YAML. This matters because a contributor able to change YAML should not be able to remove the only production approval. Azure Pipelines supports checks on service connections, environments, repositories, agent pools, secure files, and variable groups. For a production Azure connection, combine explicit pipeline authorization with branch control and a required-template check where your governance model supports it. Add human approval when the change’s risk or regulatory process requires it.

Checks run in documented categories: static checks such as branch control, required template, and artifact evaluation; pre-check approvals; dynamic checks; post-check approvals; then exclusive lock. A check timeout or terminal failure prevents the stage from running. Do not mistake a stage condition in YAML for an independently enforced resource check. Conversely, do not add an approval to every environment indiscriminately: select the protected resource and stage boundary that prevents an untrusted pipeline from obtaining the credential.

The following is only a task-shape example; sc-orders-production must be the exact authorized service connection in the project. This query is a smoke test, not a grant of least privilege or a substitute for evaluating the role assignment.

stages:
  - stage: DeployProduction
    jobs:
      - job: VerifyAndDeploy
        steps:
          - task: AzureCLI@2
            displayName: Verify the federated service connection
            inputs:
              azureSubscription: sc-orders-production
              scriptType: bash
              scriptLocation: inlineScript
              inlineScript: |
                az account show --query '{tenant:tenantId, subscription:id}' --output json

The pipeline itself should avoid printing access tokens, dumping the process environment, or turning on verbose authentication traces. Keep the job short, review every task that runs while the connection is available, and use a trusted agent pool. A self-hosted agent is part of the credential boundary: any other workload sharing that host may become relevant to the identity’s compromise risk.

Treat the 2027 issuer retirement as an inventory and test project

Export or review every Azure Resource Manager service connection and record its issuer, identity type, Azure cloud, tenant, consuming pipelines, role assignments, and owner. Filter specifically for the connections Azure DevOps marks as deprecated. Prioritize production and broad-scope identities, convert a low-risk representative first, then verify the resulting subject, pipeline authorization, logs, and denied access. Continue in batches with owners available to troubleshoot. Do not wait until a release freeze to discover a hidden classic pipeline or stale service connection.

Also distinguish Azure Resource Manager WIF from the separate Microsoft Entra workload identity service connection used for PAT-free access to Azure DevOps organizations, feeds, repositories, REST APIs, or extension publishing. They solve related but different trust problems and have different configuration steps. Name them explicitly in inventory and documentation so that an “Azure DevOps identity” is not mistaken for an Azure subscription deployer.

Production acceptance checklist

The connection uses the intended issuer and federated credential values copied from the live Azure DevOps configuration.
The relevant connection is not in the deprecated issuer cohort, or it has an owner and a tested conversion plan well before July 1, 2027.
Only named pipelines can consume the connection; broad “open access” is disabled.
Resource checks, including branch or required-template controls, are administered outside contributor-editable YAML.
The federated principal has only the necessary Azure roles at the narrowest practical scope.
A test run confirms the expected operation succeeds and an out-of-scope operation is denied.
No client secret or PAT has been retained as an untracked fallback, and token-bearing diagnostics are not logged.
The service connection, federated credential, role assignment, owning team, and conversion evidence are documented and reviewed periodically.

WIF removes the need to keep one long-lived secret in a pipeline library; it does not make every pipeline trustworthy. The durable control is a narrow federation contract combined with resource permissions, protected pipeline provenance, and an exercised migration process.

Related:

Sources: