A governance model where certain infrastructure resources can only be created through approved Terraform modules. It centralises security defaults, tagging, and compliance settings so that every deployment inherits the same baseline controls and cannot silently diverge through raw resource definitions.
Expanded Definition
Module-only provisioning is a governance control that narrows infrastructure creation to approved Terraform modules, so security defaults, labels, encryption settings, and access patterns are applied consistently. In NHI and cloud operations, it is less about Terraform as a tool and more about enforcing a single, reviewable path for provisioning.
That distinction matters because raw resource definitions often bypass guardrails that modules can encode, such as secret handling, logging, network restrictions, and standard tags for ownership and rotation. In practice, module-only provisioning sits alongside broader controls in the NIST Cybersecurity Framework 2.0, especially where secure configuration and change control are expected.
Definitions vary across vendors and platform teams on how strict the restriction must be. Some organisations treat it as a hard policy enforcement layer, while others allow exceptions for break-glass infrastructure or specialised services. The most common misapplication is assuming a shared Terraform library is enough, which occurs when teams can still create unmanaged resources outside the approved module path.
Examples and Use Cases
Implementing module-only provisioning rigorously often introduces delivery friction, requiring organisations to weigh deployment speed against stronger configuration consistency.
- A platform team publishes a vetted module for service accounts, ensuring every new account inherits rotation hooks, least-privilege defaults, and standard ownership tags.
- A data platform exposes only approved storage modules so every bucket or volume is created with encryption, logging, and restricted public access by default.
- An application team must provision secrets-backed workloads through a module that wires in approved identity bindings rather than ad hoc YAML or console-based setup.
- Security reviewers use the NHI Lifecycle Management Guide to align module templates with onboarding, rotation, and offboarding requirements for NHIs.
- Teams compare module enforcement against the Ultimate Guide to NHIs when deciding where provisioning controls should sit in the delivery pipeline.
Why It Matters in NHI Security
Module-only provisioning helps stop NHI sprawl before it starts. If engineers can create raw infrastructure directly, service accounts, API key locations, vault integrations, and audit settings can diverge silently, making later remediation expensive and incomplete. That matters because NHIs already outnumber human identities by 25x to 50x in modern enterprises, and visibility gaps often compound when provisioning is inconsistent.
For NHI security governance, this control reduces the chance that a new workload is launched with long-lived credentials, missing tags, or weak network boundaries. It also supports standardisation across teams, which is important when incident response needs to identify ownership and revoke access quickly. The Top 10 NHI Issues highlights how provisioning drift often becomes an access and lifecycle problem later, not just a DevOps preference.
Organisations typically encounter module-only provisioning as an urgent requirement only after an unmanaged resource is discovered during an audit, at which point the control 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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Module-only provisioning reduces unmanaged NHI creation paths and enforces approved control baselines. |
| NIST CSF 2.0 | PR.AC-4 | Access and configuration control support least-privilege and approved-change principles. |
| NIST Zero Trust (SP 800-207) | Zero Trust relies on consistent, policy-driven resource provisioning and control enforcement. |
Force NHI-related infrastructure through approved modules so every deployment inherits secure defaults.
Related resources from NHI Mgmt Group
- What is the difference between just-in-time provisioning and just-in-time access?
- What is the difference between access certification and provisioning?
- What is the difference between onboarding access and NHI provisioning?
- What is the difference between access recertification and access provisioning?
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
