What does configuring an Azure DevOps Azure Resource Manager service connection with workload identity federation change, and how does Microsoft Entra ID decide to trust it?

## The problem being removed The traditional Azure Resource Manager service connection authenticates with a service principal and a client secret. Azure DevOps stores that secret, and every pipeline authorised to use the connection can act with the identity behind it. The failure modes are well known: the secret is a long-lived, high-value credential sitting in a CI system; it expires on a date nobody diarised, so a deployment fails at an inconvenient moment; and rotation is a manual chore that gets skipped. Workload identity federation deletes the secret from the picture. ## The exchange, step by step 1. A pipeline job uses the service connection. 2. Azure DevOps mints a short-lived token that asserts *which service connection is running*. That token is issued by Azure DevOps, not by Entra. 3. That token is presented to Entra ID as a client assertion, asking for an access token for a specific app registration or user-assigned managed identity. 4. Entra checks whether the target identity has a **federated identity credential** whose configured issuer, subject and audience match the presented token. 5. On a match, Entra issues a normal short-lived access token, and the deployment tasks use it against Azure Resource Manager exactly as before. Nothing durable is stored on the Azure DevOps side. The credential material exists only for the length of the run. ## The three fields that establish trust ```json { "name": "azure-devops-prod", "issuer": "https://vstoken.dev.azure.com/00000000-0000-0000-0000-000000000000", "subject": "sc://contoso/Payments/prod-arm-connection", "audiences": ["api://AzureADTokenExchange"] } ``` - **Issuer** identifies your Azure DevOps organization by its GUID. It is what stops another organization's tokens being accepted. - **Subject** is the precise identity being federated: organization, project, and service connection name. This is the field that carries the authorisation decision, and it is deliberately narrow — not "any pipeline in this org" but "this one connection in this one project". - **Audience** states who the token is for, so a token minted for this exchange cannot be replayed against a different relying party. All three must match. This is the same issuer/subject/audience triple that federation uses generally; what is Azure-specific is the shape of the subject and the fact that the unit being federated is the *service connection object*, not a repository or a branch. ## The consequence people trip over Because the subject string embeds the organization name, the project name and the connection name, anything that changes those strings invalidates the trust. Renaming a service connection, renaming a project, or moving a connection between projects all break authentication with an Entra error about no matching federated credential — not with a helpful message about renaming. The federated identity credential must be updated to the new subject. Teams that generate connections through infrastructure-as-code should treat the subject as a contract and avoid cosmetic renames. ## Scoping and combining with checks Federation removes the secret but does not by itself limit blast radius. A federated identity with Owner on a subscription is still Owner on a subscription. Two things bring it back under control. First, ordinary Azure role assignments: grant the identity only the roles it needs, on the narrowest scope that works, and use a separate connection per environment so a non-production pipeline cannot reach production. Second, the service connection is itself a **protected resource** in Azure DevOps, so it can carry its own approvals and checks and its own list of authorised pipelines. A branch-control or required-template check on the production connection means that even a pipeline permitted to use it cannot do so from an arbitrary branch or without inheriting a mandated template. ## Practical notes Azure DevOps offers automatic creation of the app registration and federated credential when you create the connection, and a conversion path for existing secret-based ARM connections, so migration does not usually require hand-editing Entra objects. Federation for service connections is a feature of Azure DevOps Services; on-premises Azure DevOps Server does not offer it, which matters when a team is planning a migration off an on-premises instance.