You implement the four-eyes principle in Azure Repos by ensuring that changes reach protected target branches only via pull requests, and are only completed there once they have been approved by at least one other person. Technically, this only holds up if direct pushes to those branches are restricted and exceptions to the rules are kept tightly controlled.
This answers the key question at repository level: one person may initiate a change, but must not be able to get it into the protected branch on their own. Everything else builds on this separation between proposal, review and completion.
This article therefore covers three points:
- the mandatory approval point in the process
- the Azure Repos settings that support the four-eyes principle
- the boundary between technical enforcement and organisational control
The focus is on Azure DevOps Services with Azure Repos. In Azure DevOps Server, features may vary depending on the version, so consider your environment separately.
What segregation of duties requires for software changes
Segregation of duties is first and foremost an organisational requirement. In other words, the same person should not be able to prepare, approve and make an important change effective on their own.
For Git workflows, that means looking at more than just the merge. Direct push permissions to protected branches, exceptions to rules and the later traceability of the decision are all relevant.
Azure Repos only covers the technical part of this. You can enforce the use of pull requests and document approvals. But the system cannot tell whether the people involved are genuinely independent in organisational terms, for example in cases of cover arrangements, nested groups or shared accounts.
The technical basis is Branch Policies. According to Microsoft Learn in “Branch policies overview” and “Branch policies”, accessed on 01/11/2026, they are turned off by default and must be deliberately configured for each branch.
For segregation of duties, these rules are particularly relevant:
- minimum number of reviewers
- automatically included reviewers
- Status Checks
- Build Validation
- linked work items
- comment resolution
A Status Check is a machine-readable check result that a service reports to a pull request and that can be required by policy.
Limit merge types is not part of the actual segregation control. According to Microsoft Learn “Securely use repositories and pull requests”, accessed on 01/11/2026, this setting mainly controls the history. If you want to review the technical exceptions around approvals and protection rules, the next useful step is to look at who may push, merge and bypass rules.
Minimum Reviewers, self-approval and the last pusher
For central branches such as main, Microsoft recommends in its security baseline restricting the permissions Bypass policies when completing pull requests and Bypass policies when pushing to a small admin group and requiring at least two reviewers. This is set out in Microsoft Learn “Securely use repositories and pull requests”, accessed on 01/11/2026. For the four-eyes principle, this is a sensible starting point, because it narrows both exceptions and normal approvals.
But the minimum number on its own is not enough. If the requesting person is allowed to approve their own change, then even a formal reviewer count may still be too weak in organisational terms.
That is why the key option in the reviewer policy is Allow requestors to approve their own changes. For strict segregation of duties, this option should not be allowed. Source: Microsoft Learn “Branch policies”, accessed on 01/11/2026.
A second layer of protection is Prohibit the most recent pusher from approving their own changes. This setting addresses the common case where further commits are added to the pull request after an initial review. The same person should then not be able to sign off the latest version themselves. This option is also documented in Microsoft Learn “Branch policies”, accessed on 01/11/2026.
In practice, the iteration logic is often even more important. With Require at least one approval on the last iteration, you ensure that there is still an approval for the current state after the last push. Historical approvals on older iterations are usually of limited value for real segregation of duties.
The stricter variants are Reset all approval votes and Reset all code reviewer votes. They force a fresh assessment after changes. This can sharpen control, but it also increases the review effort.
For Azure DevOps Server, Microsoft defines the scope of functionality more narrowly: from Server 2022.1 onwards, there is also an option to require an approval on every iteration. In each case, the source is Microsoft Learn “Branch policies”, accessed on 01/11/2026. You should therefore not assume identical behaviour between Services and Server.
In addition, Microsoft recommends automatically included reviewers for sensitive paths. This does not replace the need for independent reviewers overall, but it can make the separation of responsibilities more robust for specific directories or components. You can read more about this in required reviewers in Azure Repos.
Documenting the control for audits and internal reviews
For reviews and audits, what matters above all is whether your configuration can be evidenced in a reproducible and traceable way. It therefore makes sense to define a small target state for each critical target branch: responsible repositories, active policies, permitted exceptions, responsible groups and the route by which changes to these settings are approved.
A small number of fixed pieces of evidence are helpful here:
- export or structured record of the active Branch Policies for each target branch
- assignment of policy exceptions and bypass permissions to named admin groups
- evidence of which build validation for pull requests is required
- definition of which Status Checks are mandatory and which service they come from
- short process for emergencies, including subsequent review and documentation
For ongoing control, it is important that, according to Microsoft Learn “Branch policies overview” and “Branch policies”, accessed on 01/11/2026, policies can be managed via the REST API or with az repos policy. That is suitable for regularly detecting deviations from a target state or for deliberately approving changes. The technical route is covered in the article on pull requests via REST API.
It should also be possible to verify how you handle open discussions. If comments must be resolved before a pull request can be completed, that requirement belongs in the documented control path. The practical effect of the setting is shown in the article on open threads blocking the merge.
If your audit model evaluates the exact order of commits, also document the permitted merge strategies. Microsoft Learn “Securely use repositories and pull requests”, accessed on 01/11/2026, describes Limit merge types as governance of the history, not as actual approval evidence.
Limits of technical control in Azure Repos
Technology can enforce approvals, but it cannot assess their organisational quality. Azure Repos sees votes, status and policy results. What it cannot see is whether two people involved actually act independently in day-to-day work, whether cover arrangements are problematic, or whether shared accounts undermine the control concept.
Additional automation does not change that limit either. An external checking service can report results to pull requests; the article on status reporting via Service Hooks shows how such signals enter the process. But for the four-eyes principle, one thing remains decisive: a machine result is not a human approval.
The same applies to AI-assisted reviews. According to Microsoft Learn “Copilot code reviews” and the Sprint 279 Release Notes, both accessed on 01/11/2026, the function in Azure DevOps Services can be triggered automatically via Branch Policies. At the same time, Microsoft states clear limitations:
- only Public Preview, so with no SLA and subject to change
- only active pull requests with no merge conflicts
- only within the documented size and concurrency limits
For the actual approval logic, one point above all is important: according to Microsoft Learn “Review pull requests”, accessed on 01/11/2026, the result is always a Comment review. That does not satisfy a Required Reviewer policy and does not replace a mandatory reviewer.
Alongside that, there are operational and legal issues beyond Branch Policy. In “Copilot code reviews FAQ”, accessed on 01/11/2026, Microsoft states that the data residency of this review function is not bound to the data residency boundaries of the Azure DevOps organisation. Questions relating to data protection, DORA, NIS2 or co-determination should therefore be reviewed with legal counsel or data protection officers.
If you deliberately keep pull requests unfinished at first, that is more a question of handling draft pull requests than of the technical separation between approval and implementation.
Frequently asked questions
How can you tell whether your four-eyes principle is only formal or genuinely robust?
A robust setup is usually not reflected in a single policy, but in the combination of several safeguards. What matters is whether your protected branch still remains protected when someone is under time pressure, needs an exception or has permissions that are too broad.
So pay attention to how these points work together:
- direct write permissions to target branches
- small, named groups for bypass permissions
- review requirements on the last change
- documented status and build requirements
- traceable handling of exceptions
If you want to separate technical and organisational assumptions, it helps to look at security and data questions: it should be clearly visible there what applies today, what is only planned, and which state is being described with a date.
Which questions are often still open before approval for production repositories?
Before rollout, a short preliminary review outside the repository is worthwhile. This is not just about Git settings, but also about the operating model, responsibilities and possible side effects on internal controls.
Typical questions are:
- Who is allowed to change protection rules?
- Who decides in emergencies?
- How are exceptions reviewed later?
- Which identities may become technically effective?
- Do data protection, DORA, NIS2 or co-determination need to be considered separately?
The last group in particular is not just a configuration issue. Clarify such points with legal counsel or data protection officers.
How do you track the actual status of future agent functions?
A sober review path is more useful than relying on announcements. Look separately at publicly visible changes, evidenced metrics, and the access or operating framework described in each case.
Three questions are useful here:
- What has changed publicly? You can see that in the change log.
- What has actually been measured? That is what the evidence area is for; until there are real runs, it remains empty.
- What is described for access? That is set out in the subscription and sign-up framework.
The final section of this article already classifies this: as of 01/11/2026, Polier by ballmüller solutions is in development and not available.
Next step
Define a short checkpoint for each protected branch before approving changes to policies or permissions. That keeps the focus on whether your four-eyes principle actually works in day-to-day practice at the decisive points.
In particular, check:
- who is allowed to change policies
- who has bypass rights
- whether approvals are based on the last relevant change
- whether required reviewers and Status Checks match the protection need
- how exceptions are documented and later traced
The same standard is enough when looking at possible agent functions. As of 01/11/2026, Polier by ballmüller solutions is in development and not available; it is intended for Azure DevOps Services, with the customer’s existing Branch Policies applying, and the agent itself never merges.