Azure DevOps PATs and service connections security: Replace, Scope and Monitor Pipeline Credentials

Azure DevOps personal access tokens and service connections are the two credentials that most often let a pipeline, or an attacker holding one, reach source code and production cloud subscriptions without a human signing in. PATs are bearer passwords tied to a user; service connections hold standing access to Azure, Kubernetes, registries and other services on behalf of every pipeline allowed to use them. Microsoft's guidance now points away from both as static secrets: Microsoft Entra tokens for automation, workload identity federation for Azure Resource Manager, and organisation-scoped PATs only where nothing else works. This guide goes deeper than the Azure DevOps Security Guide on these two credential types: PAT format and audit events, the PAT lifecycle API, Entra-token replacements, service connection roles, pipeline authorisation, sharing and conversion to federation. It is for DevOps platform owners and identity teams. Facts are from Microsoft Learn as checked on 28 October 2026.

Key takeaways

• Global PATs end on 1 December 2026. Microsoft states that all existing global PATs stop working on that date; anything still using one must move to an organisation-scoped PAT or Entra authentication first.
• PAT use is not logged. The audit log records PAT creation, update, expiry, revocation and public discovery, but not authentication, so it cannot tell you whether a PAT is still in use.
• Automation should not hold a PAT. Service principals and managed identities get short-lived Entra tokens, and Microsoft recommends them for applications and pipelines.
• Service connections have standing access. Restrict each one to named pipelines, add approvals and checks, and avoid "Grant access permission to all pipelines".
• Federate Azure Resource Manager connections. Workload identity federation removes the stored secret; connections on the old Azure DevOps issuer retire on 1 July 2027.

How the two credential types work

A personal access token is, in Microsoft's words, an alternative password for Azure DevOps authentication. It is sent as HTTP Basic authentication, can be scoped (for example vso.build, or Agent Pools Read and manage for agent registration) and cannot grant more permission than its owner holds. A service connection is a stored set of connection details and credentials (a federated identity, a service principal secret or certificate, a kubeconfig, a registry PAT, an API token) that pipeline tasks use to reach an external service. It is a non-human identity in its own right, with an owner, a scope and a usage history.

The offboarding row matters. A disabled or removed account's PATs cannot access the organisation, but they are not deleted, and Microsoft notes that if access is restored, an unexpired PAT works again with the user's current permissions. Revoke PATs explicitly during leaver processing. For Entra-backed organisations, a new PAT that is not used to sign in within 90 days becomes inactive.

Controlling PATs: policy, scope and lifecycle

Tenant policies (restrict global PATs, restrict full-scoped PATs, maximum lifespan, automatic revocation of leaked PATs) and the organisation policy to restrict PAT creation are set out in the Azure DevOps Security Guide. On top of that baseline:

• One PAT per tool or workflow: with the fewest scopes and shortest practical lifetime, so revocation is surgical and the audit trail names an integration.
• Keep secrets out of display names: Microsoft warns against putting personal data or any part of the token in the name.
• Never in Git remotes: do not embed PATs in remote URLs, .git/config, pipeline YAML, source code or logs. Store them in Azure Key Vault or another secret store.
• Read the notifications: Azure DevOps emails the owner when a PAT is created and before it expires. An unexpected creation notice (tools create PATs with names such as git: https://dev.azure.com/{organization} on {machine}) is a prompt to check and, if unrecognised, revoke and change the password.
• Rotate by create, swap, revoke: regenerating a PAT in the portal invalidates the old value at once. The lifecycle API has no single-step regenerate, so rotate by creating a new PAT, updating dependants, then revoking the old one by authorizationId.

The PAT lifecycle and administration APIs

The PAT lifecycle API lives at vssps.dev.azure.com/{organization}/_apis/tokens/pats (list with GET, create with POST, revoke with DELETE). It requires a Microsoft Entra user-delegated token with the vso.pats scope; service principals and managed identities cannot manage PATs. A create response returns the secret once in patToken.token, so make sure no wrapper logs the response body. Set allOrgs to false in every create request. For administrators, the Token Administration APIs revoke other users' PATs, which is the tool for offboarding and incident response.

Replacing PATs with Microsoft Entra tokens

Microsoft's direction for applications and automation is Entra tokens from managed identities or service principals. The identity requests a token for Azure DevOps (the documentation uses the scope https://app.vssps.visualstudio.com/.default) and sends it as a bearer token. Use the Azure Identity library and reuse the credential object so it caches and refreshes tokens; Microsoft advises treating tokens as opaque and not relying on a fixed lifetime.

Application identities have their own rules. Each must be added to each organisation explicitly (Organization settings, Users, Add users, using the Object ID from Enterprise applications); membership of an Entra group is not enough. Authorisation comes from Azure DevOps access levels, groups and permissions, not Entra application permissions. Deleting the identity in Entra does not remove its Azure DevOps membership, so deprovisioning needs a step in both places. Conditional Access for workload identities can target service principals, with licensing, but not managed identities. See the Azure RBAC and Service Principals Guide and the Azure Entra Client Secrets Security Guide.

Securing service connections

Each service connection has its own security settings. The roles are:

• Pipeline permissions: Microsoft says not to use "Grant access permission to all pipelines", which covers existing and future pipelines. Authorise each pipeline individually (the run pauses with "This pipeline needs permission to access a resource", and an authorised user selects Permit).
• Approvals and checks: on the connection's Approvals and checks tab, add approvals, branch control or business-hours checks so a production connection is used only from protected branches and approved stages. This is the main defence against a poisoned pipeline using a privileged connection. See the OWASP CI/CD Top 10 CICD-SEC-4 Poisoned Pipeline Execution Guide.
• Sharing: connections are not shared across projects by default, and only organisation-level administrators can share, update a shared connection or unshare it. Each share extends the blast radius; keep a register.
• Scope the target: for Azure Resource Manager, assign roles at resource group or resource level rather than subscription Contributor. A Kubernetes service account connection on a cluster without Azure RBAC gets cluster-wide privileges, so scope with namespaces and a RoleBinding.
• Avoid "Accept untrusted TLS/SSL certificates": install the internal CA on agents instead.
• Use Usage history: it shows which pipelines used the connection. Azure Pipelines may disable connections unused for 100 days and records disable and enable events in the audit log.

Moving Azure Resource Manager connections to workload identity federation

With federation, Azure DevOps issues a token that Entra trusts through a federated credential on an app registration or user-assigned managed identity, so no secret is stored. New connections use the Entra issuer https://login.microsoftonline.com/. Connections that use the Azure DevOps issuer https://vstoken.dev.azure.com are deprecated and retire on 1 July 2027; this applies to eligible connections in Azure public cloud using single-tenant applications or managed identities, not to other clouds or multi-tenant apps.

1. Inventory: list Azure Resource Manager connections per project and record authentication type (secret, certificate, publish profile, federated), issuer, identity, role assignments and sharing.
2. Convert where possible: for flagged connections, use Project settings, Pipelines, Service connections, select the connection, Update, and let Azure DevOps attempt conversion. If it cannot complete, it shows the Issuer and Subject identifier to add manually as an "Other issuer" federated credential with an explicit subject identifier.
3. Rebuild the rest: manually created or cross-tenant connections usually need a new connection, "App registration or Managed identity (manual)" with workload identity federation. The managed identity option suits teams without rights to create service principals or working across tenants.
4. Right-size roles while you are there: the managed identity guide uses Contributor as an example; replace it with the narrowest role at the narrowest scope.
5. Test in a non-production project: run every dependent pipeline, then remove the old client secret or certificate from the app registration. Rollback is reinstating the old connection details, so keep them until the secret is deleted.

The general federation model is in the Workload Identity Federation Guide.

Detection and measurement

Azure DevOps audit retention is 90 days and is not configurable, so stream audit events to a SIEM.

Metrics: global PATs remaining (zero before 1 December 2026); full-scoped PATs; PATs older than the policy maximum; share of Azure Resource Manager connections on federation; connections open to all pipelines; connections without approvals and checks in production.

Because PAT use is not logged, Microsoft advises against using the audit log to decide whether a PAT is stale. Ask the owner, or replace it with a shorter-lived credential and watch what breaks in a test ring.

Common failure patterns

• Leaver PATs left in place: disabled rather than revoked, they return to life if the account is re-enabled.
• Open-access production connections: any pipeline, including one changed in a pull request, can deploy to production.
• Subscription Contributor everywhere: one compromised pipeline owns the subscription.
• Non-atomic rotation: rotating some credentials and missing others leaves the attacker a way back in, as in the Trivy Supply Chain Attack 2026, where an incomplete rotation after a stolen GitHub PAT left valid credentials behind.
• Entra deletion treated as deprovisioning: the application identity keeps its Azure DevOps membership.

Framework mapping

Practitioner checklist

• Find and replace every global PAT before 1 December 2026.
• Revoke PATs (via Token Administration APIs) in every leaver process, not just disable the account.
• Move automation to managed identities or service principals with Entra tokens.
• Set every service connection to named pipelines; remove "all pipelines" access.
• Add approvals and branch checks to production connections.
• Convert Azure Resource Manager connections to federation on the Entra issuer, then delete old secrets.
• Review Endpoint Creators, Endpoint Administrators and cross-project shares quarterly.
• Stream audit events beyond the 90-day retention and alert on the Token events above.

Standards and references

• Microsoft Learn: Use personal access tokens
• Microsoft Learn: Use service principals and managed identities in Azure DevOps
• Microsoft Learn: Service connections
• Microsoft Learn: Service connection permissions
• Microsoft Learn: Workload identity federation service connections
• OWASP: Top 10 CI/CD Security Risks
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Azure DevOps Security Guide, CI/CD Pipeline Identity Security Guide, Workload Identity Federation Guide, Azure RBAC and Service Principals Guide, Leaked Credential Response Playbook.