Resources that exist outside the organisation’s code-based governance process, often because they were created manually or bypassed the normal pipeline. These resources are harder to review, harder to fix consistently, and more likely to accumulate hidden exposure over time.
Expanded Definition
Unmanaged infrastructure is any compute, storage, network, or platform resource that exists outside the organisation’s code-based governance path, including assets created manually, provisioned through ad hoc scripts, or left behind after a workflow bypass. In NHI security, the concern is not only that the resource was created outside policy, but that its identity, secrets, and access posture may never have been brought under lifecycle control. That makes it different from simply “poorly documented” infrastructure.
Definitions vary across vendors, but the practical boundary is clear: if a resource cannot be consistently discovered, reviewed, approved, remediated, and retired through the normal control plane, it is unmanaged in the security sense. This matters because unmanaged resources often become hidden dependencies for service accounts, API keys, and automation agents. The NIST Cybersecurity Framework 2.0 treats asset visibility and governance as core to effective security management, which is why unmanaged infrastructure is more than an operational inconvenience. It is a governance gap that can quietly widen the attack surface over time.
The most common misapplication is treating a manually created environment as temporary when it has already become production-critical.
Examples and Use Cases
Implementing strict infrastructure governance often introduces delivery friction, requiring organisations to weigh deployment speed against the cost of losing visibility and control.
- A developer spins up a database in a cloud console to unblock testing, and the instance later supports a customer-facing workflow without ever entering the IaC repository or review queue.
- An emergency firewall rule is added by hand during an outage, then forgotten, leaving a persistent exception that no policy-as-code check will catch.
- A CI/CD job creates temporary compute for an agentic workflow, but the service account and cloud project survive the job and continue running with broad privileges.
- A merger brings in a separate environment with different provisioning habits, and the inherited assets do not align with the organisation’s normal Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs practices.
- A security team finds a stray access key tied to an abandoned workload, echoing the risk patterns described in Top 10 NHI Issues and the identity visibility gaps covered in NIST Cybersecurity Framework 2.0.
These cases are common where cloud console privileges are broad, infrastructure-as-code is incomplete, or teams rely on manual exceptions to keep services moving.
Why It Matters in NHI Security
Unmanaged infrastructure is dangerous because NHIs attach to it in ways that are easy to miss and hard to unwind. Service accounts, workload identities, secrets, and certificates often inherit the lifecycle of the resource that created them, so a forgotten VM or orphaned container can become a long-lived trust anchor. That is exactly where attackers look: stale resources, inconsistent baselines, and access paths that were never designed to be revisited. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 96% store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools. In unmanaged infrastructure, those numbers become operational realities, not abstractions.
The governance impact is broader than exposure alone. Unmanaged resources break audit trails, complicate rotation, and make Zero Trust enforcement brittle because policy cannot be applied reliably to assets that are invisible or partially owned. They also create a false sense of control: a dashboard may show compliant systems while the highest-risk workloads sit outside the managed estate. The review burden then shifts to incident response, when cleanup is slower and the blast radius is already established. Organisations typically encounter the cost only after an outage, breach, or audit finding exposes the missing asset trail, at which point unmanaged infrastructure 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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Unmanaged infrastructure often hides NHIs that never enter discovery, inventory, or ownership controls. |
| NIST CSF 2.0 | GV.AM-01 | Asset management requires organisations to know what exists before they can govern it. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on verified asset and identity context for every access decision. |
Continuously discover infrastructure and reconcile shadow assets into the authoritative inventory.
Related resources from NHI Mgmt Group
- What is the biggest long-term risk of unmanaged NHIs multiplying at exponential rates?
- What challenges do unmanaged API keys pose within MCP?
- What is the difference between network controls and identity controls for infrastructure access?
- Why do static credentials create more risk in hybrid infrastructure?