How should security teams measure IaC coverage across Azure subscriptions and regions?

Security teams should measure IaC coverage by comparing managed resources against the full Azure estate, then break results down by subscription, region, resource type, and tool ownership. That view shows where drift, shadow resources, or inconsistent deployment patterns are building risk. The key is to track coverage over time, not just at a point in time, so governance teams can see whether control adoption is improving.

Why This Matters for Security Teams

iac coverage is not just a delivery metric. It is a control-coverage signal for Azure estates that often drift across subscriptions, regions, and deployment teams. When a resource is created outside code, it usually bypasses guardrails for tagging, logging, encryption, and access policy. That makes coverage gaps a practical exposure measure, not a maturity vanity metric. NIST frames configuration and change control as core security functions in NIST SP 800-53 Rev 5 Security and Privacy Controls.

This is especially important in Azure because a single “managed vs unmanaged” percentage can hide serious blind spots. One subscription may be fully codified while another region is being used for urgent exceptions, disaster recovery testing, or vendor-led workarounds. NHIMG has repeatedly shown that visibility gaps and weak control discipline are what turn identity and configuration issues into breaches, including in incidents such as Storm-2949 Azure Breach and Azure Key Vault privilege escalation exposure. In practice, many security teams discover coverage gaps only after a review, audit, or incident reveals resources nobody expected to exist.

How It Works in Practice

Measure IaC coverage by building a complete Azure inventory first, then comparing that inventory to the set of resources managed through approved pipelines, templates, and policy-controlled deployment paths. The denominator matters: if discovery misses subscriptions, resource groups, or regions, the coverage number will look better than reality. Current guidance suggests breaking the analysis down by subscription, region, resource type, and deployment owner so teams can see where unmanaged growth is concentrated.

A practical model usually includes:

• All Azure subscriptions, including sandbox, shared services, DR, and acquired-environment subscriptions.

• All regions in scope, because teams often codify primary regions first and leave secondary regions behind.

• Resource-type segmentation, since some services are routinely managed in code while others are created manually during incident response or experimentation.

• Ownership mapping, so security teams can distinguish platform-managed resources from application team exceptions and third-party deployments.

For implementation, tie deployment evidence back to source-of-truth artifacts such as repository history, pipeline runs, and policy assignments, then reconcile them with cloud discovery data. Azure Policy can help enforce preferred patterns, but policy compliance is not the same as IaC coverage. A resource may satisfy a policy after creation and still be unmanaged. For control design, this distinction aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where configuration management and continuous monitoring are required.

NHIMG’s broader research on the Ultimate Guide to NHIs shows why this matters operationally: unmanaged secrets, service accounts, and cloud-native resources tend to accumulate where ownership is unclear and automation is incomplete. Coverage reporting should therefore be time-series based, not a single audit snapshot. These controls tend to break down in highly federated Azure environments where local teams can create resources faster than central inventory and policy processes can reconcile them.

Common Variations and Edge Cases

Tighter IaC enforcement often increases operational overhead, requiring organisations to balance standardisation against emergency speed, regional autonomy, and platform complexity. That tradeoff shows up most clearly in Azure subscriptions used for incident response, proof-of-concept work, and regulated workloads that have special residency requirements. Best practice is evolving here, because there is no universal standard for how to score partial coverage when exceptions are legitimate but temporary.

A few edge cases deserve explicit treatment:

• Legacy estates: older subscriptions may contain long-lived resources that were never intended to be codified. Treat them as remediation candidates, not proof that IaC is optional.

• Ephemeral environments: short-lived test or CI resources can inflate unmanaged counts if discovery lags behind teardown.

• Multi-team ownership: shared platform resources may be managed in one repo while workload-specific resources live elsewhere, so coverage must be deduplicated carefully.

• Region-specific exceptions: sovereign cloud regions, DR regions, and data residency zones often have unique deployment patterns that distort fleet-wide averages.

For practitioners, the useful question is not whether a subscription is “mostly covered,” but whether unmanaged resources are concentrated in risky categories such as network exposure, identity, key management, or data services. That is why NHIMG case research, including Microsoft Azure Key Breach and Microsoft SAS Key Breach, is useful: it shows how a small number of unmanaged or weakly governed resources can create outsized exposure. In practice, the hardest cases are the subscriptions that look compliant at the platform layer but still allow one-off manual creation through shadow processes.

Related resources from NHI Mgmt Group

• How should security teams govern Azure environments across many subscriptions without creating manual onboarding bottlenecks?
• What do security teams get wrong about scaling identity controls across regions and channels?
• How should security teams make NHI best practices usable across the business?
• How should security teams keep SaaS application data accurate across discovery, mapping, and reporting?