What do security teams get wrong about onboarding infrastructure as code platforms?

A common mistake is treating onboarding as a one-time setup task rather than an ongoing inventory and governance process. If unmanaged paths are not surfaced early, teams inherit blind spots that affect policy enforcement, drift monitoring, and access control. Effective onboarding should expose what exists, what is unmanaged, and what needs to be governed.

Why This Matters for Security Teams

Infrastructure as code platforms are often introduced as a way to standardise deployments, but the security problem is broader than template hygiene. These platforms can provision cloud resources, manage secrets, and trigger automation across environments, which means the onboarding decision determines what is visible, what is governed, and what can change without review. If teams only approve the tool and skip the inventory work, they create a blind spot that survives every subsequent policy review.

The risk is not theoretical. NHIMG’s The 2026 Infrastructure Identity Survey reports that 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, which is a strong signal that onboarding often lags behind real operating conditions. Security teams also tend to underestimate how quickly unmanaged modules, service accounts, and pipeline tokens accumulate once infrastructure code is allowed to scale.

Practitioners who treat onboarding as a one-time control usually discover drift only after a release failure, an audit exception, or a privilege escalation. In practice, many security teams encounter unmanaged infrastructure paths only after those paths have already been used in production.

How It Works in Practice

Effective onboarding is an identity and governance exercise, not just a repository review. The first step is to discover every IaC platform, pipeline, runner, state backend, and secrets integration that can affect infrastructure. From there, teams map which identities are human-operated, which are workload identities, and which are long-lived service accounts with standing privilege. That inventory should include where approvals happen, where state is stored, and which environments can be changed automatically.

Best practice is to bind each platform to policy at the point of execution, not only at the point of code review. That means using least privilege for CI/CD service accounts, short-lived credentials where possible, and explicit controls over who can merge, apply, or promote changes. It also means monitoring for unmanaged execution paths such as ad hoc runners, locally executed plans, and shadow automation that bypasses normal controls. Guidance from CISA Secure by Design reinforces the need to reduce implicit trust in the system itself, while FATF Recommendations are a useful reminder that identity, attribution, and traceability matter whenever automated systems can initiate sensitive actions.

• Inventory every IaC entry point, including secondary runners and emergency paths.
• Assign a unique workload identity to each pipeline or platform component.
• Use short-lived secrets and rotate or revoke credentials tied to onboarding.
• Require logging that ties each apply action to a change request or approved policy.
• Continuously compare declared infrastructure against deployed reality.

NHIMG research on the Ultimate Guide to NHIs — The NHI Market is a useful reference point because IaC platforms increasingly behave like non-human identities with their own access, toolchains, and audit footprints. These controls tend to break down when teams allow multiple cloud accounts, permissive bootstrap roles, and unmanaged self-hosted runners because the organisation can no longer prove which identity made which change.

Common Variations and Edge Cases

Tighter onboarding often increases operational overhead, requiring organisations to balance deployment speed against assurance. That tradeoff becomes more visible in multi-account cloud estates, GitOps workflows, and platform engineering teams that move fast by design. The mistake is assuming every IaC platform should be governed identically; current guidance suggests the control pattern should vary by blast radius, deployment autonomy, and whether the system can reach production.

Edge cases usually appear where human review is weak or impossible. For example, ephemeral preview environments may justify lighter controls, but production deployers and state managers should face stronger identity checks and tighter policy enforcement. Similarly, a vendor-managed IaC product that can mint infrastructure changes through an API should be treated as an external execution identity, not just a software tool. There is no universal standard for this yet, but the direction is clear: organisations need visibility into who or what can create infrastructure, not just which repository contains the code.

Another common failure mode is overconfidence in scanning. Static analysis can catch bad templates, but it cannot tell whether the platform itself is still holding old tokens, stale trust relationships, or orphaned privileges. That is why onboarding should be tied to continuous review, especially when teams expand into hybrid cloud or delegate portions of infrastructure change to automation platforms with standing access.

Related resources from NHI Mgmt Group

• What do security teams get wrong about collecting practitioner feedback for identity platforms?
• What do security teams get wrong about self-service infrastructure governance?
• What do security teams get wrong about private code snippets and sharing platforms?
• What do security teams get wrong about using APIs to manage user roles and application licences?