The ASD Essential Eight was written with on-prem Windows environments in mind, which makes "achieve Maturity Level 3 on AWS" a translation exercise. Some strategies map almost directly to AWS services; others change shape entirely when there's no fleet of desktops to patch. Here's the practitioner mapping at Maturity Level 3 — the highest tier.
Practitioner guidance, not legal or audit advice. The Essential Eight is maintained by the ACSC; validate against the current Maturity Model for your context.
The eight, translated to AWS
| # | Essential Eight strategy | What ML3 looks like on AWS |
|---|---|---|
| 1 | Application control | Allow-listed AMIs/containers; SSM to enforce approved software; deny-by-default on what runs |
| 2 | Patch applications | Inspector for vulnerability findings; SSM Patch Manager on a defined SLA; container image scanning in ECR |
| 3 | Configure macro settings | Largely N/A for cloud workloads — applies to any managed desktops (WorkSpaces), enforce via GPO/MDM |
| 4 | User application hardening | Hardened base images (CIS-benchmarked AMIs); WorkSpaces hardening; browser/runtime controls |
| 5 | Restrict admin privileges | IAM least-privilege, Identity Center, SCPs, just-in-time access; no standing admin |
| 6 | Patch operating systems | SSM Patch Manager with ML3 cadence; ec2-managedinstance-patch-compliance-status-check; immutable infra where possible |
| 7 | Multi-factor authentication | MFA enforced on all human identities; phishing-resistant (FIDO2) for privileged at ML3 |
| 8 | Regular backups | AWS Backup with tested restores; immutability (Vault Lock); cross-region/cross-account copies |
The three that actually take work on AWS
Most teams handle MFA and backups. The ones that decide your maturity level:
Restrict admin privileges (strategy 5)
ML3 means no standing administrative access. On AWS that's IAM Identity Center permission sets with just-in-time elevation, SCPs that prevent privilege escalation, and Access Analyzer proving no unintended access paths. Standing AdministratorAccess attached to a human is an automatic ML3 fail.
Patch operating systems & applications (strategies 2 and 6)
ML3 demands tight patch windows and evidence of compliance. SSM Patch Manager gives you both the enforcement and the patch-compliance report that proves it — and Inspector covers the vulnerability-discovery half. The immutable-infrastructure pattern (replace, don't patch) sidesteps a lot of this, and ML3 assessors generally accept it as equivalent.
Application control (strategy 1)
The hardest to evidence in cloud. At ML3 you need allow-listing of executable content. For container and serverless workloads this becomes image provenance (signed images, ECR scanning, admission control); for EC2 it's SSM-enforced software inventory against an approved list.
How this connects to CPS 234
For APRA-regulated entities, the Essential Eight and CPS 234 overlap heavily — restrict-admin, patching, MFA, and backups all appear in both. Treat them as one control set with two reporting views, not two separate programs. The evidence (patch-compliance reports, IAM credential reports, backup-restore test results) serves both.
A diagram mapping all eight strategies to an AWS reference architecture is coming to resources. Want your estate assessed against both the Essential Eight and CPS 234 in one pass? That's what a readiness assessment covers.