IaC import is the process of bringing an existing cloud resource under infrastructure as code management without recreating it. The tool maps the live object, generates matching configuration, and reconciles that code against current state so teams can govern the resource through Terraform going forward.
Expanded Definition
IaC import is a reconciliation workflow, not a migration by recreation. It brings an already running cloud resource under code control so the declared configuration matches the live object, which is essential when teams inherit unmanaged infrastructure, brownfield estates, or production systems that cannot tolerate replacement. In practice, the import step usually reveals drift, hidden dependencies, and settings that were never documented in source control.
Definitions vary across vendors about how much of the configuration should be generated automatically versus hand-corrected after import. NHI Management Group treats IaC import as part of governance, because the imported resource often includes secrets, identities, or access paths that must be reviewed before the code is considered authoritative. For control baselines, NIST SP 800-53 Rev 5 Security and Privacy Controls is the clearest external reference for mapping the resulting configuration to inventory, access, and change management expectations.
The most common misapplication is treating import as a one-click fix, which occurs when teams import a resource without validating ownership, drift, and sensitive dependencies first.
Examples and Use Cases
Implementing IaC import rigorously often introduces short-term complexity, requiring organisations to weigh faster governance against the cost of manual reconciliation and state cleanup.
- A cloud firewall rule set was created manually during an incident, then imported so the security team could version future changes and avoid configuration drift.
- A legacy database instance was imported into Terraform after a platform team discovered that the original deployment process had no repeatable build path.
- An application load balancer was brought under code management after an audit showed the live settings differed from the approved baseline in source control.
- A service account attached to an imported resource was reviewed before code was accepted, because the move to IaC also exposed inherited non-human identity permissions.
For NHI-heavy environments, import often becomes the moment when undocumented access paths surface. That is why the Ultimate Guide to NHIs is relevant here: imported infrastructure frequently contains service accounts, API keys, or secret references that were never part of the original design review. Teams also use the process to align the live object with external guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially when the goal is to prove inventory accuracy and change traceability.
Why It Matters in NHI Security
IaC import matters because unmanaged resources often hide the exact conditions that create NHI exposure: forgotten permissions, hard-coded secrets, and stale operational exceptions. NHIMG reports that 30.9% of organisations store long-term credentials directly in code, 96% store secrets outside secrets managers in vulnerable locations, and only 5.7% have full visibility into their service accounts, which shows how quickly “temporary” infrastructure becomes an identity risk surface. When an imported object includes attached credentials or tool access, the resource is no longer just a configuration item; it is part of the NHI attack path.
Import also supports zero-trust discipline by forcing teams to verify what exists before they grant code-based authority over it. That is especially important because the Ultimate Guide to NHIs shows how widespread excessive privilege and secrets leakage already are, and those risks can be preserved if import is handled casually. Organisations typically encounter the true cost after an audit, breach review, or incident response effort exposes the unmanaged resource, at which point IaC import 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-02 | Importing live resources often exposes secrets, drift, and overprivileged NHI assets. |
| NIST CSF 2.0 | CM-2 | IaC import supports asset baselines and controlled configuration management. |
| NIST Zero Trust (SP 800-207) | SC-7 | Imported resources must be rechecked for trust boundaries and access paths. |
| NIST SP 800-63 | IAL2 | Imported systems may carry identities whose assurance needs review. |
| NIST AI RMF | IaC import is a governance action that improves traceability and accountability. |
Reconcile imported resources and validate attached secrets, identities, and permissions before code promotion.
Related resources from NHI Mgmt Group
- How should teams choose between bulk import and just-in-time CIAM migration?
- How should teams connect cloud security findings to IaC remediation workflows?
- How should security teams measure whether infrastructure is actually governed by IaC?
- Who should own IaC risk governance when DevOps and security share the same environment?
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
