Cyber Essentials for AWS: configuration guide

Cyber Essentials v3.3 treats AWS accounts you administer as in-scope cloud services. Verify effective human cloud MFA, needed privileges, network controls, supported software and required fixes. AWS Foundational Security Best Practices in Security Hub is optional supporting diagnostics, not a scheme product mandate.

Under the shared responsibility model AWS is responsible for the cloud itself; you are responsible for what you put in it. Cyber Essentials assesses your portion:

• All IAM users, groups, roles, and the root account
• Every AWS account under your control (Organizations, member accounts)
• EC2 and ECS/EKS workloads you operate at the OS or container level
• Security Groups, NACLs, and any customer-configured network boundary
• Data stores you configure - RDS firewall rules, S3 bucket policies

• Root account: MFA enforced using an AWS-supported method; passkeys/security keys are recommended, not a scheme hardware-only rule. Minimise root use and remove unnecessary credentials according to the actual supported account design.
• Human users: verify effective MFA for console/CLI authentication, including federated sessions. Workload identities and machine keys are a different flow; prefer suitable roles and short-lived tokens, and manage necessary keys securely rather than claiming interactive MFA on every programmatic operation.
• No wildcard admin policies attached to users. Use groups, and attach narrow permissions-boundary policies.
• Password policy: a fourteen-character local policy can be stronger hardening; it is not a universal scheme minimum. Apply full password controls and an applicable quality route: MFA, twelve-plus characters, or eight-plus with a common-password deny list. Federated identities inherit supported IdP policy.

Evidence: IAM credential report CSV, screenshot of the account password policy, SCP documents if using Organizations.

If you use AWS Organizations, SCPs can be among your strongest secure-configuration controls for a suitable architecture. These are illustrative optional guardrails, not a mandatory scheme list:

• Deny root user actions except for break-glass paths.
• Review regional restrictions carefully: IAM is a global service; account for global-service exceptions rather than describing users as regional resources.
• Deny public S3 bucket policies unless in an allow-listed account.

Well-scoped SCPs can provide some of the cleanest preventive-policy evidence. Check effective inheritance, exceptions and observed resource state; this is practical advice rather than a universal evidence ranking.

Consider AWS Security Hub and the AWS Foundational Security Best Practices standard for diagnostic coverage. Findings are not a one-to-one scheme mapping; review actual controls, for example:

• Default security groups open
• Publicly accessible RDS / Redshift / ElastiCache
• Unencrypted EBS volumes
• S3 block-public-access not enforced account-wide

An AWS Foundational Security Best Practices score target is local planning, not a scheme pass threshold or permission to leave required controls failing.

• Security Groups: explicit allow, deny-by-default. No 0.0.0.0/0 on 22 (SSH), 3389 (RDP), 1433/3306/5432 (databases).
• Prefer AWS Systems Manager Session Manager over opening SSH at all - no inbound SSH exposure and IAM-gated access where configured. Recording depends on session type and configuration; SSH/port-forwarding sessions do not provide the same session-content logging.
• Default VPC: either delete it or harden it. A default security group permits inbound traffic from members of the same group and generally allows outbound traffic; that differs from unrestricted public inbound access. Review actual rules.

• Systems Manager Patch Manager scanning all EC2 instances with Patch Groups aligned to maintenance windows.
• Apply vendor-approved vulnerability fixes within 14 days of release when the vendor calls the vulnerability high/critical, its CVSS v3 base score is 7 or above, or the vendor gives no severity details. Enable automatic updates where possible. Cover OS, applications and other in-scope software; a patch-level age or deferral setting alone does not establish compliance. Patch Manager baseline approval delays do not prove installation/restart timing; verify current baseline rules and actual coverage.
• AMIs regularly refreshed - golden images older than 90 days raise a flag.

Not strictly mandated by Cyber Essentials but strongly supportive:

• CloudTrail enabled in all regions with log file integrity validation.
• Config Recorder on for every region you use.
• GuardDuty catches the detective-control questions assessors sometimes ask about malware and credential exfiltration.

1. Unnecessary or poorly protected root credentials. Follow supported AWS root-account controls; do not invent a scheme instant-fail rule solely from key existence.

2. Long-lived IAM access keys on developer accounts. Rotate, or (better) replace with IAM Identity Center.

3. Security Group allows 0.0.0.0/0 on 22 or 3389 on at least one production instance. Usually legacy bastion hosts - replace with Session Manager.

4. End-of-support AMIs. Check the exact release and active vendor extended-support entitlement, including Ubuntu ESM where applicable; unsupported software must be removed or meet the no-internet-traffic exclusion condition.

The readiness check supports preparation. Share relevant scoped IAM, network, support and fix evidence when requested. Exact report ingestion and first-time rates need service/cohort records; a Security Hub score or scan does not guarantee certification.

Start Cyber Essentials - from £299.99 + VAT | Full pricing | Small business CE Plus