Azure DevOps Global PAT Retirement: Migrate Before Dec 1

On December 1, 2026, every global personal access token in Azure DevOps Services stops working. Not "gets a warning banner". Stops. Any script, pipeline, scanner or publishing job that still authenticates with one will start returning 401s on a Tuesday morning, and the person who created that token may have left the company two years ago.

I build and publish Azure DevOps extensions for a living, so this retirement lands on my own release pipeline too. That is why I wanted a guide that goes further than "check your token list". Microsoft's announcement gives you the dates and one filter in the UI. It doesn't tell you where global PATs actually hide, or which replacement fits which job.

This post does. You'll get a way to find every global PAT you depend on, a decision guide for replacing each one, the Marketplace publishing trap most guides skip, and a 9-week plan you can track to done.

What actually changes on December 1, 2026

A global PAT is a personal access token created with the scope "All accessible organizations". It authenticates against every Azure DevOps organization its owner can reach. That convenience is exactly the problem: one leaked token opens everything.

Microsoft announced the retirement in December 2025 on the Azure DevOps blog post on the retirement of global personal access tokens. The timeline shifted once, which is why so many teams parked it:

• March 15, 2026 was the original date to block creating new global PATs. Microsoft dropped that step, so you can still create them today.
• December 1, 2026 is unchanged: all existing global PATs are decommissioned and stop working.

A few things are worth being precise about:

• Azure DevOps Services only. Global PATs in self-hosted Azure DevOps Server are not affected.
• Organization-scoped PATs keep working. A PAT tied to one named organization is not part of this retirement.
• Being able to create one now means nothing. A global PAT you create in November still dies on December 1.

If you already did an audit like the one in my post on finding every Node 16 task before the Azure Pipelines deadline, the rhythm is the same: inventory, replace, test, remove. The difference is that authentication failures are less forgiving than a deprecated task warning.

Step 1: Find every global PAT you depend on

There are two questions here, and people usually only answer the first one.

Which global PATs do I own?

Every user can check their own tokens in a minute:

1. Sign in to https://dev.azure.com/{your-organization}.
2. Open User settings in the top right and choose Personal access tokens.
3. Set the Access scope filter to All accessible organizations and the status to Active.

Whatever shows up is on the December 1 list. Microsoft also emails owners of active global PATs during the deprecation, so ask your team whether anyone received one and ignored it.

Which global PATs does my organization depend on?

This is the harder question, because the token that matters is often owned by someone else: a service account, a contractor, or a former colleague whose account still exists for exactly this reason.

• Ask the owners of service accounts to run the check above. Service accounts are where the long-lived, broad tokens tend to live.
• Check your tenant policy. Organization admins with Microsoft Entra ID can restrict creation of global PATs at tenant level. Turning that on now stops new ones from appearing while you clean up the old ones.
• Search your secret stores, not just Azure DevOps. Look in variable groups, Azure Key Vault, GitHub secrets, CI systems outside Azure DevOps, and password managers for entries named like "ado-pat", "vsts-token" or "azure-devops-all-orgs".

The official Microsoft Learn guide to using personal access tokens now carries the retirement warning at the top and covers the admin policies for restricting PAT creation, scopes and lifetimes.

Step 2: Know where global PATs hide

In my experience, the token list is not where the risk is. The risk is in whatever consumes the token. These are the five places I would check first.

Cross-organization scripts and tools

The one legitimate reason to create a global PAT was reaching more than one organization with a single credential. Think of reporting scripts that aggregate work items from several organizations, sync jobs that copy work items or repos between organizations, and admin scripts that manage users or licenses across the estate. These break first and hardest, because by design they have no single-organization alternative.

Pipelines calling the Azure DevOps REST API

Many older pipelines store a PAT in a secret variable to call the REST API: tagging releases, updating work items, triggering builds in another project. If someone created that PAT with the global scope out of habit, the pipeline fails on December 1 even though it only ever talks to one organization.

Third-party integrations and scanners

Security scanners, test management tools and reporting SaaS products often ask for a PAT during setup. Vendors such as Snyk and Mend have already published migration notes asking customers to swap in organization-scoped tokens. Check every integration that asked you to paste a token, not just the ones you remember.

Local developer tooling

Git credential helpers, CLI profiles, MCP server configurations for AI assistants and IDE plugins frequently hold a PAT on a developer's machine. These fail quietly and one person at a time, so the symptom is a trickle of "my tool stopped working" messages in early December.

Extension publishing pipelines

This is the one that affects people like me directly. More on it below, because it deserves its own section.

Step 3: Pick the right replacement for each use

Not every global PAT needs the same fix. Here is how I decide.

Option A: an organization-scoped PAT (the quick swap)

Create a new PAT scoped to one named organization with only the scopes the job needs. For a tool that talks to three organizations, that means three tokens.

• Use it when: a third-party tool only accepts a PAT, or you need a fix this week.
• Watch out for: you now have more tokens to rotate. For organizations backed by Microsoft Entra ID, the owner also has to sign in within 90 days of creating the PAT or it becomes inactive, which catches out service accounts nobody logs in with.

Option B: the Azure DevOps service connection (the proper fix for pipelines)

In August 2026 Microsoft introduced the Azure DevOps service connection, which lets a pipeline authenticate to Azure DevOps as a Microsoft Entra workload identity (a service principal or managed identity) instead of a PAT. The announcement of the Azure DevOps service connection lists what you get:

• No secret to store or rotate. It uses federated credentials.
• Per-pipeline or even per-task permissions instead of the shared build service account.
• Every authentication attempt in the audit log.
• Cross-organization access to other organizations joined to the same Entra tenant, which covers many former global PAT use cases.

One prerequisite trips people up: creating the service connection does not create the identity. Create the service principal or managed identity in Entra first, add it as a user in your Azure DevOps organization with the right access, and only then create the connection.

Option C: Microsoft Entra tokens for scripts and services

For scripts and services outside pipelines, request a short-lived Microsoft Entra access token for the Azure DevOps resource (for example via the Azure CLI or an app registration) and send it as a bearer token. It's more setup than a PAT, but there is nothing long-lived to leak.

A quick decision rule

• Pipeline talking to Azure DevOps: service connection.
• Script or service you control: Entra token, falling back to an org-scoped PAT if needed.
• Third-party tool that only accepts PATs: org-scoped PAT per organization, with an expiry you actually track.
• A developer's own machine: org-scoped PAT or Entra-based sign-in, with a short lifetime.

The Marketplace publishing trap

If you build Azure DevOps or Visual Studio extensions, read this twice. For years, publishing an extension with tfx-cli required a global PAT with the Marketplace (publish) scope, because the Marketplace does not live inside any one organization. Microsoft even published a known-issue post back in 2021 about publishers who were blocked when admins restricted global PAT creation. So in many publishing pipelines, the one global PAT nobody dared touch sits right next to your release step.

The good news: there is now a supported path without it. The Microsoft Learn guide to publishing extensions from the command line recommends a Microsoft Entra token:

1. Create or reuse a service principal in Entra.
2. Look up its Azure DevOps profile ID by signing in as that principal with the Azure CLI and calling the profile API with the Azure DevOps resource ID.
3. Add the service principal as a member of your Marketplace publisher.
4. Publish with the Entra token instead of a PAT: tfx extension publish --publisher <publisher> --vsix <file>.vsix --auth-type pat -t <ENTRA_TOKEN>.

The --auth-type pat flag looks odd, but the token you pass is the Entra access token. For VS Code extensions, vsce publish --azure-credential inside an AzureCLI@2 task with a workload identity federation service connection does the same job.

My advice: migrate the publishing pipeline first, not last. It is the job most likely to be owned by one person, it runs rarely, and a failed release is the worst moment to find out your token is gone.

A 9-week plan you can actually prove

"We migrated our PATs" is not verifiable. A list of credentials, each with an owner and a done state, is. Here is the plan I would run from now until December 1:

• Weeks 1 to 2: inventory. One work item per credential or consuming system: owner, which organizations it reaches, what uses it, and the chosen replacement (A, B or C).
• Weeks 3 to 5: replace. Start with extension publishing and cross-organization scripts, then pipelines, then third-party tools.
• Weeks 6 to 7: test and revoke. Run each job with the new credential, then revoke the old global PAT yourself. Revoking early turns December 1 into a non-event, because you'll find out what breaks while you still have time.
• Weeks 8 to 9: sweep. Rerun the owner checks from Step 1, turn on the tenant policy restricting global PAT creation if you haven't already, and chase anything left.

The key is making "done" mean done for each item. I built the Checklist Extension for Azure DevOps for exactly this pattern: add a reusable checklist template to every migration work item (new credential created, job tested, old PAT revoked, secret store cleaned up) and block the work item from closing until every step is ticked. It's the same approach I describe in making "Done" mean done in Azure DevOps Boards, applied to a security deadline instead of a user story.

Conclusion

The global PAT retirement is easy to underestimate because the fix for any single token is small. The risk sits in the tokens you don't know about: the cross-organization script, the scanner someone configured years ago, the publishing pipeline that only runs at release time.

Key takeaways:

• December 1, 2026 is final for global PATs in Azure DevOps Services. Creation still works, which makes it worse, not better.
• Look beyond the token list to scripts, pipelines, integrations, developer machines and publishing jobs.
• Match the replacement to the job: service connection for pipelines, Entra tokens for your own scripts, org-scoped PATs only where a tool leaves you no choice.
• Migrate extension publishing first, using a service principal added to your Marketplace publisher.
• Revoke early so you control when things break.

If you want every credential tracked to a verifiable done state instead of a spreadsheet nobody updates, install the Checklist Extension from the Visual Studio Marketplace. It's free, and the migration template takes five minutes to set up. And if one of your in-house extensions or integrations is built around a global PAT and needs rework, that's the kind of custom Azure DevOps extension work I do.

Frequently asked questions