Should organisations separate secret storage from infrastructure deployment identities?

Yes. Separation reduces the blast radius of automation credentials and prevents a single machine identity from both creating and consuming secrets across environments. That design supports least privilege, makes access reviews clearer, and limits what a compromised deployment principal can reach.

Why This Matters for Security Teams

Separating secret storage from infrastructure deployment identities is a basic control with outsized impact because deployment principals are often the most dangerous automation accounts in the environment. If the same identity can both provision infrastructure and read long-lived secrets, a single compromise can turn a build pipeline or IaC runner into a path to production access. That is exactly the kind of secret sprawl problem NHI Management Group warns about in the Guide to the Secret Sprawl Challenge.

The practical risk is not theoretical. NHIMG’s Ultimate Guide to NHIs reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 80% of identity breaches involve compromised non-human identities. For security teams, separation creates a clearer trust boundary, makes least privilege measurable, and forces deliberate access paths instead of implicit reuse. It also aligns with the direction of the OWASP Non-Human Identity Top 10, which treats excessive privilege and secret exposure as recurring failure modes. In practice, many security teams discover this problem only after a deployment identity has already been used to harvest secrets across multiple environments.

How It Works in Practice

The cleanest pattern is to give the infrastructure deployment identity permission to create, update, and destroy infrastructure, but not to read application secrets directly. Secret storage should live behind a separate control plane, such as a secrets manager or vault, with its own access policy and audit trail. The deployment workflow can then request only the minimum secret access it needs, ideally through short-lived, task-scoped credentials rather than reusable static tokens. That is consistent with current best practice guidance in the OWASP Non-Human Identity Top 10 and with NHIMG’s analysis of static versus dynamic secret in the Ultimate Guide to NHIs.

• Use one identity for deployment actions and a different identity for secret retrieval.
• Scope secret access to a specific environment, application, or deployment stage.
• Issue just-in-time credentials with short TTLs, then revoke them after the task completes.
• Log every secret read separately from infrastructure changes so reviews can distinguish provisioning from consumption.
• Prefer workload identity and policy evaluation at request time over embedded long-lived keys.

This separation is especially important when CI/CD pipelines, IaC runners, or agentic automation can chain actions across tools, because one compromised principal should not be able to bootstrap both infrastructure changes and secret exfiltration. It also supports tighter incident response, since responders can revoke deployment access without immediately breaking all secret consumers. These controls tend to break down when legacy pipelines depend on shared service accounts and hard-coded environment variables, because the same credential is then reused across build, deploy, and runtime stages.

Common Variations and Edge Cases

Tighter separation often increases operational overhead, requiring organisations to balance blast-radius reduction against pipeline complexity and secret provisioning latency. In mature environments, that tradeoff is worth it; in smaller environments, teams may need to phase the model in by protecting only production and high-value secrets first. There is no universal standard for this yet, but guidance is converging on short-lived, context-aware access rather than static shared secrets.

One common exception is a bootstrap path, where an initial deployment identity must create the first secret store or rotate an initial credential set. That should be tightly time-boxed and monitored. Another edge case is multi-account or multi-cluster automation, where a single orchestration system needs broad infrastructure reach but should still be blocked from direct secret reads. In those cases, separate trust domains and policy-as-code help preserve the split without manual exceptions.

NHIMG’s CI/CD pipeline exploitation case study and Shai Hulud npm malware campaign both illustrate why shared deployment identities are attractive targets: once an attacker reaches the automation layer, secret reuse multiplies impact quickly. The rule of thumb is simple: if a deployment principal can both change infrastructure and read secrets, the boundary is already too weak.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?
• Why do non-human identities complicate zero trust architecture?