Azure DevOps opens a Service Connection off-ramp from PATs and build session tokens

Azure DevOps published a preview on August 6 that lets pipelines authenticate against Azure DevOps itself using an Entra-backed Service Connection, in place of a Personal Access Token or Build Session token. For platform teams, the operational read is a path off the long-lived shared secret at the bottom of the quarterly rotation ticket, and out of the ambient permissions that come with a build session.

The announcement, posted by Eric van Wijk, principal product manager, calls the change PAT-free authentication with least-privilege scoping at the pipeline or task level and no persistent secrets via federated credentials. Authentication attempts land in audit logs. That is the vendor description. In on-call terms, it is the same substitution the rest of the CI industry has been making for a few years: swap a token that lives in a variable group for a workload identity a runner federates into at job time.

What the preview actually covers

The Service Connection sits in front of a Microsoft Entra workload identity, either a service principal or a managed identity, and Azure DevOps trades a federated token for it during the job. The blog post lists the specific pipeline surfaces wired up in this preview:

• Repository resources, so checkout and cross-repo YAML template references can point at another Azure DevOps repo through the connection.
• The NuGetAuthenticate@1 task, via a nuGetServiceConnections parameter for private feeds.
• The InvokeRESTAPI@1 task, with connectionType: 'connectedServiceNameAzureDevOps' for calling the Azure DevOps REST API from a job.
• The AzureCLI@3 task, with connectionType: 'azureDevOps' so az devops and az repos commands run under the connection.

An example the post gives for the repo-resource case:

resources:
  repositories:
  - repository: external-repo
    endpoint: my-azdo-connection
    name: 'external-project/external-repo'

The setup step is the one worth reading twice. Before you can create the connection in the classic Service Connections UI, the service principal or managed identity has to be added as an organization user with the permissions the pipeline actually needs. The post also flags a manual fallback in the UI for creating the federated identity credential when the automatic path fails, which usually points at a policy in the target Entra tenant that blocks automatic FIC creation.

Why the timing matters at 3am

The PAT is the workhorse of Azure DevOps automation and the thing that most often leaves an incident channel with the word "expired" attached. Two failure modes come up more or less monthly: the PAT rotates, and a service catalogue you forgot about starts failing checkouts; or the PAT does not rotate, sits with code:read and packaging:read scopes for eighteen months, and shows up in a source-code leak review. Federated workload identity trades both for a short-lived token minted at job time. The vendor calls it no persistent secrets. That is accurate for the token, and neutral about the identity governance underneath it: an over-scoped service principal is still an over-scoped service principal.

The scope of the preview is worth naming plainly. This is Azure DevOps authenticating to Azure DevOps. It does not touch the many Marketplace tasks that reach out to package registries, artifact stores or downstream systems on their own tokens. Those stay on whatever OIDC or PAT paths they already support.

What to check before turning it on

The preview label is doing real work in the post. Three things to verify against your own setup: whether your Entra tenant allows automatic federated credential creation for the pipeline identity or forces the manual UI fallback; whether the tasks you actually depend on are on the covered list or still expect a PAT; and whether the least-privilege story holds after you assign the SP or managed identity the org-level permissions it needs to do anything useful. Azure DevOps documents the covered tasks as an explicit list, which is the honest version of the story.

PATs are not deprecated. This is an opt-in, task-by-task migration, and the value only lands if the rotation debt it removes is real.