They often treat IaC as a tool purchase instead of a control boundary. IaC only reduces risk when it is the enforced path for provisioning and change. If anyone can bypass the pipeline, code describes the desired state while the real environment drifts away from it.
Why This Matters for Security Teams
Infrastructure as code is often framed as a speed and consistency improvement, but the security failure mode is simpler: when IaC is not the only path to change, it becomes documentation rather than enforcement. That gap matters because drift, shadow changes, and emergency console edits quietly create a second control plane. Current guidance from the NIST Cybersecurity Framework 2.0 still points teams toward governed change and continuous monitoring, which only works when the declared state is the enforced state.
NHIMG’s Ultimate Guide to NHIs shows why this gets worse in modern environments: NHIs outnumber human identities by 25x to 50x, and 97% carry excessive privileges. In practice, teams do not discover the risk at design time. They discover it after a privileged deployment path, leaked secret, or manual override has already made drift operationally real.
How It Works in Practice
Effective IaC governance is less about choosing Terraform, Pulumi, or another tool and more about making every meaningful infrastructure change pass through versioned, reviewable, policy-checked pipelines. That means the repository is authoritative, plan output is inspected, and the apply step is gated by controls that block unsafe deltas. IaC only reduces risk when teams treat it as a control boundary, not a convenience layer.
Practically, that boundary usually includes:
- One approved provisioning path for each environment, with console changes treated as exceptions.
- Policy as code to reject insecure resources, overly permissive IAM, open network exposure, or missing tagging.
- Immutable change records so auditors can compare requested, approved, and applied state.
- Secret handling outside source control, with short-lived tokens instead of long-lived static credentials.
- Continuous drift detection to flag when actual configuration diverges from the committed template.
This is also where NHI management becomes inseparable from IaC. If pipelines store API keys in code or use persistent service account credentials, the infrastructure may be reproducible but still unsafe. NHIMG’s Ultimate Guide to NHIs notes that 30.9% of organisations store long-term credentials directly in code, which means IaC can amplify exposure unless secret lifecycle is controlled alongside provisioning.
Best practice is evolving toward ephemeral credentials, workload identity, and policy evaluation at request time rather than trusting a once-reviewed template forever. These controls tend to break down in hybrid environments where teams keep manual break-glass access for “temporary” fixes that never get reconciled back into code.
Common Variations and Edge Cases
Tighter IaC enforcement often increases delivery friction, requiring organisations to balance change velocity against the need to eliminate bypass paths. That tradeoff is real, especially in legacy estates where not every platform can be fully codified on day one. Current guidance suggests focusing first on the highest-risk assets, then expanding coverage as operational discipline matures.
There is no universal standard for this yet, but several edge cases appear repeatedly. Ephemeral test environments may tolerate lighter controls if they are isolated and short-lived, while regulated or internet-facing systems need stricter approvals and stronger drift monitoring. Teams also need to distinguish between declarative infrastructure and procedural changes such as database migrations, certificate rotation, and IAM exception handling, which often sit outside the IaC tool itself.
The other common mistake is assuming plan review alone is enough. A clean plan does not prevent someone with console access from changing production directly, and it does not stop a compromised automation identity from applying malicious code. For that reason, IaC should be paired with identity governance, immutable logging, and access restriction on both humans and non-human identities.
In mature environments, the question is not whether IaC exists, but whether anything important can still happen without it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP | IaC is a governed change process, not just tooling. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static secrets in IaC often become long-lived NHI exposure. |
| NIST AI RMF | GOVERN | Automated infrastructure changes need explicit accountability and oversight. |
Assign ownership, approval, and monitoring for any autonomous infrastructure change path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
