Use workload identity federation for Azure Resource Manager service connections wherever your setup supports it. Microsoft says it eliminates the need for secrets and secret management. A secret based connection stores a credential that can expire, leak in a log, or be copied by anyone with enough pipeline access.
The two approaches compared
| Question | Secret based connection | Workload identity federation |
|---|---|---|
| What is stored in Azure DevOps? | A client secret or certificate | A trust relationship, no secret |
| What happens when it leaks? | The holder can authenticate until you rotate it | There is no static credential to leak |
| Who handles rotation? | You, on a schedule | Nothing to rotate |
| Works with | Every connection type | Supported types, including Azure Resource Manager with an app registration or managed identity |
Microsoft's service connection page states that Azure Pipelines supports multiple authentication options for Azure, and recommends federation with either an app registration or a managed identity. The page also lists Azure DevOps and Azure Container Registry connections that support federation.
Why a stored secret is the weaker design
Pipelines run code from repositories. Anyone who can change what a pipeline executes can try to read what it can read. Masking in logs is helpful but Microsoft's own secrets guidance says it is not foolproof. When there is no secret to print, that whole class of leak disappears.
A federated connection still needs controls, because the pipeline can use the identity while it runs. Scope the identity's permissions in Azure to the minimum, and do not grant access to all pipelines.
The issuer change to plan for
Microsoft states that for workload identity federation connections in the Azure public cloud, the Azure DevOps issuer (https://vstoken.dev.azure.com) retires on 1 July 2027. New federation connections use the Microsoft Entra issuer by default. Azure DevOps flags affected connections in the list and offers an Update action to convert them. If you cannot use it because you lack identity access, Microsoft documents a manual federated credential approach.
Action: filter your connection list for flagged items, and schedule the conversion well before mid 2027.
Migration steps
- Inventory your Azure Resource Manager service connections and their authentication type.
- Pick one low risk connection and convert it, or create a new federated connection beside it.
- Point a test pipeline at the new connection and confirm deployment works.
- Switch the remaining pipelines, then delete the old secret from the app registration.
- Remove the all pipelines option and add approvals and checks on the connection.
- Repeat for container registries and other types that support federation.
When a secret is still the answer
Some types, such as certain generic or third party connections, have no federation option. For those, store the value in a variable group or a key vault, scope who can use it, and set an expiry reminder. Microsoft's guidance is to use another method when you can, because secrets carry inherent risk.
Quick check
Does federation remove the need to restrict pipeline access?
No. The pipeline can still use the identity while it runs, so keep Azure permissions minimal and authorize only the pipelines that need it.
What do I do if my connection is flagged for the issuer change?
Select Update on the flagged connection. If you lack identity access, follow Microsoft's manual federated credential setup.
Safeguard checks dependencies and configuration in your repositories, and you can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
