A Terraform module is a reusable package of infrastructure code that groups related resources and settings into a shared pattern. Modules help teams standardise secure defaults, reduce repetition, and apply governance consistently across projects, accounts, and environments without rebuilding the same controls each time.
Expanded Definition
A Terraform module is a composable unit of infrastructure as code that packages related resources, variables, outputs, and logic into a reusable pattern. In NHI and IAM work, modules matter because they let teams standardise identity-related infrastructure such as secret storage, policy bindings, workload identity wiring, and network controls across many environments.
Usage in the industry is still evolving, especially where module boundaries overlap with platform engineering, policy-as-code, and golden-path templates. A module is not the same as a full landing zone, and it is not a control by itself. It becomes governance-relevant when it encodes secure defaults, prevents ad hoc configuration drift, and supports repeatable deployment of identity-sensitive components. For broader risk framing, the NIST Cybersecurity Framework 2.0 remains useful because modules often implement the preventive and configuration management practices that CSF expects at scale. The most common misapplication is treating a module as inherently secure, which occurs when teams reuse it without reviewing variables, provider permissions, and downstream inheritance.
Examples and Use Cases
Implementing Terraform modules rigorously often introduces versioning and dependency constraints, requiring organisations to weigh standardisation benefits against the cost of controlled change management.
- A security team publishes a module for cloud secret storage so every project uses the same encryption, access policy, and logging settings.
- A platform team wraps service account creation into a module that also provisions least-privilege roles and scoped workload access.
- A compliance team uses a shared module for audit logging to ensure identity-relevant events are captured consistently across accounts.
- An engineering org separates base network controls from application modules so teams can move faster without bypassing central guardrails.
- A governance team reviews module code before release to prevent insecure defaults from propagating into multiple environments.
For identity-specific operational patterns, the Ultimate Guide to NHIs is especially relevant because modules often shape how secrets, rotations, and access paths are deployed. Where reusable infrastructure touches trust boundaries, NIST Cybersecurity Framework 2.0 helps translate that reuse into repeatable governance outcomes.
Why It Matters in NHI Security
Terraform modules are a major control point for NHI security because many of the failures that affect service accounts, API keys, and workload identities begin in infrastructure templates, not in runtime systems. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 97% of NHIs carry excessive privileges, which means module design directly influences whether those risks are multiplied or reduced. When modules enforce secure defaults, they reduce secret sprawl, privilege creep, and inconsistent access provisioning.
Modules also shape operational resilience. The Ultimate Guide to NHIs highlights that only 20% of organisations have formal processes for offboarding and revoking API keys, so module-driven workflows can help make revocation, rotation, and logging consistent enough to automate. In practice, this matters when teams inherit infrastructure at scale and discover that each application team implemented identity controls differently. Organisations typically encounter module-driven NHI risk only after a secrets leak, privilege abuse, or failed audit, at which point the module standard becomes operationally unavoidable to address.
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, NIST Zero Trust (SP 800-207), NIST SP 800-63 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-01 | Modules often encode secrets handling and access patterns covered by NHI controls. |
| NIST CSF 2.0 | PR.IP-1 | Infrastructure modules operationalize configuration baselines and change control. |
| NIST Zero Trust (SP 800-207) | SC-7 | Modules often implement segmented trust boundaries and policy enforcement needed for Zero Trust. |
| NIST SP 800-63 | AAL2 | Module design can support stronger service identity assurance and credential handling. |
| NIST AI RMF | Modules can govern AI infrastructure components that affect risk management and traceability. |
Review module defaults so identity-related resources are provisioned with secure secrets and least privilege.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
