Azure DevOps security groups
What they are
Azure DevOps security groups collect users, service accounts, and other groups so Azure DevOps can apply permissions to organization, project, or individual objects such as a repository or pipeline. Built-in examples include Readers, Contributors, and Project Administrators; teams also create team security groups.
Why they exist
They make authorization manageable. Grant a delivery team permission to queue a pipeline or contribute to a repository once through a group, rather than maintaining the same permission for every person.
Not the same as
- security-group — the disambiguation node: an Entra security group and an Application Security Group solve different identity and networking problems.
- azure-devops-access-levels — an access level exposes portal features; a security group grants or denies specific Azure DevOps actions. A user can need both.
- rbac — Azure RBAC controls Azure resources. Azure DevOps permissions control Azure DevOps objects.
Permission model
Azure DevOps evaluates authorization after authentication. Permissions can be assigned through group membership or directly, may inherit by scope, and use Allow, Deny, or Not set states. Do not assume that being a Contributor, or having Basic access, automatically authorizes every repository, environment, or pipeline operation.
Operational failure mode
A user can sign in and see a project but still be unable to queue a pipeline or modify a repository. Check the user’s access level, group membership, object-level permission trace, explicit Deny, and whether a recent Entra-group change has propagated.
Related
azure-devops-access-levels · security-group · devops-platform-authentication · azure-repos · azure-pipelines · rbac
Sources: Azure DevOps permissions and security groups · Authentication, authorization, and security policies