A Service Principal in Azure DevOps is a non-human identity from Microsoft Entra ID for services and automation in Azure DevOps Services. It separates technical access from user accounts and allows permissions to be controlled more precisely; for approvals and protection rules, Branch Policies and PR status as a policy need to be considered separately.
For day-to-day operations, a simple three-part split helps:
- Identity: Who is signing in technically?
- Permission: What is that identity allowed to do?
- Policy: Which checks must be satisfied before a pull request can be completed?
This separation prevents sign-in account, permissions and merge protection from being mixed together in planning. That is particularly important for repositories, because an identity should not automatically be able to bypass rules; in that context, it is also worth looking at bypass permissions.
The rest of this article therefore focuses on non-human identities in Azure DevOps Services, how they differ, and how to use them sensibly in operations. Azure DevOps Server is mentioned only where the differences matter for the decision.
The options for non-human identities in Azure DevOps
First, the term needs to be clearly distinguished: a Service Principal is an application identity from Microsoft Entra ID. It does not represent a person, but an application or service that authenticates itself technically to Azure DevOps Services.
In practice, this is the right option when your own service or an external service needs to access Azure DevOps without using an employee's user account. Typical cases include API access, automation around repositories, or processes that create or update pull requests. If you want to decouple such workflows technically, it is also worth looking at pull requests via the REST API.
This should be distinguished from a Managed Identity. That, too, is a non-human identity, but it is provided by Azure for a resource. It is mainly suitable when your service runs in Azure and the target access supports Entra-based authentication.
Azure DevOps also has other technical identities:
- Build service accounts and related system identities for pipelines and internal system operations
- Service Connections as stored connections to target systems
- and within those, different authentication methods, such as Service Principal, Managed Identity or another approach
One important point is this: a Service Connection is not itself the same thing as a Service Principal. It is the connection configuration in Azure DevOps; the identity behind it is a separate decision. For event-driven automation, the article on Service Hooks for pull requests is also useful in this context.
The real benefit of non-human identities lies in separating them by task. You can tailor permissions to each function instead of using a single user account for everything. That also becomes important where you later manage protection mechanisms and workflows as code.
For Azure DevOps Services, Entra-based identities are now the natural point of reference. Azure DevOps Server has different constraints and does not support modern cloud features in the same way. One solid indication of this: on 24.10.2026, Microsoft's documentation for Azure DevOps MCP Server did not mention support for Azure DevOps Server (Microsoft Learn, “Remote MCP server troubleshooting”, checked 24.10.2026).
Why PATs are a last resort
A Personal Access Token is a secret access token tied to a user account and used to make calls to Azure DevOps in that person's name.
In operations, that is often exactly the problem. To the outside world, the automation does not appear as its own technical actor, but as user activity. That makes clean attribution in logs, approvals and internal controls more difficult.
There is also a dependency on the account lifecycle. If the employee's role, group memberships or status change, the automation may be affected unintentionally. The technical function then depends on a person-bound access path, even though from a business perspective it ought to be separate from it.
Organisationally as well, a PAT is often more cumbersome than it first appears:
- issuance and secure storage need to be defined
- rotation and revocation require a fixed process
- scope and purpose should be documented
- otherwise old tokens can easily remain in place for too long
This mixing of person and automation is especially unhelpful if you later want to analyse workflows properly. The question then is not just what happened, but who actually acted.
A PAT can still be used as a temporary solution if a tool does not support any other access path. In that case, its use should be tightly limited, clearly time-bound and justified from a business perspective.
As soon as automation moves closer to code, pull requests or reviews, it is worth making a sober architectural decision. In such designs, it is particularly important to plan roles, permissions and technical boundaries separately; in that context, it is also worth looking at agentic workflows in Azure DevOps.
Separate identities for each role
A role model for technical identities in Azure DevOps should not begin with the question “What automation do we want to build?”, but with “What single action does this identity need to perform?”. Permissions follow directly from that.
Useful roles are often separated by:
- reading repository and pull request data
- creating or updating pull requests
- reporting a PR status
- carrying out build-related tasks
The key point is this: a status on a pull request is not the same thing as an approval. If something only sets a status, it needs its own narrowly scoped technical identity for that purpose. That way, it remains auditable which component did what, and you avoid one function quietly acquiring permissions for other steps as well.
For the main branch, Microsoft recommends as a guide a small administrator group for the permissions “Bypass policies when completing pull requests” and “Bypass policies when pushing”. In addition, there should be at least two reviewers, automatically included reviewers for sensitive paths, linked work items, build validation and comment resolution (Microsoft Learn, “Secure Azure Repos and GitHub repositories with pull request and branch policies”, read 01.11.2026). A technical identity for status reporting therefore does not normally belong in that bypass group.
Likewise, you should not mistake “Limit merge types” for a security mechanism. The setting controls the history. Microsoft describes it as a governance issue; whether squash or merge commit is the better fit depends, among other things, on whether your traceability requires the exact commit sequence (Microsoft Learn, “Branch policies” and “Secure Azure Repos and GitHub repositories with pull request and branch policies”, read 01.11.2026).
If you are assessing such roles for new agentic workflows, three separate questions help: which identity acts, which data flows, and which guardrails actually apply. For the currently described state of such points, the right places are the current security and data information, the public changelog, later documented measured results and the intended framework for sign-in and packages.
Seats and licensing at a general level
With Service Principals and licensing in Azure DevOps, the question often heads in the wrong direction. What matters is not the name of the identity, but how it actually uses Azure DevOps.
Three angles help with classification:
- Which function is being used?
- Through which access path does the access take place?
- Is the identity only acting technically in the background, or is it using functions that would otherwise be reserved for people?
That is why a general statement such as “Service Principals always need a seat” or “never need a seat” is not reliable. Always assess the case based on the specific usage in your organisation.
Particularly in mixed environments, you should also take the product status into account. Azure DevOps Services and Azure DevOps Server are not aligned when it comes to newer functions. On 24.10.2026, Microsoft documented that Copilot Code Review was not available on Azure DevOps Server; at the same time, Microsoft refers customers to Azure DevOps Services or migration to it for its AI services (Microsoft Learn, “Enterprise Live Migrations overview”, checked 24.10.2026; Microsoft documentation on Copilot Code Review, checked 24.10.2026).
For practical purposes, one short checkpoint is enough: do not derive licensing and seat questions from the identity type, but from the function, access path and product variant.
Frequently asked questions
Can a Service Principal approve pull requests?
Technically, a non-human identity in Azure DevOps can perform actions on pull requests. For security, however, you should keep that separate from review and governance.
The distinction matters:
- A vote or reviewer entry is an approval action.
- A PR status is a technical signal.
- A branch policy decides what must be satisfied before completion.
If you are connecting automation to pull requests, a status check is usually clearer than a technical “approval”. Microsoft lists branch policies including minimum number of reviewers, linked work items, comment resolution, build validation and status checks; all of them are turned off by default (Microsoft Learn, “Branch policies overview” and “Branch policies”, read 01.11.2026).
Where is a Service Principal used in practice in Azure DevOps?
Typical uses are wherever a service needs repeated and auditable access to Azure DevOps Services, for example to:
- read repository and pull request data
- create or update pull requests
- report statuses on pull requests
- connect processes via the REST API or policies
For Azure DevOps Services, policies can also be managed via the REST API or with “az repos policy” (Microsoft Learn, “Branch policies” and “Secure Azure Repos and GitHub repositories with pull request and branch policies”, read 01.11.2026).
Is a Service Principal on its own enough for secure pull request workflows?
No. The Service Principal is only the identity. Whether a workflow is robust also depends on permissions, branch policies and the separation of roles.
For main branches, Microsoft recommends, among other things:
- bypass permissions only for a small administrator group
- at least two reviewers
- automatically included reviewers for sensitive paths
- checking linked work items
- build validation
- comment resolution
Microsoft describes this as a security baseline for protected repositories (Microsoft Learn, “Secure Azure Repos and GitHub repositories with pull request and branch policies”, read 01.11.2026).
Next step
Turn this into a short operational decision rather than a matter of principle. For each technical identity, define in writing:
- purpose of the identity
- responsible operational owner
- required permissions in Azure DevOps
- procedure for review, rotation and withdrawal
After that, set a fixed review date. This is not only about permissions, but also about whether an automation still needs the same access today as when it was first introduced.
As soon as technical identities process content from work items, repositories or pull requests, this often touches on data protection, DORA, NIS2 and co-determination rights. Clarify these points with your legal adviser, your data protection officer and, where applicable, the works council.
In the context of such architectural questions, ballmüller solutions is currently developing Polier for Azure DevOps Services; status as of 01.11.2026: in development and not yet available.