To secure Azure Repos, start with branch policies on your main branches (required reviewers, build validation, comment resolution), then tighten who can sign in and which tokens exist, and add automated scanning. Microsoft's own security overview for Azure DevOps supports each of these. Here are eight settings to check in an afternoon.
1. Are branch policies on every protected branch?
Branch policies are the center of Azure Repos security. Microsoft's documentation describes policies that require reviewers, builds, status checks and other pull request protections before a merge. Apply them to main and to any release branch. A policy that exists on one branch and not its sibling protects nothing.
2. Is the minimum reviewer count real?
Set "Require a minimum number of reviewers" and read the option allowing requestors to approve their own changes. Microsoft notes that this setting applies per policy, so two policies can disagree. Turn self approval off for sensitive repositories, or the control becomes decoration.
3. Does a build have to pass first?
Build validation runs a pipeline against the proposed merge. Make it required, not optional, and include tests plus a dependency check. A required build with no security steps still gives you a compile check, which is something.
4. Do comments and work items block the merge?
"Check for comment resolution" stops a pull request with open comments. "Check for linked work items" requires a ticket link, which gives auditors a trail from change to reason. The documentation says you can set work item linking as optional to warn instead of block. For regulated work, choose required.
5. Who can sign in, and from where?
Microsoft's overview lists network protection and access controls. Among them: IP allowlisting for trusted sources, Conditional Access policies through Microsoft Entra, and restricting unnecessary authentication mechanisms. It also notes that public projects are retired, with existing ones converted to private in 2027. Check whether any of your projects are still public.
6. What tokens exist?
The overview describes alternatives to long lived personal access tokens for service accounts. Review the list of active tokens, delete the ones nobody can explain, and prefer short lived identity based access for pipelines. A token with repository write access is a key to your source code.
7. Are you applying Zero Trust to the DevOps platform itself?
Microsoft's guidance applies "never trust, always verify" to the DevOps platform, the development environment and developer workflows. In plain terms, treat the repository host as a high value target, because whoever controls it controls what you ship.
8. Is scanning automated?
The overview mentions Component Governance for CI/CD, which alerts on known vulnerabilities in open source components, checks licenses, and tracks components across repositories. Whatever tool you use, the point is that scanning runs on every change, not when someone remembers.
A constructed example
A team audits its Azure DevOps organization and finds three things: main requires one reviewer but allows self approval, a pipeline token created two years ago still has write access, and build validation exists but skips tests on branches named hotfix. Each fix takes minutes. Together they close the routes a careless merge or a stolen token would use.
How to check or apply this
- List your repositories and the branch policies on each default branch.
- Disable self approval where it is not needed, and make build validation required.
- Export the token and service connection list, and revoke anything stale.
- Confirm sign in restrictions and project visibility.
- Add dependency and secret scanning to the required build.
- Re-run this audit every quarter and keep the results.
Safeguard offers dependency scanning and policies and gates for pull requests that can run alongside Azure DevOps pipelines, and its CLI and local runner fit into a build step.
Quick check
What is the single most useful Azure Repos setting?
Branch policies on the default branch, with required reviewers and required build validation.
Should I use personal access tokens in pipelines?
Microsoft's security overview points to alternatives for service accounts. Prefer short lived, identity based access where it is available.
Sources
Last reviewed: 18 October 2026.
