Mapping the ACSC Essential Eight onto real AWS services.

Australian organisations increasingly meet the Essential Eight through procurement rather than regulation. A government tender asks for a maturity level; an enterprise customer's security review asks the same. Then somebody has to work out what "application control" means for a platform that has no user workstations in scope.

What follows is how we translate it in practice. It is not a determination for your system — scope must be agreed with your assessor, and that conversation should happen before you spend anything.

Start with the scope argument

Four of the eight strategies — application control, configure Microsoft Office macro settings, user application hardening, and to a large extent restrict administrative privileges as originally framed — assume end-user computing devices.

If your assessment boundary is a SaaS platform running on AWS with no managed desktop fleet, several of these are either out of scope or satisfied trivially. Getting that agreed in writing at the start is worth more than any single control implementation, because the alternative is scoping work for controls that do not apply to you.

Where an organisation does have a corporate desktop fleet, that fleet is usually a separate system with a separate boundary. Conflating the two is the most common scoping error we see, and it inflates programmes by months.

The four that carry the weight

1. Patch applications

In cloud terms this is your container images, your Lambda runtimes and your application dependencies — not a desktop patching agent.

• Amazon Inspector for continuous vulnerability assessment across EC2, ECR images and Lambda
• Image scanning as a pipeline gate, not a report — a critical CVE fails the build
• Base image rebuild cadence, so patching is a rebuild rather than a mutation
• A patch SLA per severity, with exceptions registered against a named owner and an expiry date

Where it usually falls down: the exception register. Level 2 asks for patching within two weeks for internet-facing services. Most organisations can hit that for the main application and cannot for the one legacy component nobody wants to touch. An exception with an owner and a date is defensible; a silent gap is not.

2. Patch operating systems

• Systems Manager patch baselines per environment, with maintenance windows
• Compliance reporting so coverage is a number, not an assertion
• Immutable AMI pipelines where the workload permits — the strongest answer available, because a rebuilt host cannot drift

Where it usually falls down: instances outside Systems Manager entirely, typically because the agent was never installed on something built before the policy existed. The reported coverage percentage looks fine because it is a percentage of the hosts being counted.

3. Multi-factor authentication

Straightforward to implement on AWS and straightforward to get wrong in one specific way.

• IAM Identity Center federated to your identity provider, MFA enforced there
• Service control policy denying IAM user and access key creation entirely
• Root account credentials in a break-glass procedure with hardware MFA
• Machine identities via IAM roles and OIDC federation from CI — never keys

Where it usually falls down: long-lived access keys. Human MFA is enforced, and there are forty programmatic keys with broad permissions and no rotation. An assessor will find these in the first hour. On one recent engagement we removed sixty-three, four of which carried administrator policies.

4. Restrict administrative privileges

• Permission boundaries so delegated administrators cannot escalate
• No standing production administrator access — just-in-time elevation, time-boxed
• Session logging for privileged access, stored outside the account being accessed
• Regular access review with automated removal of unused permissions

Where it usually falls down: break-glass roles used routinely because the normal path is too slow. If elevation takes twenty minutes and a form, people will find another way, and your logs will show it. Fix the friction rather than writing a policy about it.

And the fifth that matters more than people expect

Regular backups

Everyone claims this one and it is where we find the most serious gaps, because backup success is measured and restore capability generally is not.

• AWS Backup with policy per workload, mapped to an agreed RTO and RPO
• Vault Lock for immutability, in an account separate from the workload
• Restore testing on a schedule, with the result written down
• The recovery path documented and tested independently of the environment being recovered

Where it usually falls down: backups that complete successfully and cannot be restored — because nobody has tried, or because the restore depends on a credential, a network path or a licence that only exists in the environment being recovered. Ransomware resilience in particular requires that the backup account be outside the blast radius of the credentials that would be compromised.

On maturity levels

Level 1 is a reasonable baseline for most commercial organisations. Level 2 is what government tenders commonly ask for. Level 3 is a significant undertaking and is usually only justified where the threat model genuinely warrants it.

For a cloud-native platform with no desktop fleet in scope, Level 2 across the applicable strategies is typically eight to fourteen weeks of work. That estimate collapses or doubles depending entirely on the scope conversation described at the top of this article — which is why it should be the first thing you do, not the last.

The single highest-return item

If you do one thing after reading this: enumerate your long-lived IAM access keys, and the permissions attached to each one.

It takes an afternoon, it is the finding an assessor will open with, and on most estates the result is genuinely uncomfortable.