Who Secures the Operating System in IaaS
In infrastructure-as-a-service, the cloud provider is responsible for the physical data center, networking fabric, and the hypervisor that isolates your virtual machine. The operating system, its patches, access controls, and configuration settings remain your responsibility unless you explicitly delegate that work through managed services. Misunderstanding this boundary is the fastest way to create a gap that attackers exploit.
More from this site
Keep reading the latest coverage
The provider ensures the hypervisor is patched and that the host OS is hardened, but they do not log into your guest instance to apply updates or configure firewall rules. That line is the core of the shared responsibility model, and it shifts depending on whether you run unmanaged VMs, managed instances, or containers.
What the IaaS Provider Typically Owns
Providers secure the infrastructure stack down to the hypervisor layer. This includes physical security, facility access controls, host OS patching for the underlying machines, hypervisor isolation, and the management plane that provisions and monitors your resources. Network controls at the gateway level, such as DDoS mitigation and edge firewalling, are also generally included.
What they do not touch is your guest operating system, its kernel parameters, installed services, user accounts, or the rules you configure inside the instance. If you launch an unmanaged VM, you own everything above the hypervisor.
Your OS Security Settings in IaaS
Once a virtual machine is provisioned, you are accountable for the full OS security posture. This includes patch management, disabling unnecessary services, enforcing least-privilege user accounts, configuring host-based firewalls, auditing file permissions, and managing encryption keys for disk and data in transit.
Specific settings that fall to you typically include:
- OS patch level and update cadence
- Kernel and service hardening
- User and group permissions
- Host firewall and intrusion-detection rules
- Secure remote access configuration
- Logging and monitoring agents
Neglecting any of these creates exposure that the provider will not remediate on your behalf, because they have no visibility or control inside your guest environment.
Shared Responsibility Across IaaS Configurations
The split changes when you move from raw VMs to higher-level managed services. For example, AWS Fargate or Azure Container Apps abstract the host OS entirely, so the provider handles OS patching and hardening for the underlying infrastructure. You retain responsibility for your application code, container image choices, and identity and access policies.
With managed instance groups or Azure Virtual Machine Scale Sets, you still control OS settings, but automation features like patch orchestration shift the operational burden. The provider supplies the tooling; you define the policies.
| Configuration | Provider Responsibility | Your Responsibility |
|---|---|---|
| Raw IaaS VM | Hypervisor, host OS, physical security | Guest OS, patches, firewall, access control |
| Managed containers | Host OS, orchestrator, patching | Container image, app code, IAM policies |
| Managed VMs with patch orchestration | Infrastructure, patching tooling | Patch policies, OS configuration, compliance validation |
Common Gaps in OS Security Settings
The most frequent failures in IaaS environments are unpatched operating systems, exposed management ports, overly permissive SSH or RDP access, and default credentials left unchanged. Cloud providers offer native tools such as AWS Systems Manager Patch Manager or Azure Update Manager to automate remediation, but they only work if you enable and configure them.
Misconfigured security groups and network access controls also create risk that is often blamed on the provider. The provider supplies the controls, but you define the rules and must review them regularly.
Verifying Your OS Security Posture
Start by mapping every IaaS workload to its owner and documenting which OS settings are in scope. Use cloud-native security posture management tools and third-party scanners to detect drift from your baseline. Automate patching and configuration enforcement so that changes do not silently degrade security over time.
Regularly test access controls, validate encryption settings, and review logs for anomalies. In IaaS, the provider secures the foundation, but the operating system security settings that determine whether your workloads are safe are yours to own and maintain.