Infrastructure as code is strong at creating consistent baselines, but it is weaker at showing how live systems have changed over time. It also requires new tenant configurations to be coded separately, which limits flexibility. Without drift management, teams can miss unauthorized or accidental changes, lose historical context, and struggle to prioritise remediation based on actual operational risk.
Where Infrastructure as Code Is Strong, and Where Control Still Slips
Infrastructure as code is effective at making intended state repeatable, reviewable, and easier to deploy at scale. That strength is also its limit: it captures what should exist, not necessarily what is actually running, who changed it, or how long a deviation has been present. In practice, the control gap appears when organisations treat a deployment definition as a complete record of configuration truth.
The main issue is that configuration control is not just initial provisioning. It also includes detection of drift, tracking exceptions, understanding operational changes, and preserving evidence of change over time. When those layers are missing, teams can approve a clean file while a live environment quietly accumulates unmanaged differences. For security teams, that means the baseline can look compliant even when the runtime state is not. In practice, many security teams encounter this only after an outage, audit finding, or incident has already exposed the gap.
Why Live State, Drift, and Tenant Variation Matter in Practice
Infrastructure as code works best when the environment is stable, the deployment path is well defined, and every meaningful configuration change is represented in version control. It becomes weaker when organisations assume that code alone can explain current exposure. Drift is the key limitation: manual hotfixes, emergency edits, console-side changes, and platform defaults can all move the live system away from the declared template without changing the repository.
Tenant-specific settings add another layer of complexity. Many platforms require new environments, subscriptions, accounts, or tenants to be configured with local parameters that are not fully generic. That means a reusable template may still need separate coding for region, policy, logging, identity boundaries, networking, or service settings. If those differences are not modelled explicitly, teams can end up with a “standard” build that is only standard in name.
- Declared state shows intent, but runtime inspection shows exposure.
- Version control helps with review, but it does not by itself detect drift.
- Exception handling matters because operational changes often happen outside the normal pipeline.
- Local tenant variation can create configuration blind spots even when the base template is well designed.
This is why configuration control needs a feedback loop, not only a provisioning mechanism. A useful comparison is the official OWASP Non-Human Identity Top 10, which is relevant when automation and service-level access create hidden control dependencies, but the same lesson applies here: the strongest design still fails if organisations cannot see what has changed after deployment.
The guidance breaks down when teams use infrastructure as code as a substitute for monitoring, asset reconciliation, or change validation.
What Breaks When Drift, Exceptions, and Hidden Dependencies Build Up
Tighter configuration control often increases operational overhead, so organisations must balance deployment speed against the work needed to verify live state and manage exceptions. That tradeoff is real: the more dynamic the environment, the more difficult it is to keep declarative definitions aligned with reality.
Common edge cases appear in cloud platforms, managed services, and hybrid estates where some settings are owned by the platform, some by central engineering, and some by application teams. Guidance also differs by maturity. There is broad consensus that drift must be measured, but there is less consensus on how much deviation should be accepted for ephemeral workloads versus long-lived systems. The right answer depends on whether the change affects security boundaries, logging, identity trust, data handling, or recovery assumptions.
Another hidden issue is historical context. Infrastructure as code can show the current desired baseline, but it may not explain why a system diverged, whether the change was approved, or whether remediation should be urgent. That matters because not all drift carries equal risk. A cosmetic difference is not the same as a firewall exception, disabled logging, or weakened access control.
Teams get into trouble when they flatten every deviation into the same remediation queue or, worse, ignore differences because the repository still looks clean.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | IaC gaps are configuration-control gaps that CIS 4 directly addresses. |
| Recommendation — Compare live state to approved baselines and remediate unauthorized configuration drift. | ||
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | The question concerns maintaining and validating configuration integrity over time. |
| DE.CM — Continuous Monitoring | Drift and hidden changes require ongoing detection, not one-time deployment review. | |
| RS.MI — Mitigation | Configuration deviations need prioritised correction when they create exposure or instability. | |
| Recommendation — Maintain configuration baselines and verify runtime systems against them. Continuously monitor environments for unauthorized or unintended configuration change. Prioritise remediation of drift that changes security, resilience, or operational risk. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Hidden config changes can preserve or enable unauthorized access paths through trusted accounts. |
| Recommendation — Hunt for access paths that remain valid because configuration changes were not reconciled. | ||
Practitioner Guidance
What to prioritise: Treat drift detection and exception tracking as part of configuration control, not as a separate hygiene task. If a team can deploy from code but cannot prove current state, the control is incomplete.
What to verify: Check whether live systems are compared against the declared baseline on a schedule that matches the change rate of the environment. Confirm that console changes, emergency fixes, and managed-service defaults are captured somewhere observable.
Decision rule: If a difference changes exposure, logging, access, or recovery, treat it as a security-relevant deviation. If it only affects presentation or non-critical tuning, classify it separately so urgent issues are not buried.
What practitioners underestimate: The hard part is usually not writing the template; it is maintaining confidence that the template still describes reality after months of operational change.
Practitioner takeaway: Infrastructure as code is a provisioning control, not a complete truth source, so mature configuration governance must continuously reconcile declared intent with live state.
