A cloud model in which the customer controls the virtual server, installed software, and operating system configuration. The provider supplies the underlying compute, storage, and hardware platform. Security responsibility is broader here because patching, hardening, network exposure, and application maintenance sit largely with the customer.
Expanded Definition
infrastructure as a service, or IaaS, is the cloud delivery model where the provider supplies compute, storage, networking, and the virtualisation layer, while the customer configures the guest operating system, applications, identity controls, and data protection choices. It sits lower in the shared responsibility stack than Platform as a Service or Software as a Service, so the customer inherits more operational security burden.
The boundary that matters most is control of the operating environment. The provider secures the underlying facilities and host platform, but the customer still decides how the virtual machines are exposed, patched, segmented, logged, and administered. That is why IaaS is often described as flexible but demanding. It is not a managed security service, and it is not a guarantee of secure configuration.
In practice, the common misunderstanding is to treat cloud migration as a transfer of protection rather than a redistribution of duties. NHI Management Group sees this boundary error repeatedly in cloud governance discussions: the service may be elastic, but accountability for what runs inside the instance remains with the tenant.
Examples and Use Cases
IaaS appears wherever teams need raw, programmable infrastructure without buying physical servers. The model is common in environments that require fast scaling, custom operating system builds, or legacy workloads that cannot yet be refactored into managed services.
- A development team provisions virtual machines for a test environment and controls the OS image, application stack, and security agents.
- An enterprise lifts and shifts a business application into cloud servers while keeping the same patch cadence and host hardening responsibilities.
- A security team deploys segmented workloads for sensitive processing and defines the network controls around each instance.
- An engineering group uses ephemeral infrastructure for batch jobs, then destroys the servers after the workload completes.
- An identity team runs automation on cloud instances, where instance access, local credentials, and service permissions must be governed carefully.
The trade-off is clear: more flexibility and portability usually means more configuration ownership. That can be helpful for specialised workloads, but it also increases the chance that exposed services, stale images, or weak administrative paths become part of the environment.
If the workload depends on machine identities, tokens, or automation credentials, the operational model starts to overlap with NHI governance. For that reason, the OWASP Non-Human Identity Top 10 is useful reading when IaaS hosts automated workloads or infrastructure tools.
Security Implications
IaaS creates security exposure when teams assume the provider is responsible for controls that actually sit inside the guest environment. Misunderstood responsibility boundaries can leave operating systems unpatched, administrative interfaces overexposed, or storage volumes accessible beyond their intended scope.
The most common failure conditions are poor instance hardening, excessive network reachability, inconsistent logging, and weak control over secrets used by automation on cloud hosts. Because IaaS is highly configurable, the blast radius can grow quickly when a baseline image, security group, or instance role is reused across many systems.
Operationally, the symptoms are often subtle before they become serious: drift between approved images and running instances, old services still listening on public ports, and unclear ownership of patching or backup restoration. Those are not abstract cloud hygiene issues; they are direct indicators that the customer side of the shared responsibility model is not being enforced.
Domain and Governance Relevance
IaaS matters in cybersecurity governance because it is one of the clearest examples of shared responsibility in action. Control ownership does not disappear in the cloud; it shifts. That means governance must define who hardens the host, who approves network exposure, who maintains the image, and who verifies that identity and logging controls remain consistent over time.
For identity and NHI-heavy environments, IaaS is especially important because automation often runs close to the metal. Build agents, deployment tools, and workload scripts may authenticate from inside cloud instances, which makes credential scope, rotation, and instance-level trust part of the security design. When those relationships are unmanaged, the infrastructure layer becomes an access layer as well as a compute layer.
In broader cloud security terms, IaaS is where architecture decisions, operational ownership, and identity governance meet. The model offers control, but only if organisations are prepared to govern the controls they now own.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | IaaS shifts patching and hardening to the customer. |
| PR.AC — Identity Management, Authentication and Access Control | IaaS host access and administrative paths must be tightly governed. | |
| DE.CM — Security Continuous Monitoring | Instance drift and exposed services require continuous visibility. | |
| Recommendation — Define and maintain host hardening, patching, and secure build processes for cloud instances. Restrict administrative access to IaaS instances and enforce least-privilege controls. Monitor cloud instances for configuration drift, unexpected exposure, and anomalous activity. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | IaaS demands secure baseline images and hardened instance settings. |
| CIS-6 — Access Control Management | Cloud instance administration and automation access are primary control points. | |
| Recommendation — Apply secure configuration baselines to every virtual machine image and running instance. Review and remove unnecessary access paths to cloud consoles, hosts, and automation credentials. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | IaaS workloads often rely on machine credentials and automation secrets. |
| Recommendation — Inventory and rotate secrets used by workloads, scripts, and infrastructure automation on cloud hosts. | ||
Related resources from NHI Mgmt Group
- What breaks when service accounts have broad reach into identity infrastructure?
- Who is accountable when an AI service is abused to host phishing infrastructure?
- Why do hardcoded service credentials increase the blast radius of exposed infrastructure systems?
- Why does infrastructure as code matter for service mesh operations in multi-team environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
