Skip to content

about-security-identity.md

Latest commit

 

History

History
282 lines (211 loc) · 14.4 KB

about-security-identity.md

File metadata and controls

282 lines (211 loc) · 14.4 KB
title About authentication, authorization, and security policies
titleSuffix Azure DevOps
description Understand how Azure DevOps manages security through authentication, authorization, and policies.
ms.subservice azure-devops-security
ms.author chcomley
author chcomley
ai-usage ai-assisted
ms.topic overview
monikerRange <= azure-devops
ms.date 02/24/2026
ms.custom pat-reduction

About authentication, authorization, and security policies

[!INCLUDE version-lt-eq-azure-devops]

Azure DevOps uses a combination of security concepts to ensure that only authorized users can access its features, functions, and data. Access is determined by two key processes: authentication, which verifies a user's credentials, and authorization, which grants permissions based on account entitlements. Together, these processes control what each user can do within Azure DevOps.

This article expands on Get started with permissions, access, and security groups. It helps administrators understand the different account types, authentication and authorization methods, and security policies available to protect Azure DevOps environments.

::: moniker range="azure-devops"

:::row::: :::column span="1"::: Account types - Users - Organization owner - Service accounts - Service principals or managed identities - Job agents

  **Authentication**
  - User credentials
  - Windows authentication
  - Two-factor authentication (2FA)
  - SSH key authentication
  - Microsoft Entra token
  - Personal access tokens
  - OAuth configuration
  - Active Directory authentication library

:::column-end::: :::column span="1"::: Authorization - Security group membership - Role-based access control - Access levels - Feature flags - Security namespaces and permissions

  **Policies**
  - Privacy policy URL
  - Application connection and security policies
  - User policies
  - Git repository and branch policies

:::column-end::: :::row-end:::

::: moniker-end

::: moniker range="< azure-devops"

:::row::: :::column span="1"::: Account types - Users - Service accounts - Service principals or managed identities - Job agents

  **Authentication**
  - User credentials
  - Windows authentication
  - Two-factor authentication (2FA)
  - SSH key authentication
  - Personal access tokens
  - OAuth configuration
  - Active Directory authentication library

:::column-end::: :::column span="1"::: Authorization - Security group membership - Role-based permissions - Access levels - Feature flags - Security namespaces and permissions

  **Policies**
  - Git repository and branch policies

:::column-end::: :::row-end:::

::: moniker-end

[!INCLUDE alt-creds-deprecation-notice]

Azure DevOps supports software development from planning to deployment. It uses Microsoft Azure's platform as a service (PaaS) infrastructure and services, including Azure SQL databases, to provide a reliable, globally available service for your projects.

::: moniker range="azure-devops" For more information about how Microsoft ensures your projects are safe, available, secure, and private, see the Azure DevOps data protection overview. ::: moniker-end

Accounts

While human user accounts are the primary focus, Azure DevOps also supports various other account types for different operations:

::: moniker range="azure-devops"

  • Organization owner: The creator of an Azure DevOps Services organization or assigned owner. To find the owner for your organization, see Look up the organization owner.
  • Service accounts: Internal Azure DevOps accounts used to support a specific service, such as Agent Pool Service, PipelinesSDK. For descriptions of service accounts, see Security groups, service accounts, and permissions.
  • Service principals or managed identities: Microsoft Entra applications or managed identities added to your organization to perform actions on behalf of a non-Microsoft application. Some service principals refer to internal Azure DevOps organization to support internal operations.
  • Job agents: Internal accounts used to run specific jobs on a regular schedule.
  • Non-Microsoft accounts: Accounts that require access to support webhooks, service connections, or non-Microsoft applications.

Throughout the security-related articles, "users" refers to all identities added to the Users Hub, which can include human users and service principals.

::: moniker-end

::: moniker range="< azure-devops"

  • Service accounts: Internal Azure DevOps accounts used to support a specific service, such as Agent Pool Service, PipelinesSDK. For descriptions of service accounts, see Security groups, service accounts, and permissions.
  • Service principals or managed identities: Microsoft Entra applications or managed identities added to your organization to perform actions on behalf of a non-Microsoft application. Some service principals refer to internal Azure DevOps organization to support internal operations.
  • Job agents: Internal accounts used to run specific jobs on a regular schedule.
  • Non-Microsoft accounts: Accounts that require access to support webhooks, service connections, or non-Microsoft applications.

::: moniker-end

The most effective way to manage accounts is by adding them to security groups.

Note

The organization owner and members of the Project Collection Administrators group have full access to nearly all features and functions.

Authentication

Authentication verifies a user's identity based on the credentials they provide during sign-in to Azure DevOps. Azure DevOps integrates with several identity systems to manage authentication:

  • Microsoft Entra ID: Recommended for organizations managing a large group of users. Provides robust, cloud-based authentication and user management.
  • Microsoft account (MSA): Suitable for smaller user bases accessing Azure DevOps organizations. Supports cloud authentication.
  • Active Directory (AD): Recommended for on-premises deployments with many users, using your existing AD infrastructure.

Microsoft Entra ID and Microsoft accounts both support cloud authentication. For more information, see About accessing Azure DevOps with Microsoft Entra ID.

For on-premises environments, use Active Directory to efficiently manage user access. For more information, see Set up groups for use in on-premises deployments.

Authenticate programmatically

Access your Azure DevOps organization programmatically without repeatedly entering your username and password by choosing one of the available authentication methods. Use the following methods to automate workflows, integrate with REST APIs, or build custom applications:

Tip

Always store credentials securely and follow best practices for managing authentication methods.

By default, your organization allows access for all authentication methods. Organization admins can restrict access to these authentication methods by disabling security policies. Tenant admins can further reduce PAT risk by restricting the ways in which they can be created.

Authorization

Authorization determines whether an authenticated identity has the required permissions to access a specific service, feature, function, object, or method in Azure DevOps. Authorization checks always occur after successful authentication—if authentication fails, authorization is never evaluated. Even after authentication, users or groups might be denied access to certain actions if they lack the necessary permissions.

Azure DevOps manages authorization through permissions assigned directly to users or inherited through security groups or roles. Access levels and feature flags can further control access to specific features. For more information, see Get started with permissions, access, and security groups.

Security namespaces and permissions

Security namespaces define user access levels for specific actions on Azure DevOps resources.

  • Each resource family, for example, work items or Git repositories, has its own unique namespace.
  • Within each namespace, there can be multiple access control lists (ACLs).
    • Each ACL contains a token, an inherit flag, and one or more access control entries (ACEs).
    • Each ACE specifies an identity descriptor, a bitmask for allowed permissions, and a bitmask for denied permissions.

For more information, see Security namespaces and permission reference.

Security policies

::: moniker range="azure-devops"

To secure your organization and code, organization-level (Project Collection Administrator) or tenant-level (Azure DevOps Administrator) admins can enable or disable various security policies, depending on the policy scope. Key policies to consider include:

If your organization is connected to Microsoft Entra ID, you have access to the following other security features:

Review and configure these policies to strengthen your organization's security posture and ensure compliance with your data privacy and access requirements.

Project-scoped Users group

By default, users you add to an organization can view all organization and project information and settings. To limit access for specific users, you can enable the Limit user visibility and collaboration to specific projects preview feature. For more information, see Project-scoped users group.

[!INCLUDE project-scoped-users-warning]

::: moniker-end

Git repository and branch policies

To secure your code, set various Git repository and branch policies. For more information, see the following articles:

Azure Repos and Azure Pipelines security

Repositories and build and release pipelines pose unique security challenges that require additional security features. For more information, see the following articles.

Next step

[!div class="nextstepaction"] Permissions and groups reference

Related content