Azure DevOps Pipelines is the dominant CI in the Microsoft-centric enterprise, and the platform has shipped a meaningful set of supply chain features over the past two years that change the hardening picture. Workload identity federation has replaced most long-lived credentials, the template trust model has matured, and the environment approval gates are now flexible enough to carry real verification logic. The defaults, however, still allow a lot of patterns that would not survive a careful threat model.
This guide is a working pipeline engineer's view of the controls that matter in 2026. We focus on the changes that have happened recently, because most of the guidance written before 2024 is now out of date in load-bearing ways.
How should service connections be configured?
Service connections are the seams between Azure DevOps and external systems, Azure subscriptions, container registries, package feeds, and they are where the most consequential supply chain decisions get made. In 2026, every Azure service connection should use workload identity federation rather than service principal secrets or certificates. Federation exchanges the pipeline's OIDC token for a short-lived Azure access token at job run time, with no long-lived credential stored on the Azure DevOps side.
The federation trust on the Azure side should be scoped tightly. Match on the specific pipeline, the specific branch, and the specific environment where appropriate. A broad federation subject that accepts any pipeline in the project gives an attacker who lands in any build job the ability to assume the role. The configuration takes a few extra minutes per service connection and is worth every minute.
Beyond Azure, service connections to Docker registries and NuGet feeds should use scope-limited tokens with read-only access where the pipeline only consumes, and explicit push permissions only on the connections that publish artifacts. The standard mistake is to reuse a single registry credential for both pull and push across all pipelines.
How do environment approvals carry verification logic?
Azure DevOps environments support pre-deployment approval gates that can be wired to required reviewers, business hours windows, and, more interestingly, custom checks that invoke external services. The custom check pattern is where the real verification logic should live in a mature pipeline: an external service runs SLSA verification, SBOM analysis, and policy evaluation, and returns an approval or rejection to the environment gate.
The environment is the right choke point because it is the single place every deployment to that target flows through, regardless of which pipeline produced the artifact. Concentrating verification at the environment rather than scattering it across pipeline YAML keeps the policy auditable and avoids the failure mode where one pipeline is verified rigorously and an adjacent one bypasses every check. Treat the environment configuration as production-critical infrastructure, restrict who can modify it, and audit changes.
How should templates and template trust be configured?
Azure DevOps pipeline templates are powerful and underused for security. Templates can declare required parameters, restrict which repositories can extend them, and enforce constraints on the consuming pipeline. The template-extends pattern, where a pipeline must extend a corporate security template that enforces a set of mandatory steps, is the cleanest way to ensure that every pipeline runs SBOM generation, vulnerability scanning, and provenance signing without relying on developers to remember.
The setting that closes the loop is the required template approval at the project level, which forces any new pipeline using a given template to be approved by a designated reviewer the first time it runs. Combined with the resource authorization model, where templates from other repositories must be explicitly authorized, this prevents a developer from creating a new pipeline that bypasses corporate security controls by simply not extending the security template.
How are agents and agent pools isolated?
Microsoft-hosted agents are ephemeral and managed, which is the safer profile for most workloads. Self-hosted agent pools are where operational discipline matters. Run self-hosted agents on ephemeral compute, fresh VM or container per job, never reused, and isolate pools by trust level. Build agents that compile internal code live in one pool; deployment agents that touch production live in a separate pool with separate network policies, separate credentials, and a narrower set of authorized pipelines.
The agent pool security tab is where most of the access control happens. Restrict which pipelines can use the pool, restrict which users can manage the pool, and audit the authorization list periodically. The agent pool is a credential boundary, treat it as one, and do not let high-trust and low-trust pipelines share a pool.
How do you integrate SLSA provenance and signing?
Azure DevOps has matured its SLSA provenance support through 2025 and 2026, with native Level 3 conformance on Microsoft-hosted agents using the Azure DevOps SLSA generator extension. The generator captures the materials, the pipeline identity, and the artifact digest, signs the predicate with cosign using the Azure DevOps OIDC token via Fulcio, and pushes the signed bundle to Azure Container Registry or any sigstore-aware store.
The verification side runs at the environment gate as a custom check that invokes slsa-verifier with policy pinned to the expected pipeline identity. The combination of workload identity federation, environment approvals, custom checks, and SLSA verification gives Azure DevOps a credible production posture for supply chain enforcement. The components have existed in pieces for a few years; the maturity in 2026 is in how cleanly they compose.
How Safeguard Helps
Safeguard ingests Azure DevOps SLSA provenance and SBOMs alongside data from other CI systems, treating all of them as evidence in the same supply chain inventory. Griffin AI correlates Azure DevOps pipeline identity with artifact CVE findings and reachability, surfacing regressions in service connection scope, template extension, and agent pool boundaries. Policy gates run as environment custom checks, verifying SLSA level, signing identity, and SBOM completeness before allowing a deploy to proceed, using cosign and slsa-verifier under the hood. TPRM scoring covers vendors who ship via Azure DevOps, and zero-CVE base images integrate cleanly with ACR and Azure DevOps build flows for downstream consumers.