Azure DevOps Service Connection: PAT-Free Pipelines

Azure DevOps service connection support sounds like a small update until you count the Personal Access Tokens hiding in pipelines, variable groups, feed restores, template repositories and “temporary” scripts. On August 6, 2026, Microsoft announced that pipelines can use an Azure DevOps service connection backed by Microsoft Entra workload identity instead of a PAT or build session token.

It fits the broader push toward secretless automation: shorter-lived tokens, workload identities, better audit trails and fewer mystery credentials. The practical question for admins isn’t whether PAT-free is good, but where to use it first without breaking the delivery system.

What changed with Azure DevOps service connection support

The new connection lets Azure Pipelines authenticate to Azure DevOps resources with a Microsoft Entra service principal or managed identity. Microsoft highlights PAT-free authentication, least-privilege permissions, no persistent secrets, audit logging, and access to resources in another organization connected to the same Entra tenant.

It uses Entra workload identity federation, so no long-lived secret sits in a variable, library, task input or script. The connection works for repository resources, cross-organization templates, Azure Artifacts feeds, REST API calls, extension publishing, and the newer AzureCLI@3 task patterns.

Why PATs are the problem

PATs are bearer tokens, often tied to a human account, and they sprawl because the fastest fix for “the pipeline can’t reach that repo” is to paste in a new token. Microsoft’s authentication guidance now recommends Entra ID for new integrations and says to use PATs sparingly, only when Entra isn’t available. They won’t vanish overnight, but new Azure DevOps Services automation should start with managed identities, service principals and service connections.

Where to use it first

Don’t start with the strangest pipeline in the company. Start where the benefit is obvious and the rollback is boring:

• Cross-organization repository checkouts in the same Entra tenant.
• Shared YAML template repositories, which sit at the center of the delivery platform.
• Azure Artifacts restores used across many builds.
• REST API automation: InvokeRESTAPI@1 can use the service connection.
• Scripts calling az devops with a PAT, which AzureCLI@3 can replace with an Entra-authenticated session.

A safe Azure DevOps service connection migration plan

1. Inventory tokens before touching YAML

List where PATs are used: variable groups, pipeline variables, classic releases, service connections, repository resources, feed authentication tasks, scripts and documentation. Flag tokens owned by individuals, tokens with broad scopes and tokens near expiry.

2. Create a purpose-specific Entra identity

The service connection doesn’t create the identity for you. Create a service principal or managed identity and add it as a user in Azure DevOps before creating the connection; for cross-organization access, add it to the target organization too.

3. Grant the minimum permissions

Grant only the project, repo, feed or API permissions needed, and avoid “grant access permission to all pipelines” unless you mean it. A secretless connection with permissions sprayed everywhere is still a mess.

4. Pilot one pattern at a time

Convert one scenario cleanly, such as a cross-organization template repo with an endpoint pointing to the service connection, or a feed restore with NuGetAuthenticate@1. Keep the old path for rollback, but give the PAT a sunset date.

5. Expand and revoke

Roll through shared templates and high-value feeds, confirm audit logs show the expected identity, then revoke the replaced PATs.

Example: a PAT-free template checkout

The key is the endpoint: it names the Azure DevOps service connection, not a secret variable.

resources:
  repositories:
  - repository: templates
    type: git
    endpoint: my-azdo-connection
    name: 'external-project/external-repo'
    ref: 'refs/heads/main'

steps:
- template: azdosc-template.yml@templates

The YAML gets less interesting because the identity work moved into a governed, auditable connection. That’s the point.

Governance checklist

• Name service connections by purpose, not by person.
• Use one identity per trust boundary where practical.
• Add owners and a runbook before broad rollout.
• Review project, repo, feed and service connection permissions.
• Confirm audit logs show the expected identity.
• Revoke replaced PATs after validation.

Watch-outs before rollout

• Services vs. Server: Entra ID and OAuth 2.0 authentication are available for Azure DevOps Services only. On-premises Azure DevOps Server still relies on Windows authentication, .NET client libraries or PATs.
• The identity must be added to Azure DevOps, not just created in Entra.
• Federated credentials may need an Entra admin. Without Graph permissions, the UI provides issuer and subject values for manual setup.
• Service connections hold standing access, even after the pipeline that used them is retired. Review them periodically.
• AI-assisted DevOps raises the stakes. With the Azure DevOps Remote MCP Server generally available since August 2026, AI clients can reach delivery workflows, so identity hygiene matters more.

Recommended next step

Treat the Azure DevOps service connection as a PAT-reduction project. Pick three pilots: one cross-org checkout, one shared template repo and one feed restore or REST task. Build the identity, create the connection, test, confirm audit logs, then revoke the old token. Small, controlled migrations beat heroic token bonfires. For the same idea on the Azure side, see Azure API Management managed identity, and for review automation, Copilot code reviews for Azure Repos.

Last reviewed: October 2026

Sources

• Use the Azure DevOps Service Connection instead of a PAT or build session token (Microsoft DevBlogs)
• Access Azure DevOps with Microsoft Entra workload identity (Microsoft Learn)
• Service connections in Azure Pipelines (Microsoft Learn)
• Authentication methods for Azure DevOps integrations (Microsoft Learn)
• Azure DevOps Remote MCP Server is generally available (Microsoft DevBlogs)