About security and identity

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


Azure DevOps no longer supports Alternate Credentials authentication since the beginning of March 2, 2020. If you're still using Alternate Credentials, then they won't work anymore. You have to switch to a more secure authentication method, to mitigate this breaking change impacting your DevOps workflows. Learn more.

For anyone to access a project, you must add them to a security group. For a quick look at what permissions are assigned to the default security groups, see Default permissions and access assignments.

Azure DevOps Services, our cloud-hosted application, is based on the capabilities of Azure DevOps Server 2019 (formerly known as Team Foundation Server), with additional cloud services. Both 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.

This article introduces the main security concepts employed by Azure DevOps. To learn more about the steps Microsoft takes to keep your projects in Azure DevOps safe, available, secure, and private, see this white paper, Azure DevOps Services Data Protection Overview.

The main security concepts to understand are

  • Authentication
  • Authorization
  • Security groups
  • Security roles
  • Permission levels and permissions
  • Access levels


Authentication verifies a user's 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 is based on users and groups, and the permissions assigned directly to both those users and groups and permissions those users and groups might inherit by belonging to one or more Azure DevOps security groups. These users and groups can be Azure AD or AD users and groups. For on-premises deployments, they can also be local Windows users and groups.

Also, for select features, users and groups may need to belong to an access level that grants them access to a feature.

Security groups and permissions

Azure DevOps is pre-configured with default security groups. Default permissions are assigned to the default security groups.

Security area Groups, levels, and states
Security groups
  • Project-level
  • Organization or collection level
  • Server-level (Azure DevOps Server and TFS only)
Permission levels
  • Object-level
  • Project-level
  • Organization or collection level
  • Server-level (Azure DevOps Server and TFS only)
Permission states

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

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

Conceptual image of permissions and access levels

Azure DevOps controls access through these three inter-connected functional areas:

  • Membership management supports adding individual Windows user accounts and groups to default security groups. Also, you can create Azure DevOps security groups. Each default group is associated with a set of default permissions. All users added to any security group are added to the Valid Users group. A valid user is someone who can connect to the project.

  • Permission management controls access to specific functional tasks at different levels of the system. Object-level permissions set permissions on a file, folder, build pipeline, or a shared query. Permission settings correspond to Allow, Deny, Inherited allow, Inherited deny, and Not set. To learn more about inheritance, see About permissions and groups.

  • Access level management controls access to features provided via the web portal, the web application for Azure DevOps. Based on what has been purchased for a user, administrators set the user's access level to Basic, VS Enterprise (previously Advanced), or Stakeholder.

Each functional area uses groups to simplify management across the deployment. You add users and groups through the web administration context. Permissions are automatically set based on the security group that you add users to, or based on the object, project, collection, or server level to which you add groups. On the other hand, access level management controls access for all users and groups at the server level.

Access levels, membership management, and permissions management

You can create local groups or Active Directory (AD) groups to manage your users. If you decide to use groups, make sure that membership in those groups is limited to valid users. Because group membership can be altered by their owners at any time, if those owners did not consider Azure DevOps Server access when they created those groups, their changes to membership can cause unwanted side effects within the server.

Default permissions set for the Contributors group

The following image shows the default permission assignments made to the Contributors group.

Contributor role default permissions

To learn more about other groups and their permission assignments, see Permissions and groups reference.

Security roles

There are a number of artifacts whose permissions are managed by role. These include the following artifacts and features.

Security level Functional area
  • Deployment groups
  • Secure files
  • Variable groups
  • Agent queues
  • Service connections
  • Team administration
  • 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 for those features. Access to those features is not controlled by permissions but by membership in an access level. To learn more, see Access levels.