Does the Essential Eight apply to cloud and SaaS?

The most common objection to the Essential Eight is that it looks like an on-premises Windows framework. Application control, macro settings, Credential Guard — the vocabulary is unmistakably endpoint-centric, and organisations running mostly on cloud services conclude it barely applies.

That conclusion is wrong, and expensively so. The scope follows your data and your users, not your data centre.

The requirements that reach into cloud immediately

• Multi-factor authentication explicitly covers third-party internet-facing services that process, store or communicate your data — sensitive data from Level One, and where available for non-sensitive data too.
• Patch applications covers online services as a named class, with the tightest window in the framework: 48 hours where the vendor assesses the vulnerability as critical or a working exploit exists, two weeks otherwise.
• Restrict administrative privileges follows privilege wherever it lives. A global administrator in a cloud tenancy is a privileged account.
• Regular backups covers data you hold in cloud services. Provider redundancy is not a backup — it protects against their failure, not your deletion or encryption.

Between them, that is half the framework reaching straight into services you do not host.

What the provider covers, and what stays yours

Shared responsibility is the right mental model but it is often applied too generously to the provider:

• Infrastructure as a service: the provider handles the hypervisor and physical layer. Guest operating system patching, application control on those servers, and privileged access are entirely yours. An IaaS server is a server.
• Platform as a service: the provider patches the runtime; you remain responsible for the application, its dependencies and its access model.
• Software as a service: the provider patches everything. Your obligations are the configuration ones — MFA, privileged roles, data export for backup, and logging.

The trap is treating SaaS as fully outsourced. The provider patching their platform does not evidence your MFA scope, your privileged role membership, or your ability to restore data they will happily delete on your instruction.

The strategies that look inapplicable but are not

• Application control: applies to workstations regardless of where your servers live. Your users still have endpoints, and at Level Two and Three it extends to internet-facing and then all servers — including the ones you run in IaaS.
• Macros and user application hardening: these target the endpoint, which cloud adoption does not remove. Browser hardening arguably matters more when the browser is the primary interface to everything.
• Patch operating systems: applies to your IaaS instances exactly as it does to a rack.

The only case where a strategy genuinely narrows is a pure-SaaS organisation with managed endpoints and no servers at all — and even there, every endpoint requirement stands.

How to evidence what you do not operate

For provider-operated layers, evidence shifts from configuration to assurance and contract:

1. Enumerate the services first. You cannot evidence MFA scope without the list of third-party services holding your data. Build it from expenditure and identity-provider logs, not from memory — shadow IT lives here.
2. Classify what each holds. Sensitive or not, because that drives whether MFA is required or required-where-available.
3. Capture the provider assurance you rely on, and record what it does and does not cover.
4. Configure and evidence your side: MFA enforcement, privileged role membership and review, logging export, and data export for backup.
5. Record the boundary explicitly. A short statement per service of what the provider covers and what you retain answers the assessor question directly.

The gap that catches people

SaaS data backup. Providers protect against their own failures; they generally do not protect you from a user deleting a mailbox, a ransomware operator with valid credentials, or a malicious departure. Retention policies and recycle bins are not backups — they expire, and they are usually reachable by the same privileged accounts an adversary would compromise. The backup strategy applies to this data, including the Level Two requirement that privileged accounts other than backup administrators cannot delete it.

Key takeaways

• Scope follows your data and users, not your data centre.
• MFA and online-service patching reach third-party services from Level One.
• Provider redundancy is not a backup — it does not protect against your deletion.
• Enumerating the services you use is the prerequisite for evidencing anything.