As organizations continue to strengthen their security posture, restricting usage of personal access tokens (PATs) has become a critical area of focus. With the latest public preview of the Restrict personal access token creation policy in Azure DevOps, Project Collection Administrators (PCAs) now have another powerful tool to reduce unnecessary PAT usage and enforce tighter controls across their organizations.
🗣️ This has been one of our most requested features — we’re excited to finally deliver it.
Why This Matters
PATs are a convenient way for users to authenticate with Azure DevOps, but they also pose a risk if not properly managed. Long-lived or overly permissive tokens can become a vector for unauthorized access. We have tenant-level policies that help target these risk vectors by limiting full-scope and global PATs or reducing a PAT’s maximum lifespan.
This new organization-level policy mitigates that risk further by giving administrators the ability to control who can create or regenerate PATs.
What’s New
Once enabled, the Restrict personal access token creation policy prevents users from creating or regenerating PATs unless they are explicitly allowed. Here’s what you need to know:
- Default Behavior:
For new organizations, the policy is enabled by default.(Update 06/27: This requirement has been relaxed as part of public preview. We will revisit this potentially as part of General Availability (GA).) For existing organizations, it remains off until manually turned on. - Existing PATs: Tokens already in use will continue to function until they expire.
- Global PAT Usage: Global PATs cannot be used in an organization unless the user is added to an allowlist.
💡 Tip: Combine this policy with the “Set maximum lifespan for new PATs” setting to further reduce token sprawl and enforce short-lived credentials.
How to Enable the Policy
-
Sign in to your organization at https://dev.azure.com/{yourorganization}.
-
Navigate to Organization settings via the gear icon.
-
Select Policies, then locate Restrict personal access token creation.
-
Toggle the policy on and configure the sub-policies as needed.
Managing Exceptions
Need to make exceptions? You can add specific Microsoft Entra users or groups to an allowlist:
-
Click Manage next to “Allow list” under the “Allow creation of PAT of any scope for selected users and groups” subpolicy.
-
Search for and select Microsoft Entra users or groups.
-
Check the box for the subpolicy.
Once configured, these users will retain the ability to create PATs of any scope, even with the policy enabled.
💡 Tip: Use an Identity & Access Management (IAM) platform like Microsoft Entra ID Identity Governance to manage inbound access requests and send access reviews when an existing user’s access to the allowlist is due to expire.
Supporting Packaging Scenarios
Some packaging workflows still rely on PATs. To support these cases without compromising broader security goals, you can enable the “Allow creation of PAT with packaging scope only” option. This limits token creation to packaging scopes for users not on the allowlist.
Final Thoughts
This policy is a significant step forward in reducing PAT usage and aligning Azure DevOps with modern identity and access management practices. By enabling it, organizations can better protect their environments while still supporting essential workflows.
💬 We’d love to hear from you—has this policy helped your team reduce PAT usage? Are there additional controls you’d like to see? Let us know in the comments below!
Hello Angel,
This is a very nice feature as it gives a lot of options to admins in order to restrict access based on users. My question is how do we recognise the users that have PAT in order to inform them and prepare a plan. As PAT is personal and there is no API command to list users that have PAT enabled it is little bit hard to organise and inform users for the new "restrictions". One quick workaround is to check audit logs and see the column "AuthenticationMechanism" to see if there is any "PAT authorizationId". But...
Hello Dimitrios,
you have a point here! We also have > 1000 users in our organization and we really like to enforce PAT restrictions. For business continuity reasons we like to inform the relevant persons prior to enforcing new policies.
For starters we like to inform the ones having global or full scoped PATs about the upcoming restrictions. Sending informational mails to 1000+ individuals will most likely end up in a communication disaster. That is the primary reason why we did not activate PAT restrictions yet.
Having some option to see a list of PATs, users having PATs (all, full scoped, global) or...
this comment has been deleted.
Hi,
This feature sounds good!
But how should users clone a git repo from the UI of Azure DevOps work with this feature enabled?
Right now they get errors because of a
DisablePatCreationPolicyValidation.Hi Christian, there’s a number of ways you can git (clone and other operations) without PATs!
Here’s a helpful link to some options: https://learn.microsoft.com/en-us/azure/devops/repos/git/auth-overview
Hi Angel,
Thanks for the detailled information. Looks like something has been broken under the sheet. I am one of the customer who is heavily using PAT tokens for our self hosted pipelines. from last week, our pipelines are breaking as it no longer can view PAT or create new PAT as part of our regular recycle schedule. Many users are reporting the same in the forum here: https://developercommunity.visualstudio.com/t/Problem-DeployingEditing-Release-pipeli/10918913?sort=active
Hi Karthik, this one seems unrelated (and potentially closed by now). Do continue posting in Developer Community if you’re still experiencing issues.
Hi Angel, thanks for sharing the preview's availability.
When I first heard this was coming, my hope was it would achieve parity with (feature-wise) or exceed what's possible with the tenant-level PAT control policies.
Inside an enterprise, some organizations may wish to restrict PAT more than is possible on a tenant-wide basis.
Specifically the ability to control max-life for a PAT, and for ability to limit app_token scope on tokens, and to allow exceptions from those policies on a managed-list basis I think would be appreciated by many.
And some new PAT alternatives may not have existed at the time the tenant level...
Hi Matt! Thanks for your feedback.
It seems that some of your PAT policy requests are already covered in the existing tenant-level policies (max-lifetime duration, exception management through allowlists). We may someday choose to bring some of these tenant-level policies down to the org-level, but this is likely not coming anytime soon.
The ability to limit token creation by scope is certainly an interesting and popular request that we may eventually explore in the future.
In the meantime, our main goal remains how to engage more users to get comfortable with Entra-first auth instead of furthering PAT reliance. As you also alluded to,...
I don't think it's possible to assume that every Azure DevOps org in a tenant will align on some of the policy choices. By having some of the choices only available at the tenant level, it weakens security to the lowest common denominator...
Personally I would like to enforce a whitelist for using unrestricted scopes as an easy first start. I don't know that being able to individually restrict specific scopes is that fruitful... would say perhaps more choice between a few options like Unrestricted/Packages scope except whitelisted/Whitlisted only ... or something like that..
But also would like to...