A broken apply is a failed or unreliable infrastructure deployment caused by conflicting configuration, invalid state, or contradictory resource ownership. In Terraform, duplicate definitions can trigger this condition when the platform cannot reconcile which code path should control the target resource.
Expanded Definition
A broken apply is a deployment failure mode in infrastructure-as-code where the tool cannot produce a single, authoritative change set because configuration, state, or ownership conflicts prevent reconciliation. In Terraform, this often appears when duplicate resource definitions, stale state, or competing modules all claim control of the same object. The result is not merely a syntax error, but an unreliable delivery process that can leave infrastructure partially changed, rolled back, or blocked from future updates.
In NHI operations, broken apply matters because the same ambiguity that affects infrastructure resources can also affect the service accounts, secrets, and permissions used to deploy them. Industry usage is still evolving, but the practical distinction is clear: broken apply describes a control-plane failure to converge, while a routine plan diff describes an expected change. The most common misapplication is treating broken apply as a harmless deployment nuisance, which occurs when teams retry the pipeline without resolving conflicting ownership or corrupted state.
For baseline guidance on governance and identity control, NHI Management Group recommends pairing deployment discipline with broader identity visibility, as outlined in Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.
Examples and Use Cases
Implementing Terraform rigorously often introduces state and ownership constraints, requiring organisations to weigh deployment speed against the discipline needed to keep one resource under one source of truth.
- A module and a root stack both declare the same cloud role, so Terraform cannot determine which code path owns the final permissions set.
- Two CI/CD pipelines run against the same workspace, one with outdated state and one with current state, causing conflicting updates during apply.
- A service account secret is rotated outside the deployment process, but the state file still references the prior value, so the apply fails when reconciling live and declared configuration.
- An imported resource is later redefined in code without removing the original binding, creating duplicate ownership and an irreconcilable plan.
- Teams can compare this failure pattern with broader identity and secret exposure trends documented in Ultimate Guide to NHIs, while NIST Cybersecurity Framework 2.0 helps frame the operational need for controlled change and recovery.
In practice, broken apply is often discovered during routine delivery of NHI-related infrastructure such as secret managers, identity bindings, or CI/CD permissions, where ownership ambiguity is especially risky.
Why It Matters in NHI Security
Broken apply becomes a security issue when deployment instability affects credentials, access policies, or the infrastructure that governs non-human identities. If a pipeline cannot reliably create, rotate, or revoke secrets and entitlements, teams may leave privileged access in place longer than intended or reintroduce outdated configurations after a partial failure. That is a direct governance problem, not just an engineering inconvenience.
The scale of the NHI challenge makes this especially important: NHI Management Group reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. A broken apply in that environment can freeze remediation, delay rotation, or overwrite a corrective change with stale state. When a deployment system cannot prove which identity owns a resource, trust in the rollout path collapses.
Practitioners typically encounter the consequence only after a failed rotation, an access incident, or a halted release, at which point broken 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 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 | Broken apply often stems from ambiguous ownership and unsafe deployment flows. |
| NIST CSF 2.0 | PR.IP-1 | Controlled change management is central when applies can fail or partially converge. |
| NIST Zero Trust (SP 800-207) | SC-31 | Zero Trust assumes tightly governed resource access and change paths. |
| NIST SP 800-63 | AAL2 | Strong authenticator assurance helps protect privileged automation used in deployments. |
| NIST AI RMF | GOVERN | Governance is needed when autonomous or automated changes can fail unpredictably. |
Limit deployment authority to authenticated, least-privilege workflows with explicit resource trust boundaries.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
