About security, membership, and permissions

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

Azure DevOps employs a number of security concepts to ensure only those who should have access to features, functions, and data have access. Accounts get access to Azure DevOps through authentication of their security credentials and authorization of their account entitlements to access a feature or function. The following table summarizes the various account types supported and the methods used to manage authentication and authorization.

Accounts Authentication Authorization
• Users
• Organization owner
• Service accounts
• Service principals
• Job agents
• User credentials
• Windows authentication
• Two-factor authentication (2FA)
• SSH key authentication
• Personal access tokens
• Oauth
• Active Directory authentication library
• Security group membership
• Role-based access control
• Access levels
• Feature flags
• Security namespaces & permissions


Azure DevOps no longer supports Alternate Credentials authentication since the beginning of March 2, 2020. If you're still using Alternate Credentials, we strongly encourage you to switch to a more secure authentication method (for example, personal access tokens). Learn more.

Both our cloud service, Azure DevOps Services, and on-premises server, Azure DevOps Server, support software development projects, from planning through deployment. Azure DevOps uses Microsoft Azure's Platform as a Service infrastructure and many of Azure's services, including Azure SQL databases, to deliver a reliable, globally available service for your development projects.

To learn more about the steps Microsoft takes to keep your projects in Azure DevOps Services safe, available, secure, and private, see this white paper, Azure DevOps Services Data Protection Overview.


While the main types of accounts of interest are the user accounts that you add to your organization or project, Azure DevOps supports other types of accounts to perform various operations. These include the following account types:

  • Organization owner: The creator of an Azure DevOps Services organization or assigned owner.
  • Service accounts: Internal Azure DevOps accounts used to support a specific service, such as Agent Pool Service, PipelinesSDK.
  • Service principals: Internal Azure DevOps accounts to to support internal operations.
  • Job agents: Internal accounts used to run specific jobs on a regular schedule.
  • Third party accounts: Accounts that require access to support Web hooks, service connections, or other third-party applications.

The most effective means for managing accounts is by adding them to security groups.


The organization owner and members of the Project Collection Administrators group are granted full access to most all features and functions.

To learn more

See one of the following articles:


Authentication verifies an account identity based on the credentials provided when they sign into Azure DevOps. These systems integrate with and rely upon the security features provided by these additional systems:

  • Azure Active Directory (Azure AD)
  • Microsoft account (MSA)
  • Active Directory (AD)

Azure AD and MSA support cloud authentication. We recommend Azure AD when you need to manage a large group of users. Otherwise, if you have a small user base accessing your organization in Azure DevOps, you can simply use Microsoft accounts. For additional information, see About accessing Azure DevOps with Azure Active Directory (Azure AD).

For on-premises deployments, AD is recommended when managing a large group of users. For additional information, see Set up groups for use in on-premises deployments.

Authentication methods, integrating with other services and apps

Other applications and services can integrate with services and resources in Azure DevOps. To access your account without asking for user credentials multiple times, apps can use the following authentication methods.

By default, your account or collection allows access for all authentication methods. You can limit access, but you must specifically restrict access for each method. When you deny access to an authentication method, no app can use that method to access your account. Any app that previously had access gets an authentication error and can't access your account.

To learn more about how we store your credentials, see Credential storage for Azure DevOps.

To learn more about how to choose the right authentication mechanism, see Guidance for authentication.


Authorization verifies that the identity which is attempting to connect has the necessary permissions to access a service, feature, function, object, or method. Authorization always occurs after successful authentication. If a connection is not authenticated, it fails before any authorization checking is performed. If authentication of a connection succeeds, a specific action might still be disallowed because the user or group did not have authorization to perform that action.

Authorization depends on the permissions assigned to the account. Permissions are granted either directly to an account, or through membership in a security group or security role. Access levels and feature flags can also grant or restrict access to a feature.

Security group membership

With the creation of an organization, collection, or project—Azure DevOps creates a set of default security groups which are automatically assigned default permissions. Additional security groups are defined with the following actions:

  • When you add a custom security group. You can create custom security groups at the following levels:
    • Project-level
    • Organization- or collection-level
    • Server-level (on-premises only)
  • When you add a team, a team security group is created

Security group members can be a combination of users, other groups, and Azure Active Directory groups.

Security group members can be a combination of users, other groups, and Active Directory groups or a Workgroup.

Most users are assigned to the Contributors group for a project to provide them access to the features they need to access. Administrators should be added to the Project Collection Administrators or Project Administrators group.


Accounts that are assigned to more than one security group are restricted to those permissions granting the least access. For example, if you add a user to the Readers group and the Project Administrators group, the effective permissions of the Readers group are enforced for the user.

Populate security groups

You can populate these groups by adding individual users. However, for ease of management, it's easier if you populate these groups by using Azure Active Directory (Azure AD), Active Directory (AD), or Windows security groups. This method enables you to manage group membership and permissions more efficiently across multiple computers.

Conceptual image showing adding Azure Active Directory groups to Azure DevOps security groups, cloud

Conceptual image showing adding Active Directory groups to Azure DevOps security groups , on-premises

Conceptual image showing defining AD groups

Of course, you don't need to grant permissions for reports or the project portal if your project doesn't use SQL Server Reporting Services or a SharePoint site.

Permission levels

As shown in the following image, security groups defined at the project and collection-level can be assigned to permissions assigned at the object, project, and collection level.

Conceptual image mapping default security groups to permission levels, cloud

As shown in the following image, security groups defined at the project and collection-level can be assigned to permissions assigned at the object, project, and collection level. You can only define server-level security groups to server-level permissions.

Conceptual image mapping default security groups to permission levels, on-premises

Conceptual image of security groups and permission levels, TFS-2018 and earlier versions

For a description of each default security group, see Security groups, service accounts, and permissions.

Valid user groups

When you add accounts of users directly to a security group, they are automatically added to one of the valid user groups.

  • OrganizationName\Project Collection Valid Users: All members added to organization-level groups.
  • ProjectName\Project Valid Users: All members added to project-level groups.
  • Server\Azure DevOps Valid Users: All members added to server-level groups.
  • ProjectCollectionName\Project Collection Valid Users: All members added to collection-level groups.
  • ProjectName\Project Valid Users: All members added to project-level groups.
  • Server\Team Foundation Valid Users: All members added to server-level groups.
  • ProjectCollectionName\Project Collection Valid Users: All members added to collection-level groups.
  • TeamProjectName\Project Valid Users: All members added to project-level groups.

The default permissions assigned to these groups are primarily limited to read access, such as View build resources, View project-level information, and View collection-level information.

This means that all users that you add to one project can view the objects in other projects within a collection. If you need to restrict view access, then you can set restrictions through the area path node.

If you remove or deny the View instance-level information permission for one of the valid users groups, no members of the group are able to access the project, collection, or deployment, depending on the group you set.

Role-based access control

With Role-based access control, accounts are assigned to a role, with each role assigned one or more permissions. The following table lists the artifacts whose permissions are managed by role.

Object-level Project-level Collection-level
•  Secure files
•  Variable groups
•  Agent pools
•  Agent queues
•  Service connections
•  Team administrator
• Agent pools
•  Deployment pools
•  Marketplace extensions

To learn more, see About security roles.

Access levels

Certain features are only available to users who have the appropriate licensing level. Administrators control access by assigning users or security groups to an access level. Access levels control what features are visible to users in the web portal, and are dependent on user licenses; permissions control a user's ability to use features across Azure DevOps.

If you're just trying to give someone access to Agile portfolio management and test case management features, you'll want to change access levels, not permissions. To learn more, see Access levels.

Feature flags

Access to select, new features are controlled by feature flags. Periodically, Azure DevOps Services introduces new features by placing them behind a feature flag. Features under a private preview require the organization owner to request that the feature be turned on. Other features may be introduced as a preview feature which general users can enable or disable. To learn more, see Manage or enable features.

Security namespaces and permissions

Security namespaces store data that determines the level of access that Azure DevOps accounts have to perform a specific action on a specific resource. Each family of resources, such as work items or Git repositories, is secured through a unique namespace. Each security namespace contains zero or more access control lists (ACLs). Each ACL contains a token, an inherit flag, and a set of zero or more access control entries (ACEs). Each ACE contains an identity descriptor, an allowed permissions bitmask, and a denied permissions bitmask.

To learn more, see Security namespaces and permission reference.

Permission levels

Permissions are assigned at various levels based on the structure of the Azure DevOps instance. To learn more, see About permissions and inheritance.

  • Object-level
  • Project-level
  • Organization-level
  • Object-level
  • Project-level
  • Collection-level
  • Server-level

Permission states

There are five possible assignments made to a permission. They grant or restrict access as indicated.

  • User or group has permissions to perform a task:
    • Allow
    • Inherited allow
  • User or group doesn't have permission to perform a task:
    • Deny
    • Inherited deny
    • Not set

Azure Repos and Azure Pipelines security

Since repositories and build and release pipelines pose unique security challenges, additional features beyond those discussed in this article are employed. To learn more, see the following:

Try this next