Infrastructure as Code in 2026: Drift, Policy, and the Terraform vs OpenTofu Decision

Most organisations now say they "do Infrastructure as Code," and most of them are only partly telling the truth. Firefly's 2025 State of Infrastructure as Code found that while 72% of organisations use IaC, only about one-third have codified more than 75% of their infrastructure (Firefly, 2025). The gap between those two numbers is where outages, failed audits, and surprise cloud bills live. For an engineering director at a regulated Benelux team, the interesting question is no longer "should we adopt IaC" but "what does mature IaC actually require, and which tool do we standardise on now that the ecosystem has split." This article answers the questions teams are actually searching for.

Interior of a data center showing multiple rows of tall metal server racks - the physical infrastructure that Infrastructure as Code provisions and manages declaratively.

What is Infrastructure as Code, really?

Infrastructure as Code means defining your servers, networks, databases, and cloud resources in machine-readable definition files that you version, review, and apply through automation - rather than clicking through a console. The distinction that matters in practice is declarative versus imperative. An imperative approach scripts the steps ("create this VPC, then this subnet, then attach this gateway"). A declarative approach describes the desired end state and lets the tool compute the diff between what exists and what you asked for. Terraform, OpenTofu, AWS CloudFormation, and Pulumi are all primarily declarative, which is why they dominate: the tool owns the reconciliation logic, not your runbook.

That declarative model is the whole point. It gives you a single source of truth that doubles as documentation, a pull-request workflow for infrastructure changes, and a reproducible way to stand up identical staging and production environments. It is also what makes the next problem - drift - both detectable and fixable, which it simply is not when infrastructure lives in someone's memory and a series of manual console clicks.

Why does configuration drift keep breaking production?

Configuration drift is the divergence between the state your code declares and the state actually running in the cloud. It happens for mundane reasons: an engineer makes an emergency change in the console during an incident, an auto-scaling group rewrites a value, a managed service updates a default, or two teams edit overlapping resources. Each individual change is small. The cumulative effect is an environment your IaC no longer describes - so the next `apply` either reverts a fix someone made by hand or fails outright.

Drift is dangerous precisely because it is invisible until you act on stale assumptions. The defence is continuous drift detection: a scheduled job that compares declared state against live state and flags every divergence, rather than discovering it during a high-pressure deploy. This is also where the "only one-third have codified most of their estate" statistic bites. If two-thirds of your infrastructure was created by hand and never imported into code, drift detection has nothing to compare against, and the manual provisioning that Firefly's report flags - roughly 30% of teams still deploy Terraform manually rather than through a pipeline - is exactly the behaviour that reintroduces drift faster than you can remediate it (Firefly, 2025). The fix is unglamorous: import existing resources into code, route every change through CI/CD, and treat a drift alert as a defect, not a curiosity.

What does policy as code actually buy a regulated team?

For a regulated team, the strongest argument for IaC is not speed - it is governance. Because infrastructure is now code in a pull request, you can attach policy as code: machine-enforced rules that run in the pipeline before anything reaches production. Open Policy Agent (OPA) and HashiCorp Sentinel are the common engines. A policy can refuse any storage bucket without encryption at rest, block a security group that opens port 22 to the internet, deny resources deployed outside EU regions, or require a cost-centre tag on everything. The rule is evaluated automatically on every change, and the result is recorded.

That last point is what auditors care about. Instead of "we have a policy that says encryption is required," you can demonstrate "this control is enforced in code, every proposed change is evaluated against it, and here is the immutable history of every pass and fail." It turns a written policy into an executed control with an audit trail - the difference between a compliance aspiration and a compliance fact. Given that 45% of respondents in Firefly's survey named security and compliance risk as a major IaC challenge, policy as code is the part of the discipline that converts that risk from a liability into a strength.

Terraform vs OpenTofu: which should you standardise on?

This is the question that changed since most teams last revisited their IaC strategy, and it deserves a clear-eyed answer. In 2023 HashiCorp relicensed Terraform from an open-source licence to the Business Source License. The community responded by forking the last open-source version into OpenTofu, now governed under the Linux Foundation. OpenTofu reached a stable release in January 2024 and has matured fast: by early 2025 it had reported more than 300% year-over-year growth in registry usage and tripled its contributor base to over 160, while shipping features Terraform users had requested for years - most notably native end-to-end state encryption (InfoWorld, 2025).

The corporate picture also shifted: IBM completed its $6.4 billion acquisition of HashiCorp on 27 February 2025, folding Terraform into a larger hybrid-cloud portfolio (IBM, 2025). Terraform remains the incumbent by a wide margin - it was used by 17.8% of all developers in the 2025 Stack Overflow Developer Survey, well ahead of any other dedicated IaC tool (Stack Overflow, 2025) - so this is not a story of one tool replacing the other.

The pragmatic decision rule: the two are still largely interchangeable at the HCL level, so the choice turns on your constraints, not on syntax. If you already run HCP Terraform or depend on Sentinel and enterprise support, staying put is reasonable and low-risk. If you are starting greenfield, want to avoid the BSL and any future licensing surprise, or specifically value features like native state encryption for a DevSecOps posture, OpenTofu is now a credible default rather than a gamble. The one thing not to do is treat the fork as irrelevant: pick deliberately, document why, and avoid drifting into a mixed estate where half your modules assume one tool and half assume the other.

Is Infrastructure as Code worth it, and what does "good" look like?

The data answers the worth-it question by omission: when 72% of organisations use IaC and 80% run multi-cloud environments, IaC has stopped being a competitive edge and become table stakes (Firefly, 2025). The teams pulling ahead are not the ones that "have Terraform" - they are the ones that closed the coverage gap. Mature IaC, concretely, looks like this: nearly all infrastructure is codified and version-controlled; every change goes through a pull request and a pipeline, never the console; drift detection runs continuously and a divergence is treated as a bug; policy as code enforces security, residency, and cost rules automatically with a recorded audit trail; and the choice of Terraform or OpenTofu is a deliberate, documented standard rather than an accident of whoever set up the first module.

None of that is exotic. It is the difference between infrastructure you can reason about, prove to an auditor, and rebuild after a disaster, and infrastructure that merely happens to be running today. For high-scale teams under regulation, that difference is the entire return on investment.