The required template check fails any pipeline that does not extend a specific YAML template before it uses a protected resource such as a service connection. Combined with an extends template that fixes the pipeline structure, it lets a platform team require scanning steps that pipeline authors cannot remove.
Includes versus extends
Azure Pipelines offers two template styles. An includes template pastes its steps into the calling file, like an include in C++. An extends template defines the outer structure of the pipeline and exposes only chosen points for customization, like inheritance. Microsoft recommends starting with extends templates for the most secure pipelines.
The security idea is simple. The template owns the shape, and the pipeline author fills in allowed slots. Because a template is expanded before the run, its parameters become constants and can be type checked, for example by limiting a pool parameter to a list of approved pools.
What a template can enforce
| Control | What it does |
|---|---|
| Step targets | Run user steps inside a container so they cannot alter the agent host |
| Type safe parameters | Restrict pools or images to an approved list |
| Logging command restrictions | In restricted mode, block most agent services, and limit which variables a step can set |
| Conditional jobs | Run restricted jobs only for the main branch |
| Syntax modification | Rewrite user steps, for example to strip inline script steps |
| Template steps | Automatically add steps, such as credential scanning, before user steps |
The documentation gives an example that inserts a credential scanning task before the user steps in every job.
Why a template alone is not enough
A template is only a convention until something enforces it. A pipeline author could simply not extend it. Microsoft says template effectiveness relies on enforcement, and the control point is the protected resource.
That is the job of the required template check. You add it on a service connection, for example, and specify the repository type, repository, ref, and path of the template. If the pipeline does not extend that template, the check fails and the stage using the connection does not run. You can require more than one template on the same connection.
Setup steps
- Put the template in its own repository with tight branch policies, so only the platform team can change it.
- Pin the reference to a tag or branch so a breaking change does not hit every pipeline at once.
- Open the service connection, then Approvals and checks, and add Required template.
- Enter the repository type, repository name, ref, and path to the template.
- Run a pipeline that does not extend the template and confirm the check fails.
- Repeat on other protected resources such as environments and agent pools.
Limits to know
Microsoft's templates page says this check applies only when the pipeline extends from a template, so test a pipeline with no extends line to see how your setup behaves. Templates also cannot protect a resource that has no check, and a user with administrator permission can bypass a check, so keep that group small.
Try it yourself
The demo below shows a static code scan step. Click through it and think about which step in your own template would run it for every pipeline automatically.
Click through it at your own pace, or open it full screen.
Quick check
Does a required template check stop a pipeline that does not use templates?
Microsoft's documentation says the check fails a pipeline that does not extend the referenced template. It also says the check applies only when the pipeline extends from a template, so test your own setup with a pipeline that has no extends line.
Why pin a template to a tag?
So a breaking change in the template does not affect every pipeline that extends it at the same moment.
Safeguard's CLI can run in a pipeline step, so a platform template can include it for every team. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
