Azure DevOps is the CI/CD that runs the majority of the Fortune 500's production builds, and it is the one that gets the least supply chain attention in the security press. That mismatch has consequences. Most large Azure DevOps tenants I have audited in the last year have at least one pipeline that can deploy to production with no human approval, no source verification, and no artifact attestation. Those pipelines are the soft underbelly of an otherwise mature security program.
The controls you need in 2026 are not the same controls Microsoft documented in 2022. The platform has shipped meaningful new primitives — pipeline templates with mandatory parameters, federated service connections, and the new manifest-based deployment groups — that most security teams have not absorbed. This guide is what an actually-defended Azure DevOps tenant looks like in 2026.
Why is Azure DevOps the highest-leverage attack surface in many enterprises?
Because Azure DevOps pipelines often hold federated identities to multiple Azure subscriptions, and the federation tokens can be used to deploy ARM templates, Bicep modules, and Terraform stacks into production without any further authentication. A compromised pipeline becomes a key to the entire Azure estate.
The threat model in 2026 has two new wrinkles. First, the migration from classic service connections to federated identity has happened unevenly, and many tenants run a mix of both. The classic connections store secrets that can be exfiltrated; the federated ones cannot, but the federation trust policy can be modified by anyone with the right pipeline permission. Second, the pipeline template ecosystem has grown. Many enterprises now consume pipeline templates from a central platform team's repository, which means a compromise of the platform team's repo cascades to every pipeline that imports it.
The platform team repo is the unsung most-valuable target in an Azure DevOps tenant. It contains the templates that hundreds of pipelines run, and the access controls on it are usually weaker than the access controls on the production-deploying pipelines themselves. Defenders have to harden the platform team repo as if it were a production deployment surface, because effectively it is.
How do I secure service connections in 2026?
Use federated workload identity for every Azure subscription, never store a secret in a service connection, and require approval and check policies on every connection that touches production. Federated workload identity uses OIDC tokens that are issued at pipeline run time, scoped to the pipeline, and unusable outside the pipeline context. That eliminates the credential-exfiltration path entirely.
The federation trust policy needs to be locked down. The default trust allows any pipeline in the project to use the connection, which is too wide for any production-impacting connection. The fix is to use the per-pipeline federation feature, which binds the connection to a specific pipeline definition by ID, and refuses tokens issued for any other pipeline.
The approval and check policies are the next layer. Azure DevOps lets you require manual approval, business hour windows, exclusive lock, and arbitrary REST API checks before a pipeline can use a service connection. The exclusive lock is the one that prevents the most common supply chain race condition: two pipelines using the same connection at the same time, where one is malicious and the other is authentic, and the malicious one finishes first.
What does template hygiene look like for Azure DevOps in 2026?
Pin every template reference to a specific commit SHA, never a branch or a tag. Require that templates from outside the project come from an explicitly allowlisted repository. Use extends with a required template that runs at the top of every production pipeline and enforces the controls the platform team cares about.
The commit SHA pinning is the control most pipelines miss. A template reference of template: pipelines/build.yml@platform-templates defaults to the head of the default branch. If the platform team's default branch is compromised, every pipeline that imports the template runs the compromised code on its next run. Pinning to a SHA makes the import deterministic and forces a deliberate update path.
The allowlist enforcement uses the new repository resources feature. You declare which external repositories the pipeline can extend templates from, and Azure DevOps refuses any template reference that is not in the list. This is set at the project or organization level, and the audit log of changes to it is the highest-priority security signal in the tenant.
The required extends template is where the platform team enforces global controls. The template emits an SBOM, runs the source-signature verification, attaches an attestation to every artifact, and refuses to proceed if any of those steps fail. Because every production pipeline extends it, the platform team has a single point of enforcement for global policy.
How do I keep agent pools from becoming a pivot path?
Use Microsoft-hosted agents for low-trust work, self-hosted agents in dedicated VMs for high-trust work, and never share an agent pool between the two. The Microsoft-hosted agents are ephemeral by design and reset between jobs, which makes them a bad target for persistence. Self-hosted agents persist by default, which is convenient and dangerous in equal measure.
The dedicated VM pattern is the one most enterprises get wrong. A self-hosted agent that runs builds for ten different teams accumulates secrets, build caches, and toolchain state that any compromised job can read. The fix is one agent per team or per trust boundary, with the agent VM rebuilt nightly from a known-good image, and with no persistent disk attached.
The other thing to watch is the agent's outbound network. A self-hosted agent in a corporate network has access to internal resources that the pipeline definition does not declare. An attacker with code execution on the agent can pivot to any internal resource the agent can reach. The defence is to put self-hosted agents on a dedicated subnet with explicit egress rules, audited at the firewall level, not at the agent level.
What about secret handling in pipelines?
Use Azure Key Vault references with the new just-in-time retrieval mode, never variable-group secrets that are persisted across runs. The just-in-time mode requests the secret from Key Vault at the moment the pipeline step runs, with a short-lived federation token, and never caches the secret on the agent.
The variable group pattern is convenient but problematic. A variable group secret is readable by any pipeline that has the group linked, and the linkage permission is wider than most teams audit. A misconfigured pipeline can dump the secret into a log or pass it to an external process, and the secret is then compromised across every pipeline that uses the group.
How Safeguard Helps
Safeguard ingests Azure DevOps pipeline definitions, service connection configurations, and agent pool topology, and produces a continuous posture signal that maps to the controls above. The posture signal flags pipelines that import templates from non-allowlisted repos, service connections that still use stored secrets, and agent pools that span trust boundaries.
Griffin AI generates pinned template references, federated service connection configurations, and required extends templates from an existing pipeline graph, then opens pull requests against the platform team's repo to roll the changes out. The PR-driven workflow is what makes the rollout tractable in tenants with hundreds of pipelines, because the platform team reviews and approves the change rather than the security team chasing each pipeline.
Safeguard's SBOM module attaches an in-toto attestation to every Azure DevOps pipeline output at the dependency depth the policy requires, the TPRM module tracks the trust state of every external template repository the tenant references, and the policy gate module integrates with Azure DevOps approval checks so a stage cannot proceed unless Safeguard's policy decision passes. The integration is direct: a pipeline approval is wired to a Safeguard policy ID, and the policy evaluates reachability, license risk, and provenance at the moment the approval is requested.
For multi-tenant Azure DevOps customers, Safeguard rolls up posture across organizations, so the security team has a single view of which pipelines are out of compliance and a single workflow for getting them back into compliance.