Implement and manage Azure DevOps service connections and PATs

Service connections

A service connection stores how a pipeline authenticates to an external system. For Azure Resource Manager the current pattern is workload identity federation — a managed identity or app registration with a federated credential, and no secret stored.

Two authorisation controls matter:

Pipeline permissions — authorise each pipeline individually rather than granting access to all pipelines. The "grant access permission to all pipelines" checkbox is convenient and is exactly what lets an unrelated pipeline use your production credential.
Checks — a service connection is a protected resource, so its owner can attach approvals and checks.

The Azure DevOps issuer is being deprecated for workload identity federation. Connections flagged as deprecated must be converted to the Microsoft Entra issuer; convert the existing connection rather than creating a replacement.

Personal access tokens

A PAT is a user credential. Scope it minimally, set the shortest workable expiry, and never use one where a service connection or managed identity would do.

The recurring failure: a PAT belonging to an engineer who has left, still authenticating a nightly pipeline, until it expires and the pipeline breaks with an authentication error nobody can explain.

Primary sources