Terraform Apply is the execution phase where planned infrastructure changes are written into the target environment. It can create, update, or delete resources, so organisations need guardrails around this step to stop destructive outcomes that were not intended by the person making the change.
Expanded Definition
Terraform Apply is the moment when desired-state infrastructure code becomes real infrastructure changes. In NHI and IAM operations, that means the apply step can create service accounts, rotate secrets, attach policies, or delete resources that underpin machine access. The distinction matters because planning is advisory, while apply is authoritative and can affect production immediately. In governance terms, Terraform Apply is not just a deployment action; it is a control point where change approval, policy checks, and execution identity all intersect.
Definitions vary across vendors on how much policy enforcement should happen before apply versus during execution, but the core risk is consistent: the runner often has broader permissions than the change author. NIST’s NIST Cybersecurity Framework 2.0 supports treating this as a governed change activity, not a routine command. In NHI-managed environments, apply should be constrained by least privilege, scoped credentials, and reviewable change records, especially when secrets or identity bindings are involved.
The most common misapplication is allowing an unattended pipeline to run apply with production-level privileges when the plan was reviewed only by a developer.
Examples and Use Cases
Implementing Terraform Apply rigorously often introduces delivery friction, requiring organisations to weigh deployment speed against the cost of stronger approvals and tighter execution identity.
- A platform team applies a change that creates a new service account and binds it to a workload, with the apply job using a short-lived identity instead of a long-lived token.
- A security team requires policy-as-code checks before apply so that secret references cannot be written into versioned configuration files, aligning with guidance in the Ultimate Guide to NHIs.
- A CI/CD runner performs apply only after human approval, because a resource replacement could delete an existing API key and interrupt an automated integration.
- An operations team uses apply to rotate credentials across multiple environments, following the NHI lifecycle and rotation principles described in the Ultimate Guide to NHIs.
- A cloud security engineer compares the planned change against NIST Cybersecurity Framework 2.0 governance expectations before allowing production apply.
Why It Matters in NHI Security
Apply is where hidden NHI weaknesses become incidents. A mis-scoped execution role, an unmanaged secret, or an overbroad resource replacement can expose service accounts, break automation, or create standing privileges that were never intended. NHIMG research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, and that reality makes apply controls especially important because the execution path often inherits those privileges at the exact moment infrastructure is rewritten.
For practitioners, the key question is not whether Terraform is used, but who can apply, with what identity, against which environment, and under what approval model. A safe plan can still become a dangerous change if the apply runner can reach secrets stores, IAM policy documents, or production namespaces without guardrails. This is why apply should be paired with scoped credentials, audit logging, separation of duties, and rollback design. Organisations typically encounter destructive infrastructure drift, leaked secrets, or broken machine access only after a failed deployment, at which point Terraform Apply 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Apply is the control point where overprivileged NHIs can create or alter sensitive access paths. |
| NIST CSF 2.0 | PR.AC-4 | Apply depends on enforcing least privilege for the identity executing the change. |
| NIST Zero Trust (SP 800-207) | SC-7 | Apply should operate as a trust-minimized action with environment and identity checks. |
| NIST SP 800-63 | IAL2 | Human approval behind apply workflows should be tied to trusted identity assurance. |
| OWASP Agentic AI Top 10 | LLM-04 | Autonomous agents that trigger apply can amplify unsafe tool use and execution risk. |
Restrict apply credentials, validate change scope, and prevent privilege escalation during infrastructure execution.
