Organisations should block non-module Terraform resource creation for resource types where standardisation, tagging, and security settings are mandatory. If a team needs an exception, it should be explicit, reviewed, and monitored. The point is not to eliminate flexibility everywhere, but to prevent uncontrolled parallel provisioning paths.
Why This Matters for Security Teams
Terraform is supposed to make infrastructure repeatable, reviewable, and policy-driven. When teams allow direct, non-module resource creation, they create a second provisioning path that bypasses standard tagging, baseline encryption, network guardrails, and approval logic. That is not just an IaC style issue; it becomes an identity and governance issue because resource ownership, drift control, and exception handling all become inconsistent.
This is especially risky in environments that already struggle with hidden access paths and unmanaged credentials. NHI Management Group notes that 97% of NHIs carry excessive privileges, and 96% of organisations store secrets outside secrets managers in vulnerable locations, which shows how quickly parallel paths become control failures. The same pattern appears in infra provisioning: once a direct path is available, it tends to spread faster than the controls designed to contain it. See the broader governance framing in the Ultimate Guide to NHIs and the control baseline in NIST Cybersecurity Framework 2.0.
In practice, many security teams encounter mis-tagged, unreviewed, or over-permissioned resources only after an audit, cost spike, or incident has already exposed the uncontrolled provisioning path.
How It Works in Practice
The practical answer is not “block everything” or “allow everything.” Organisations should block direct creation for resource classes that require mandatory security, naming, tagging, encryption, or network controls, then route those changes through approved modules. That gives security and platform teams a single place to encode policy while still leaving room for exceptions where the business genuinely needs them.
A workable pattern usually includes:
- Approved Terraform modules as the default path for standard workloads.
- Policy-as-code checks in CI/CD to reject direct resources for protected types.
- Exception workflows that are time-bound, owned, and logged.
- Drift detection to find resources created outside the module pathway.
- Mandatory metadata, such as owner, environment, data classification, and cost centre.
This aligns with the control logic described in the ASP.NET machine keys RCE attack, where weak lifecycle discipline around sensitive configuration created lasting exposure, and with NIST’s guidance that security outcomes depend on repeatable, auditable processes rather than ad hoc action. In Terraform terms, the module is not just code reuse. It is the enforcement point for approved defaults, least privilege, and consistent change records. The NIST Cybersecurity Framework 2.0 reinforces that governance must be operationalised, not assumed.
These controls tend to break down in fast-moving platform teams where application squads can merge directly to production through separate pipelines because policy enforcement is fragmented across repositories, clouds, and approvals.
Common Variations and Edge Cases
Tighter module enforcement often increases platform overhead, requiring organisations to balance consistency against developer speed and legitimate workload diversity. That tradeoff is real, especially when teams are standardising across multiple clouds, legacy estates, or third-party managed services.
Best practice is evolving on where to draw the line. There is no universal standard for blocking every direct resource forever. Current guidance suggests focusing first on high-risk resource types: IAM bindings, security groups, databases, storage, key management, and anything that can expose data or create lateral movement. Lower-risk, low-impact resources may be left open temporarily if there is a compensating review process.
Edge cases also matter. Some teams need one-off resources for incident response, vendor integrations, or experiments. Those should not become informal exceptions. They should be explicitly approved, tagged as temporary, and tracked back into a module or decommissioned. That mirrors the broader NHI governance lesson in the Ultimate Guide to NHIs: unmanaged exceptions become durable risk. Where policy is too rigid, engineering workarounds emerge; where policy is too loose, parallel provisioning becomes the norm.
The right decision is usually selective blocking plus enforced exceptions, not blanket prohibition across every Terraform resource type.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Direct provisioning paths often hide unmanaged secrets and privileges. |
| NIST CSF 2.0 | PR.AC-4 | Access and change paths need least-privilege, auditable enforcement. |
| NIST AI RMF | Governance should make infrastructure change decisions traceable and accountable. |
Force approved modules to standardise identity, tagging, and secret handling for each Terraform-managed resource.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
