What is infrastructure as a service and what do you secure in it?

Infrastructure as a service (IaaS) means renting computing, storage and networking on demand and running your own software on top. The provider secures the physical facilities and the underlying infrastructure. You secure the operating systems, applications, identities, network rules and data you put on it.

How does NIST define it?

NIST's SP 800-145 is the reference definition of cloud computing. For IaaS, the capability provided to the consumer is to provision processing, storage, networks and other fundamental computing resources, where the consumer can deploy and run arbitrary software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but controls operating systems, storage and deployed applications, and possibly limited networking components such as host firewalls. The same wording appears in the NIST glossary entry.

That definition is the shared responsibility split in one sentence. Everything the consumer controls is something the consumer must secure.

What do you own in practice?

Guest operating systems. Patching, hardening, remote access and endpoint tooling are yours. A virtual machine image from a catalogue is a starting point, not a hardened system.

Identity and access. Who can create, change and delete resources is governed by the account's identity policies. Overly broad administrator roles and long-lived access keys are common causes of cloud incidents.

Network configuration. Security groups, routing tables and public IP addresses decide what is reachable. A rule that opens an administrative port to the whole internet is a configuration you created.

Data. Encryption choices, key management, backups and storage access policies are yours to set.

Logging and monitoring. Provider logs exist, but you must enable, collect, retain and review them.

Images and templates. Infrastructure code and machine images are software. They carry dependencies and secrets, and need the same review as application code.

What does the provider cover?

The provider is responsible for the physical data centres, the hardware, the network backbone and the hypervisor, the layer that separates tenants. Providers publish documents, audit reports and responsibility matrices. Read the ones for your provider and the specific services you use, because details differ between a virtual machine and a managed database.

A constructed example

A startup launches a virtual machine to run a reporting tool. The image is six months old, the default security group allows SSH from anywhere, and the instance has an access role that can read every storage bucket in the account. Within hours of launch, automated scanners find SSH. No provider failure occurred. All three issues sit in the consumer's half of the split.

A better launch: use a current hardened image, allow administrative access only through a bastion or session manager, and give the instance a role that reads one bucket.

What do teams usually get wrong?

They assume a default setting is a safe setting. Public storage, wide-open administrative ports, shared administrator accounts and disabled logging are choices a person made, often under time pressure, and rarely revisited. They also forget that a quickly created test account is still part of the estate. Schedule a periodic sweep for accounts, regions and resources nobody can explain, and delete them. What you cannot see, you cannot patch.

How to check or apply this

1. Read your provider's shared responsibility documentation for each service you use.
2. Protect the root or owner account with multi-factor authentication, and do not use it day to day.
3. Use roles with short-lived credentials instead of long-lived keys, and apply least privilege.
4. Default deny on network rules. Open only needed ports to needed sources.
5. Build machines from hardened, regularly rebuilt images, and patch on a schedule.
6. Turn on audit logging for the account, send it to a separate protected store and set alerts.
7. Encrypt storage and manage keys with a service that has access policies.
8. Scan infrastructure code and images before deployment.
9. Review the account's resources regularly and remove what is not used.

Quick check

Sources

• NIST SP 800-145, The NIST Definition of Cloud Computing
• NIST CSRC Glossary, infrastructure as a service
• CISA Cloud Security Technical Reference Architecture

Last reviewed: 18 October 2026.