TL;DR: Traditional CI/CD is effective for stateless application delivery, but it breaks down for live cloud infrastructure where state, dependencies, drift, and rollback risk make small changes harder to control, according to ControlMonkey. The governance problem is not pipeline speed, but whether teams can safely manage infrastructure changes with traceability and policy.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on ControlMonkey's blog post: CI/CD delivery models that work for stateless applications fail to govern live cloud infrastructure safely.
Why it matters: It matters because IAM, PAM, and cloud governance teams need traceability, policy enforcement, and drift control around infrastructure changes, not just faster pipelines.
Context
CI/CD works well when software changes can be deployed, tested, and rolled back as discrete artifacts. Cloud infrastructure does not behave that way because it is stateful, interconnected, and live when changes are applied, which means one change can affect security, compliance, or availability in ways a standard pipeline does not fully model.
The governance gap is straightforward: infrastructure delivery needs ownership, policy, drift awareness, and change traceability at the resource level. When teams rely on software-style delivery for infrastructure, they lose the control points needed to manage cloud sprawl, dependency chains, and rollback risk across environments.
Key questions
Q: What breaks when CI/CD is used to manage live cloud infrastructure?
A: CI/CD breaks when it assumes infrastructure behaves like stateless software. Live cloud resources have state, dependencies, and side effects, so even a small change can alter access, compliance, or availability in ways a normal pipeline does not safely capture.
Q: Why do infrastructure changes create more governance risk than app releases?
A: Infrastructure changes can modify security groups, IAM policies, routes, and other live controls immediately. That means the business impact is not limited to a failed deployment, because the change can expose resources, break services, or violate policy before rollback happens.
Q: What are the signs that infrastructure delivery is losing control?
A: Common signs include manual approvals that cannot keep pace, engineers who cannot trace ownership, growing drift between code and live resources, and recurring questions about what changed or why a resource exists. Those are indicators that delivery is no longer governed at the state level.
Q: How do teams keep infrastructure delivery governed at scale?
A: Teams should tie ownership, policy, drift detection, and change review to the infrastructure object itself rather than relying on application-style pipelines alone. That keeps change traceable and makes the delivery process match the operational risk of live cloud environments.
Technical breakdown
Why stateless delivery models fail for cloud infrastructure
Stateless delivery assumes the target can be replaced cleanly, validated independently, and rolled back without side effects. Infrastructure is different because security groups, IAM policies, route tables, and dependencies between services create a live state that cannot be treated as disposable code. A configuration change can alter access paths, compliance posture, or service availability immediately. That is why CI/CD success for application code does not translate into safe infrastructure delivery. The issue is not simply deployment automation; it is whether the delivery model understands operational state and blast radius.
Practical implication: treat infrastructure changes as governed state transitions, not as ordinary build artefacts.
How drift and dependency chains create delivery risk
Drift appears when deployed infrastructure diverges from source-controlled intent, often because of console changes, emergency fixes, or environment-specific exceptions. Dependency chains magnify that risk because a change to one resource can cascade into others that were not part of the original update. In cloud estates that span multiple teams and regions, those hidden relationships make validation harder and rollback less predictable. The result is not just technical inconsistency but weaker assurance over what is actually running and who changed it.
Practical implication: continuously detect drift and map dependencies before approving changes to live infrastructure.
What a governed delivery unit changes for infrastructure delivery
The article’s stack concept is best understood as a governed delivery unit that ties code, resources, ownership, history, and policy together. That matters because teams need to answer who owns a resource, whether it matches the declared code, whether policy has been applied, and whether a change can be reviewed in context. In practice, this is closer to cloud governance and lifecycle control than to simple CI/CD. It gives infrastructure a delivery boundary that supports traceability and controlled change without pretending the environment is stateless.
Practical implication: organize infrastructure delivery around a traceable governed unit that preserves ownership and policy context.
NHI Mgmt Group analysis
CI/CD is the wrong control model when infrastructure state is the object being governed. Traditional pipelines assume a replaceable target and a bounded rollback path, both of which weaken once the change touches live cloud resources. The operational implication is that delivery governance has to move from artifact shipping to state-aware control of infrastructure change.
The real control gap is not deployment speed but loss of resource-level accountability. When teams cannot answer what owns a resource, what changed it, and whether it still matches policy, they have already lost the governance signal that CI/CD was supposed to provide. That is why infrastructure delivery needs traceability as a first-class control, not an afterthought.
Stack-level governance is a more accurate framing than pipeline modernisation. The article is really describing a shift from code movement to controlled infrastructure state management, where history, drift, compliance, and ownership are part of the delivery object. Practitioners should read that as a change in control plane design, not a tooling preference.
Cloud sprawl turns delivery discipline into a governance requirement. Once infrastructure spans teams, regions, and environments, small misconfigurations can produce outsized operational and compliance effects. The programme implication is that cloud delivery must be governed as a lifecycle, because unmanaged change at scale is itself a risk condition.
Infrastructure delivery exposes a visibility debt that generic CI/CD can hide for too long. The longer teams rely on pipelines that do not track state and drift, the more they accumulate uncertainty about what is deployed and why. Practitioners should treat that uncertainty as a governance defect, not just an engineering inconvenience.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Delivery governance has to move closer to the resource, not just the pipeline. As cloud estates grow, the questions that matter are ownership, drift, policy compliance, and who approved the change. Teams that cannot answer those questions in real time are operating with a visibility gap that CI/CD alone will not close.
State-aware change control is becoming the practical boundary for cloud governance. Infrastructure delivery that ignores live state eventually turns every rollback, exception, and manual fix into technical debt. The programme response is to make traceability and policy enforcement part of the delivery unit itself, not an external audit step.
For practitioners
- Define infrastructure ownership at the resource level Map each cloud resource to source code, team ownership, and approval responsibility so every change can be traced to a governed control point.
- Introduce drift detection before deployment Compare desired state against live state before changes move through the pipeline, and block promotion when unmanaged divergence exists.
- Separate infrastructure change reviews from application release cadence Use approval, testing, and rollback logic that reflects the operational impact of security groups, IAM policies, and routing changes.
- Audit whether manual approvals still match cloud scale Check where human sign-off is still compensating for weak policy automation, especially in environments with multiple teams and fast-changing resources.
Key takeaways
- CI/CD is effective for stateless software, but live cloud infrastructure introduces state, dependencies, and rollback risk that change the governance model.
- The main failure mode is not delivery speed by itself. It is losing traceability, drift control, and policy enforcement over resources that remain live during change.
- Practitioners need a governed delivery model for infrastructure that links ownership, state, and compliance to the unit being changed.
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 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Infrastructure changes here directly affect permissions, policies, and resource access. |
| Recommendation — Apply PR.AA-05 to govern who can change cloud resources and under what approval conditions. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article centres on controlling who can make infrastructure changes and trace ownership. |
| Recommendation — Use CIS-5 to align account ownership and change authority with live infrastructure responsibility. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Infrastructure delivery risk rises when broad change rights touch sensitive cloud controls. |
| Recommendation — Enforce AC-6 so infrastructure changes occur under the minimum access needed for the task. | ||
| NIST Zero Trust (SP 800-207) | 5.2 — The Tenets of Zero Trust | Zero Trust principles support continuous verification of stateful infrastructure change. |
| Recommendation — Apply Zero Trust tenets to verify infrastructure state and authorization before each change. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Cloud delivery tooling and automation often accumulates excessive access in pipeline identities. |
| Recommendation — Review pipeline and automation identities for overprivileged access to infrastructure control paths. | ||
Key terms
- Drift: Any difference between the intended configuration recorded in code and the actual state running in the environment. Drift becomes risky when it accumulates unnoticed, because the live system no longer matches the controls or assumptions used to approve it.
- Stateful Infrastructure: Infrastructure that retains live operational state after a change is applied. Unlike app artifacts that can often be replaced cleanly, stateful infrastructure carries dependencies, access paths, and compliance effects that make rollback and remediation more complex.
- Governed Delivery Unit: A governed delivery unit is the smallest infrastructure scope that can be changed with traceable ownership, policy, and rollback awareness. In cloud operations, this is the practical boundary that turns delivery from a deployment task into a controlled change process.
- Infrastructure Ownership: Infrastructure ownership is the assignment of accountability for a resource, its code source, and its change history. It is essential because governance fails when teams cannot say who is responsible for a resource, why it exists, or which policy applies to it.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org