They often treat coverage as a DevOps efficiency measure rather than a control-plane visibility measure. That mistake matters because the security value comes from what code makes governable, not from how quickly infrastructure can be deployed. If coverage is low, the organisation is accepting a larger unmanaged attack and audit surface.
Why This Matters for Security Teams
IaC coverage is not a deployment metric; it is a visibility metric for the control plane. When security teams confuse those two, they measure how much infrastructure can be provisioned from code instead of how much of the live environment is governed, reviewable, and enforceable. That creates blind spots in identity, network, storage, and secrets exposure, especially when teams rely on manual changes outside the repository.
NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a strong reminder that configuration coverage and identity coverage are tightly linked. The same problem appears in broader governance guidance such as the NIST Cybersecurity Framework 2.0, where visibility and control monitoring are treated as operational requirements, not documentation exercises.
Security teams also get tripped up by the assumption that every asset created by code is therefore controlled by code. In reality, drift, console-side edits, unmanaged modules, and copied templates can all expand the attack surface without changing the apparent IaC footprint. In practice, many security teams encounter unmanaged access only after a policy exception, audit finding, or incident has already exposed the gap.
How It Works in Practice
Strong IaC coverage means answering a specific question: what percentage of the production control surface is defined, reviewed, and enforced through code and policy, versus created or altered elsewhere? That includes cloud accounts, identity bindings, security groups, routing, encryption settings, secret references, and the pipeline rules that approve changes. For modern environments, coverage also extends to the non-human identities that IaC provisions or depends on, because service accounts and tokens are often the real control points.
A practical model usually combines four checks:
- Repository coverage: the percentage of known infrastructure components represented in version-controlled code.
- Policy coverage: whether guardrails are evaluated on every change, not only in pre-deploy scanning.
- Runtime coverage: whether live assets are continuously compared against approved desired state.
- Identity coverage: whether secrets, roles, and service accounts created by IaC are inventoried and governed.
That last point matters because unmanaged identities are frequently the path through which IaC drift becomes a real incident. The Ultimate Guide to NHIs highlights how often secrets live outside proper managers and how rarely organisations fully track service-account scope, which turns partial IaC adoption into partial security control. This is where NIST Cybersecurity Framework 2.0 style governance is useful: it pushes teams to treat visibility, control mapping, and continuous assessment as part of the control objective itself.
In mature programmes, IaC coverage is measured alongside drift detection, exception handling, and change provenance. Best practice is evolving toward policy-as-code and continuous reconciliation, but there is no universal standard for a single coverage formula yet. These controls tend to break down when large portions of infrastructure are provisioned through consoles, managed services, or ad hoc emergency changes because the repository no longer represents the authoritative state.
Common Variations and Edge Cases
Tighter IaC coverage often increases delivery overhead, requiring organisations to balance governance depth against developer friction and platform complexity. That tradeoff is real, especially in fast-moving cloud environments where not every managed service can be expressed cleanly as code.
One common edge case is brownfield infrastructure. A team may have strong IaC for new workloads but limited coverage for legacy networks, inherited accounts, or acquisitions. Another is platform abstraction: internal developer platforms can improve standardisation while hiding the true control surface, which makes coverage look better than it is unless the underlying policies and identities are also mapped.
Coverage can also be misleading when code exists but is not authoritative. Templates copied between teams, stale modules, and one-off overrides in the console create a false sense of control. The security question is not whether code exists, but whether code is the governing source for both configuration and identity. This is why the gap described in the Ultimate Guide to NHIs matters so much in practice: unmanaged secrets and service accounts often sit outside the same review process as infrastructure definitions, even when the platform itself looks well covered.
Current guidance suggests treating coverage as a risk segmentation problem. High-value environments should aim for near-complete coverage and continuous drift control, while lower-risk zones may accept documented exceptions. The important point is that every exception should be explicit, time-bounded, and reviewed, because silent exceptions are where IaC coverage becomes an audit illusion.
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 | ID.AM-1 | Asset inventory coverage is central to defining IaC control-plane visibility. |
| OWASP Non-Human Identity Top 10 | NHI-01 | IaC often provisions NHIs, so incomplete coverage leaves credentials and service accounts unmanaged. |
| NIST AI RMF | Governance and monitoring principles fit runtime reconciliation and exception management. |
Map every governed cloud asset and identity to an inventory and reconcile IaC against it continuously.
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
