IaC Coverage

Expanded Definition

IaC Coverage measures how much of an environment is provisioned and changed through infrastructure as code rather than by console clicks or ad hoc scripts. In NHI security, the metric matters because cloud infrastructure, identity bindings, secrets distribution, and policy attachments often determine whether an AI Agent or service account can act safely. Higher coverage usually means changes are versioned, reviewable, and repeatable, which strengthens governance and makes drift easier to detect. Lower coverage creates a gap between what is documented and what actually exists, especially when teams create exceptions for urgent production fixes. That gap is where identity sprawl, weak entitlement reviews, and unmanaged secrets tend to accumulate. NIST guidance on configuration and change control in NIST SP 800-53 Rev 5 Security and Privacy Controls provides the closest control context, but no single standard yet defines IaC Coverage as a universal metric. The most common misapplication is counting any script as IaC, which occurs when teams treat one-off deployment commands as managed, reviewable infrastructure definitions.

NHIMG research on the Ultimate Guide to NHIs shows how often identity risk is hidden in weak governance patterns, which is exactly why IaC Coverage is more than a DevOps vanity metric.

Examples and Use Cases

Implementing IaC Coverage rigorously often introduces process overhead, requiring organisations to weigh faster emergency changes against stronger control and traceability.

• A platform team provisions service account bindings, network rules, and secret store references through Terraform, so every NHI-related change is reviewed before deployment.
• A security team measures what share of Kubernetes namespaces, workload identities, and policy objects were created from Git-managed templates versus manual edits.
• An engineering org identifies that production databases were created by hand, then converts them into declarative modules to reduce drift and support NIST SP 800-53 Rev 5 Security and Privacy Controls alignment.
• An incident response team uses IaC logs to verify when a new API gateway permission was added, then compares the change against the approved pipeline in the Ultimate Guide to NHIs.
• A cloud governance group excludes personal sandboxes from the numerator to avoid overstating coverage, because only production-relevant managed resources should count toward the metric.

Why It Matters in NHI Security

IaC Coverage is a practical signal of whether NHI controls are enforceable or merely aspirational. When identity bindings, secret references, and runtime permissions are created outside code, reviewers lose visibility into who changed what, when, and why. That creates fertile ground for standing access, orphaned service accounts, and secrets left in undocumented locations. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, and only 5.7% have full visibility into their service accounts, which makes poor IaC Coverage a direct governance concern. The broader NHI problem set documented in the Ultimate Guide to NHIs also shows why manual provisioning undermines Zero Trust assumptions and weakens auditability. Organisations that want measurable control over NHI sprawl need infrastructure definitions to be the default, not the exception. Organisations typically encounter the consequences only after a drift event, privileged access review, or secrets exposure, at which point IaC Coverage becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What do security teams get wrong about IaC coverage?
• When do IAST and RASP create a false sense of coverage for NHIs?
• Should organisations prioritise least privilege or broad platform coverage first?
• How do you know if passwordless coverage is actually enterprise-wide?