Notifications
Clear all
Topic starter
08/07/2026 7:07 pm
TL;DR: Azure DevOps pipeline secrets spread across variable groups, YAML, Key Vault, and repo history create scale problems because native controls lack unified inventory, consistent access boundaries, and automated rotation, according to Infisical. The security issue is not storage alone, but unmanaged secrets sprawl that turns routine delivery into an identity governance problem.
NHIMG editorial — based on content published by Infisical: Azure DevOps Secrets Management with Infisical
By the numbers:
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
Questions worth separating out
Q: How should security teams reduce secrets sprawl in Azure DevOps pipelines?
A: Start by inventorying every secret location, including variable groups, YAML, Key Vault references, and repository history.
Q: Why do Azure DevOps pipeline secrets create governance risk at scale?
A: Because static secrets spread across multiple projects and environments become hard to inventory, hard to rotate consistently, and easy to overexpose.
Q: What breaks when secrets are stored in YAML or shared variable groups?
A: Secrets can leak into source control, logs, or multiple pipelines that were never meant to share the same value.
Practitioner guidance
- Map every pipeline secret to an owner and lifecycle state Build an inventory of variable groups, YAML secrets, Key Vault references, and repo-embedded values.
- Move deployment steps to runtime-only secret retrieval Use short-lived token exchange so secrets are fetched during execution and never persisted in Azure DevOps storage.
- Replace personal tokens with machine identities or federation Authenticate non-interactive pipelines with machine identities or OIDC federation instead of employee-owned credentials.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Azure DevOps sync configuration for App Connections, variable groups, and secret paths.
- Pipeline-ready CLI examples for runtime injection, including token exchange and environment scoping.
- Terraform and OpenTofu injection patterns for provider credentials, backend access, and TF_VAR mapping.
- Kubernetes operator deployment details for teams syncing secrets into cluster-native Secret resources.
👉 Read Infisical's Azure DevOps secrets management guide →
Azure DevOps secrets sprawl: what IAM teams need to fix?
Explore further
08/07/2026 7:31 pm
Secrets sprawl, not secret storage, is the real Azure DevOps governance failure. Azure DevOps can store secrets, but it cannot by itself answer the lifecycle questions that matter at scale: where a secret lives, who can use it, and how quickly it is rotated or revoked. That is why pipeline secret handling becomes an identity governance problem once organisations move beyond a handful of builds. Practitioners should judge their current model by inventory and lifecycle visibility, not by whether a field is marked secret.
A few things that frame the scale:
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 91% of former employee tokens remain active after offboarding, showing how lifecycle gaps turn secret exposure into durable access risk.
A question worth separating out:
Q: How do teams decide between Key Vault, runtime injection, and federation?
A: Use persistent storage only when a secret truly must remain available between runs, use runtime injection when the value is needed only during execution, and prefer federation when the platform can issue short-lived identity assertions. The best choice is the one that reduces credential persistence without breaking deployment control.
👉 Read our full editorial: Azure DevOps secrets management is breaking at pipeline scale
