Microsoft's Azure Resource Manager service connection guidance gives security teams a clear starting point: use workload identity federation where possible, authorize pipelines individually, and avoid granting a connection to every pipeline. Those recommendations are easy to list and surprisingly hard to verify across a large organization. A release pipeline, its service connection, the linked Microsoft Entra identity and that identity's Azure role can be owned by different teams. An assessment needs to follow the whole authorization path.
Quick answer. Scope an Azure DevOps service connection test from the pipeline definition to the Azure resource it can change. Review who can edit or run the pipeline, which pipelines can use the connection, how the connection obtains credentials, what the identity can do in Azure, and which approvals intervene before a production action. Validate a small set of permitted scenarios under written rules of engagement. The deliverable should connect each observed permission to a business owner and a retest result.
This is a buyer's guide for platform engineering and security teams running mid-market or enterprise delivery systems. It addresses customer-controlled Azure DevOps and Azure configuration. It does not claim a flaw in Microsoft's hosted platform, and it does not require publishing pipeline definitions, tenant names or secrets.
Figure 1: A service connection assessment follows four related control decisions, from pipeline access to Azure role scope. Sources: Microsoft's service connection guidance and DevOps platform security considerations.
Why a service connection belongs in a penetration test
An Azure Resource Manager service connection lets an Azure Pipeline reach Azure resources, including services such as Key Vault. Microsoft describes both the connection and the workload identity it uses. The connection is a bridge: a user may have modest Azure privileges but broad pipeline permissions, while the pipeline runs with an identity that can change valuable cloud resources. Conversely, a tightly controlled pipeline can still be risky if its identity has a subscription-wide role it does not need.
The central question is who can cause this identity to act, on what resource, after which approval. A static review that counts service principals cannot answer it. Neither can a web application test that never examines release infrastructure. The test must join Azure DevOps access, pipeline configuration, Entra credentials, Azure RBAC and change-management evidence. Where the pipeline deploys an application, the application itself can be tested separately as a web application; those are different surfaces and findings.
Microsoft's Cloud Adoption Framework guidance recommends a separate service connection and identity for each application and environment, approvals on service connections and federated credentials scoped to the service connection. These are useful assessment hypotheses. They are not proof that every environment needs an identical implementation or that a missing approval always leads to compromise. The assessor should ask what business workflow each exception supports and test whether its actual reach matches the approved design.
Draw the trust path before testing
For each representative deployment, record the repository and branch that supply the pipeline, the people and groups able to change it, and the service connection selected by the job. Then identify the associated Entra app registration or managed identity, its federated credential or other authentication method, and the Azure role assignments it receives. Finish with the resources and environment approvals that the release can reach.
The picture should include adjacent routes. A deployment template may be stored in another repository. A shared pipeline may be invoked by many teams. A service connection can be reused across projects or environments. Azure role assignment inheritance can make the practical scope broader than the resource group named in a project ticket. These are areas to verify in the customer's tenant; they are not presumed defects.
Use a sample designed around different privilege patterns, not just the biggest pipelines. Include a routine development deployment, a production release, a shared infrastructure pipeline and one integration whose owner is unclear. That sample reveals more than testing four nearly identical services. For a large enterprise, add business units with different Azure DevOps organizations or Azure tenants and state where the sampling stops.
The four controls to validate
Pipeline use of the connection
Microsoft says selecting Grant access permission to all pipelines lets all pipelines use a service connection and is not recommended; it recommends authorizing pipelines individually. Inventory connections that still have broad pipeline access. For each, identify who can create or edit a pipeline in the relevant project and whether a less privileged project contributor can make the connection act on a more privileged environment.
Do not equate the existence of a connection with exposure. A service connection may be appropriately isolated even when it is powerful, or a narrowly scoped connection may be available to an inappropriate pipeline. Report the intersection of pipeline use, pipeline edit permissions and target role. The buyer should expect a reproducible permissions path and a recommendation that preserves necessary delivery workflows.
Authentication and federation
Microsoft recommends workload identity federation with an app registration or managed identity because it removes stored connection secrets and secret management. In an assessment, identify older secret-based connections, their rotation owner and any repositories or variable groups where related credentials are stored. Do not copy secret values into the report; record location, custody, exposure condition and rotation action without reproducing the material.
For federated connections, examine the trust relationship, not merely the label “secretless.” Verify that the subject and issuer belong to the intended organization and service connection, and that credentials are not reused for an unrelated pipeline. This is a configuration review tied to permitted tests; it is not an invitation to try arbitrary credentials or third-party tenants. Microsoft's DevOps security guidance specifically calls for federated credentials scoped to the connection.
Microsoft also documents a future issuer change for certain public-cloud workload identity federation connections, with a 1 July 2027 retirement for the old issuer. It identifies exclusions for non-public clouds and multitenant applications. This is an inventory and migration-planning item, not evidence that every current connection is vulnerable. Capture which connections match the affected configuration before adding it to a remediation list.
Azure permissions and separation
Inspect the role assignments effective for the connection identity at the subscription, resource-group and resource level. Compare them with what the pipeline genuinely deploys. A pipeline that only updates one application should not silently inherit an unrelated production data platform. Test whether application and environment separation works as intended, especially where shared identities cross development and production. Microsoft's guidance explicitly recommends separate connections and identities per application and environment.
“Least privilege” becomes actionable only when the report names the resource, role, identity, allowed task and narrower alternative. If a deployment needs elevated privileges for a short operation, document the approval and expiry path. If a role appears broad because of a centralized platform design, test the compensating controls and say what they do and do not block. Avoid speculative findings based solely on a role name.
Approvals and evidence
Microsoft recommends approvals on the service connection. Review who can change those approvals, who can approve a production use and whether the approver is meaningfully independent of the pipeline author. Follow a benign authorized release through the approval and logging trail. Ask whether the same person can alter the pipeline, approve its run and change the service connection's protection. A missing separation may be a design choice in a small team; the report should show the resulting exposure rather than assert a universal policy breach.
The evidence bundle should include timestamped configuration exports or screenshots, effective Azure role assignments, an approved test run identifier, approval outcome and the Azure activity tied to the test identity. Redact tenant identifiers and credentials before sharing outside the response team. For failed or denied test cases, preserve the denial event as proof that the boundary operated, not merely as a screenshot of a configured rule.
A sample assessment matrix
Test question | Authorized validation | Evidence a buyer should receive |
|---|---|---|
Can an unapproved pipeline use a protected connection? | Compare permissions and run a benign test pipeline under a permitted lower-privilege account. | Connection authorization setting, run result and denial or approval event. |
Does federation bind the intended pipeline to one identity? | Review issuer, subject and identity mapping; validate only with a test identity. | Redacted trust mapping and observed token-use outcome without token values. |
Can a development path change production resources? | Compare role scopes and attempt a harmless approved operation on a designated test resource. | Effective role path, target, decision and change ticket. |
Can one person change and approve a sensitive release? | Review role memberships and perform a controlled approval workflow. | Actor roles, run ID, approval record and exception owner. |
Does revocation close the path? | Remove a temporary test grant and repeat the benign operation. | Before and after decisions, log timestamps and residual access check. |
The matrix is a proposed method, not a claim that these controls fail in a particular company. The rules of engagement should specify test identities, test resources, windows, stop conditions and an Azure administrator who can reverse a change. Production deployment disruption is not necessary to answer most of the questions.
Scope and procurement questions
A useful request for proposal names the Azure DevOps organizations, projects, representative pipelines, service connections, Azure subscriptions and Entra tenants in scope. It specifies whether the tester can inspect pipeline definitions, Azure RBAC and approval history, and whether a non-production test identity and resource are available. It should also name excluded release systems and third-party integration owners. Without these inputs, “Azure DevOps pentest” can mean anything from a repository scan to a cloud control-plane assessment.
Ask how the provider will trace a finding across DevOps, Entra and Azure instead of handing back three disconnected checklists. Ask for a sample report that maps who could trigger a connection, what the identity could change, how the tester validated the boundary and who can fix it. Request a retest after permissions or approvals change. The final report should be suitable for engineering action and for evidence in an enterprise security review without exposing secret material.
Stingrai is a global CREST-accredited penetration testing services company, incorporated in 2021 and based in Toronto, Canada. Its human-led Azure and Entra cloud testing can follow identity and control-plane paths across the systems in scope. Two named penetration testers work on each human-led engagement, with findings posted as they are confirmed and retesting of remediated findings included. Stingrai supports both one-time tests and continuous programs. An assessment can support a buyer's SOC 2 or ISO 27001 program by producing test evidence; it does not replace the buyer's own control ownership.
A phased validation checklist
Inventory the bridge. List representative pipelines, service connections, authentication methods, identities, Azure roles and environment owners. Mark the exact sample and the untested population.
Review authorization. Identify who can edit or invoke each pipeline, which pipelines can use the connection, and who can change approvals. Reconcile broad permissions with documented business needs.
Exercise bounded paths. Use test identities and harmless test resources to validate denied and allowed cases under written rules of engagement. Correlate DevOps run records, approval decisions and Azure activity.
Fix and retest. Narrow pipeline grants, identity roles or federation mappings as appropriate. Repeat the same benign scenarios and preserve before-and-after evidence.
The deliverable should say what was tested and what was inferred. A correctly configured connection for one application says nothing about a different project, a shared deployment identity or a separate tenant. Sampling limits belong in the executive summary, not only in an appendix.
Frequently Asked Questions
What is the security risk of an Azure DevOps service connection?
A service connection lets a pipeline act on Azure resources through an identity. Risk depends on who can change or run that pipeline, which pipelines can use the connection, what the identity can do in Azure and what approvals intervene. A security assessment follows that complete path and verifies representative allowed and denied cases.
Should Azure DevOps service connections use workload identity federation?
Microsoft recommends workload identity federation with an app registration or managed identity because it avoids stored connection secrets. An assessment should also verify the federation mapping, pipeline authorization and Azure role scope. “Secretless” alone does not establish least privilege.
Is granting a service connection to all pipelines safe?
Microsoft says the all-pipelines grant is not recommended and advises authorizing individual pipelines. Review any exception against who can create or edit pipelines in that project and what the connection identity can change. The observed permission path, rather than a setting in isolation, determines the finding.
Does a service connection assessment need production access?
Most authorization questions can be tested with read-only configuration evidence and benign operations on designated test resources. Production access may be useful for reviewing approvals and role scope, but the rules of engagement should bound any action that could alter a live deployment.
What should the final report prove?
It should map each tested pipeline to its connection, identity, effective Azure role and approval path. For every finding it should show the observed permission path, its business impact, the owner of the fix and a retest result. It should not include secret values.
Related reading
References
Microsoft. Connect to Azure with an Azure Resource Manager service connection. Accessed 21 October 2026. Authentication options and pipeline authorization.
Microsoft. Security considerations for DevOps platforms. Accessed 21 October 2026. Connection separation, approvals and federation scope.
Talk to Stingrai
For a scoped test of your Azure DevOps to Entra to Azure deployment path, get a quote or book a free discovery call. Name the projects, connections and environments you want represented.
