No. Microsoft's documentation says the "Grant access permission to all pipelines" option is not recommended. Ticking it lets every current and future pipeline in the project use that service connection, including pipelines written by people who should never touch production. Authorize each pipeline individually instead.
What the option does
A service connection holds the credentials or trust that a pipeline uses to reach something outside Azure DevOps: a cloud subscription, a container registry, a Kubernetes cluster. When you create one, the dialog offers the all pipelines option. If you leave it off, a pipeline must be explicitly authorized before it can use the connection.
With it on, anyone who can create or edit a pipeline in the project can point it at that connection. The pipeline definition is just YAML in a repository. If your branch controls are weak, that is a path to production credentials.
Two layers of permission
Microsoft separates the controls on protected resources into two kinds.
| Layer | Question it answers | Typical setting |
|---|---|---|
| User permissions | Who can manage or administer this connection? | A small group in the User or Administrator role |
| Pipeline permissions | Which pipelines may use it? | An explicit list of trusted pipelines |
The documentation says pipeline permissions guard against copying protected resources to other pipelines. It also says only a Project Administrator can enable access across all pipelines, and that you should not enable open access.
How to fix existing connections
- List your service connections and open each one.
- Look at the pipeline permissions. If all pipelines have access, note which pipelines actually use the connection.
- Remove open access and authorize only those pipelines.
- On the Approvals and checks tab, add controls that suit the connection, for example a manual approval or a branch control check.
- If a connection is no longer needed, a service connection administrator can disable it so that pipelines that reference it fail until it is enabled again.
- Record an owner and purpose for each connection, the same way you would for a service account.
What authorizing one pipeline looks like in practice
The first time an unauthorized pipeline runs and needs the connection, it pauses and asks for permission. A person with the right role then permits it. This is a small friction that turns an invisible dependency into a recorded decision.
Pair it with the right credential type
Open access is worse when the connection carries a long lived secret. Microsoft recommends workload identity federation for Azure Resource Manager connections, which removes the stored secret entirely. If a pipeline is compromised, there is then no static credential to steal. See the related post on federation versus secrets.
Quick check
Does disabling a service connection delete it?
No. Disabling prevents pipelines from using it until it is enabled again. Pipelines that reference a disabled connection fail or are denied access.
Who can enable access for all pipelines?
Microsoft's resource security page says the Project Administrator role is needed to enable access to a protected resource across all pipelines.
Safeguard can inventory the assets and pipelines connected to your code and flag risky configuration, and a free scan is available at gold.safeguard.sh/scan. A service connection review is still a manual platform task.
Sources
Last reviewed: 19 October 2026.
