Azure DevOps Global PAT Retirement: 2026 Migration Guide
Azure DevOps global Personal Access Tokens stop working on 1 December 2026. If a token's access scope is set to All accessible organizations, Microsoft says it will be fully decommissioned on that date.
One terminology correction matters before planning begins: this is not a retirement of GitHub personal access tokens. Angel Wong's Microsoft announcement is titled Retirement of Global Personal Access Tokens in Azure DevOps. It applies to Azure DevOps Services PATs that authenticate across every Azure DevOps organisation the user can access. Azure DevOps Server is excluded, and organisation-scoped Azure DevOps PATs are not being retired by this announcement.
The risk is operational as well as security-related. A forgotten global PAT may sit inside a pipeline variable, integration platform, deployment script, reporting job or vendor connector. When the deadline arrives, that workload can start returning authentication failures even though the code has not changed. This guide explains how Australian teams can find those dependencies, choose a replacement and test the change without confusing PATs with SSH keys.
What Microsoft is retiring—and when
Global PATs are Azure DevOps bearer credentials with an access scope of All accessible organizations. Their reach grows when the account gains access to another organisation, so one leaked credential can expose a broader set of resources than an organisation-specific token with the same permission scopes.
Microsoft originally planned to block creation and regeneration of global PATs from 15 March 2026. A 5 March update cancelled that intermediate restriction, allowing users to continue creating them until the final retirement. The date that now matters is 1 December 2026: Microsoft says all existing global PATs will be decommissioned and stop working.
The change applies to Azure DevOps Services. Microsoft's announcement explicitly says no changes are being made to global PATs in the on-premises Azure DevOps Server product. It also does not announce the retirement of all PATs. Where modern authentication is not available, an organisation-scoped PAT can remain a compatibility option, provided it has only the required permissions and the shortest practical lifetime.
Find every affected token before the deadline
Start with the owner view in Azure DevOps. Sign in to an organisation, open User settings → Personal access tokens, set Access scope to All accessible organizations and Status to Active. That identifies global PATs owned by the signed-in user.
The portal list is only the start of the audit because it does not tell you every place a token value is consumed. For each result, record the owner, expiry, scopes, organisations reached, business purpose, consuming workload, secret-storage location and support contact. Search approved secret stores, variable groups, self-hosted agent configuration, scheduled scripts, integration platforms and vendor settings. Never print token values into logs or copy them into the migration register.
Prioritise unattended and business-critical workloads. A developer can repair a broken local script quickly; an overnight finance export, release pipeline or customer integration may fail silently until a deadline or incident exposes it. Treat unknown ownership as a defect that must be resolved before migration.
Choose authentication by workload—not convenience
The global PAT retirement is a reason to remove long-lived user secrets where the platform supports a better identity model.
Managed identity
Best for automation hosted in Azure. Azure manages the identity credentials, so the workload does not store a client secret.
Service principal
Use for unattended automation outside Azure or across environments. Prefer workload identity federation or certificates over client secrets.
Azure DevOps service connection
Use when an Azure Pipeline needs Azure DevOps repos, feeds or APIs across organisations without keeping a PAT in variables.
Organisation-scoped PAT
Keep as a narrow compatibility option for short-lived personal, legacy or vendor scenarios that cannot yet use Microsoft Entra authentication.
A migration sequence that reduces outage risk
- Classify the workload. Separate interactive user tools, personal scripts, Azure-hosted automation, external services and Azure Pipelines. The right replacement differs for each.
- Confirm organisation boundaries. List every organisation and resource the workload genuinely needs. A former global PAT may need separate organisation-scoped credentials or an application identity explicitly added and permitted in each organisation.
- Prefer an application identity for unattended work. Microsoft recommends a managed identity for Azure-hosted workloads and a service principal for portable or non-Azure automation. For service principals, favour federation or a certificate where supported.
- Check product compatibility. Some legacy and third-party tools may only accept PATs or may assume a cross-organisation profile endpoint. Confirm current vendor support before issuing a new credential.
- Build a parallel test. Give the replacement only the access it needs, exercise read and write paths, run scheduled and failure scenarios, and check each target organisation.
- Cut over with evidence. Update the approved secret or identity reference, monitor authentication and authorisation errors, then revoke the global PAT after every consumer is verified.
Do not treat successful sign-in as sufficient testing. Authentication proves who the caller is; Azure DevOps permissions decide what it can do. A managed identity or service principal must be explicitly added to the relevant Azure DevOps organisation and granted the required access level, project membership and resource permissions.
Does the global PAT retirement affect SSH keys?
No direct SSH retirement is stated in Angel Wong's announcement. SSH keys and PATs are different credential types. A PAT is a bearer token commonly used with HTTPS, REST APIs and supported integrations. SSH authentication uses a public-private key pair for Git access: Azure DevOps stores the public key while the private key stays with the user or controlled client.
An Azure Repos remote already using an SSH URL does not authenticate with a global PAT, so the 1 December global PAT shutdown does not by itself require that remote to change credentials. However, SSH is not a universal PAT replacement. It is designed for Git transport and does not replace authentication for REST API calls, Boards automation, package workflows or every third-party connector.
There is no special Azure DevOps credential called an “SSH key token”. Teams should inventory SSH keys separately. Azure DevOps currently documents RSA keys for Azure Repos, recommends the ssh.dev.azure.com URL format and allows organisation administrators to disable SSH authentication. Its Validate SSH key expiration policy is enabled by default; when active, expired keys become invalid, with notifications sent seven days before expiry and after expiry.
That means an SSH-based Git workflow may be unaffected by the PAT deadline but still fail for a different reason: an expired key, a disabled SSH policy, missing repository permission or an inactive identity session. Keep the two migration tracks separate in the register and in testing.
PAT, SSH key or Microsoft Entra identity?
| Credential | Best fit | What to check now |
|---|---|---|
| Global Azure DevOps PAT | No future fit in Azure DevOps Services | Replace before 1 December 2026; do not merely extend its expiry. |
| Organisation-scoped PAT | Temporary, personal or legacy compatibility | Use minimum scopes, short lifetime, protected storage and tested rotation. |
| SSH key | Git clone, fetch and push over SSH | Check key expiry, organisation SSH policy, repository permission and remote URL. |
| Managed identity | Azure-hosted unattended automation | Add the identity to each Azure DevOps organisation and grant least privilege. |
| Service principal | Portable or non-Azure automation | Prefer federation or certificates; manage permissions and lifecycle independently of staff accounts. |
| Azure DevOps service connection | Azure Pipelines calling Azure DevOps resources | Use Microsoft Entra workload identity federation and authorise only the pipelines that need it. |
What to complete before 1 December
- Export a register of active global PAT metadata without exposing secret values.
- Assign a business and technical owner to every consuming workload.
- Choose the modern authentication method supported by each scenario.
- Confirm third-party product support and any organisation-specific endpoint requirements.
- Test least-privilege permissions across every required organisation.
- Update runbooks, monitoring, expiry alerts and offboarding procedures.
- Revoke the old PAT after observed production success—well before the deadline.
Sources Checked
- Microsoft Azure DevOps Blog: Retirement of Global Personal Access Tokens in Azure DevOps
- Microsoft Learn: Azure DevOps Sprint 270 Update
- Microsoft Learn: Authentication methods for Azure DevOps integrations
- Microsoft Learn: Use service principals and managed identities in Azure DevOps
- Microsoft Azure DevOps Blog: Use the Azure DevOps service connection instead of a PAT
- Microsoft Learn: Use SSH key authentication
- Microsoft Learn: Change application connection and security policies
- Microsoft Learn: Use personal access tokens