Who is accountable when infrastructure as code onboarding leaves unmanaged code paths outside governance?

Why This Matters for Security Teams

When infrastructure as code onboarding leaves code paths outside governance, the problem is not just missing paperwork. It is a control gap that can let repositories, pipelines, and deployment roles diverge from approved policy while still appearing “onboarded.” That creates blind spots in change approval, drift detection, and incident response, especially when teams assume a platform standard covers everything.

Security, cloud, and platform owners each hold part of the answer, but accountability must be explicit because unmanaged paths often bypass the controls described in the NIST Cybersecurity Framework 2.0. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives also treats non-human access as something that must be mapped, owned, and reviewed, not merely registered.

The real risk is that unmanaged code paths become permanent exceptions: they keep shipping, keep changing, and keep accumulating access until nobody can say who approved them or who is responsible when they drift. In practice, many security teams discover those paths only after an audit finding or failed deployment reveals them, rather than through intentional governance.

How It Works in Practice

Accountability should be split by function, not left vague. Platform owners usually own the onboarding framework, cloud teams own the underlying control plane, and infrastructure security owns the governance rules that decide what is permitted, monitored, and revoked. That means each team needs a named responsibility for repository discovery, stack registration, policy enforcement, and exception handling.

A practical operating model usually includes:

• Discovery of all repositories, modules, and deployment pipelines before onboarding is marked complete.
• Policy checks against approved patterns, using controls from NIST SP 800-53 Rev. 5 Security and Privacy Controls as a baseline for access, logging, and configuration governance.
• Explicit exception ownership, with expiry dates and a named approver, so exceptions do not become hidden standards.
• Continuous drift monitoring that compares deployed state to the declared source of truth.
• Periodic review of dormant stacks and orphaned paths, since “unused” often still means “still privileged.”

NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference because unmanaged code paths behave like unmanaged identities: they need lifecycle ownership, not just initial approval. Where teams are still building this model, current guidance suggests treating onboarding as a governance event, not a one-time technical import.

This guidance tends to break down in federated engineering organisations where multiple platform teams can create pipelines independently and no single control owner can enforce uniform onboarding criteria.

Common Variations and Edge Cases

Tighter onboarding control often increases delivery overhead, requiring organisations to balance speed against assurance. That tradeoff becomes especially visible in high-change environments, where platform teams want self-service while security teams need traceability.

There is no universal standard for this yet, but the most common edge case is partial onboarding: a stack is registered, yet its auxiliary repositories, bootstrap scripts, or emergency deployment paths remain outside governance. Another common variation is inherited infrastructure, where code created before current standards still deploys critical workloads but lacks a clean owner.

That is why some organisations assign accountability by source of authority. If the path creates or changes infrastructure, the team that owns the pipeline owns onboarding completeness. If the path authorises deployment, the security owner owns policy coverage. If the path exists only as a temporary exception, the exception owner must carry the expiry and review burden.

NHIMG’s Top 10 NHI Issues is relevant here because unmanaged access and weak lifecycle control often travel together. In the field, the hardest cases are legacy code paths, acquired environments, and “temporary” hotfix routes that were never retired, because each one creates a governance exception that looks operational until it becomes security debt.

Related resources from NHI Mgmt Group

• Who is accountable when hybrid identity governance leaves systems outside central policy control?
• Who is accountable for Entra ID recovery and governance when identity changes bypass Infrastructure as Code?
• Who is accountable for Terraform governance when some code is managed and some code is still outside control?
• Who is accountable for cloud governance when infrastructure is provisioned through shared pipelines and code repositories?