Join our Newsletter — 33% off our NHI Course

What do organisations get wrong about migrating cloud infrastructure to Infrastructure as Code?

A common mistake is treating migration as a pure code-generation exercise. In practice, the hard part is reconstructing the environment’s structure so Terraform reflects how resources actually work together. Without that model, teams may import incomplete stacks, miss dependencies, and create state that is technically valid but operationally weak.

Why This Matters for Security Teams

Cloud-to-IaC migration fails when teams assume the goal is to translate console settings into HCL and call it done. The real problem is identity, dependency, and operational intent: infrastructure is not just a list of resources, but a living system of access paths, policy bindings, and secrets flows. That is why a Terraform state file can be syntactically correct and still be unsafe to run.

NHI Management Group’s 2024 Non-Human Identity Security Report shows how often organisations underestimate this class of risk, with 88.5% saying their non-human IAM practices lag behind or only match human IAM. That gap matters during migration because cloud resources often depend on machine identities, token brokers, and secret distribution paths that are easy to miss if the project is framed as automation rather than reconstruction. Standards such as the NIST Cybersecurity Framework 2.0 are useful here because they force attention onto governance, recovery, and continuous control operation, not just code delivery.

In practice, many security teams discover missing trust relationships only after the new IaC pipeline has already mirrored the old environment’s weakest assumptions.

How It Works in Practice

A safer migration starts by modelling the target environment before writing code. That means mapping resource dependency chains, identifying which services call which APIs, documenting where secrets live, and deciding which identities should exist at all. The most common failure is importing infrastructure one object at a time and assuming the resulting stack is complete because the plan applies successfully.

Practitioners usually get better results by separating the migration into layers:

  • Inventory the live environment, including service accounts, roles, secrets, routes, storage policies, and cross-account trust.
  • Rebuild the dependency graph so the IaC modules reflect operational boundaries rather than provider console layouts.
  • Decide which items should be managed, imported, or replaced, instead of forcing every resource into the same workflow.
  • Validate that state, drift detection, and secret rotation are part of the operating model, not optional cleanup tasks.

This is where the NHIMG research link between secret exposure and privilege escalation becomes relevant. For example, the Azure Key Vault privilege escalation exposure illustrates how an apparently narrow permissions issue can become a broad infrastructure risk when identities and secrets are not mapped together. The same pattern shows up in public breach analysis such as the Snowflake breach, where access paths, credential handling, and environment assumptions mattered more than any single misconfigured resource.

Current guidance suggests treating IaC migration as a control redesign exercise: choose least privilege, short-lived secrets, and explicit module boundaries first, then codify the infrastructure around those decisions. These controls tend to break down when legacy environments contain undocumented cross-service dependencies because the migration team cannot safely infer ownership or trust from the cloud console alone.

Common Variations and Edge Cases

Tighter migration control often increases delivery time, requiring organisations to balance speed against the risk of preserving insecure architecture in code. That tradeoff becomes sharp in hybrid estates, multi-account clouds, and acquired environments where documentation is incomplete and the original operators are no longer available.

There is no universal standard for this yet, but best practice is evolving toward staged import with progressive refactoring. In mature migrations, teams often leave some resources unmanaged temporarily while they rebuild the security model around them, especially for shared networking, legacy databases, and secrets systems. That approach is less elegant than a full greenfield rewrite, but it avoids encoding brittle relationships into Terraform modules that become difficult to change later.

This is also where migration teams should pay attention to identity-centric failure modes described in the 230M AWS environment compromise. In environments with heavy automation, the wrong assumption is that infrastructure code automatically improves security. It only does so when the migration explicitly removes standing access, reduces secret sprawl, and verifies that the resulting operational model still works under change. The NIST Cybersecurity Framework 2.0 remains useful as a planning baseline, but it does not replace environment-specific threat modelling.

Organisations usually get this wrong when they optimise for a clean repo instead of a trustworthy runtime.

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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) 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-03 IaC migrations often expose weak secret rotation and static credential patterns.
NIST CSF 2.0 PR.AC-4 Migration errors often come from unmanaged access paths and trust relationships.
NIST Zero Trust (SP 800-207) SC-7 IaC should enforce explicit trust boundaries instead of implicit network trust.
NIST AI RMF Automated migration decisions need governance, validation, and human accountability.
CSA MAESTRO A2 Cloud migration requires control-plane visibility into identities, secrets, and dependencies.

Use AI RMF governance to review automated code generation and environment reconstruction.