Guide

CIS AWS Foundations Benchmark v5.0: a guide to the controls

What the CIS benchmark for AWS contains in version 5.0, section by section, what changed since v3.0, where to start and how to track your compliance over time.

Published September 27, 2026 · updated October 23, 2026 · 5 min read

What is the CIS AWS Foundations Benchmark?

The Center for Internet Security (CIS) publishes hardening benchmarks built by consensus among practitioners. The CIS AWS Foundations Benchmark describes the baseline configuration expected from an AWS account: identities, storage, logging, monitoring and networking.

Version 5.0.0 has 63 recommendations. It is the latest version supported by AWS Security Hub CSPM, whose CIS v5.0.0 standard is certified by CIS at levels 1 and 2 and automatically assesses part of the recommendations.
Each recommendation is either level 1 (a reasonable baseline for everyone) or level 2 (defence in depth, for sensitive environments).
Some recommendations are automated (checkable through the API), others manual (contact details, root user usage, review of peering routes).
The benchmark is not a certification: it is an assessment grid, often reused by external auditors.

The five sections of the benchmark

Sections of the CIS AWS Foundations Benchmark v5.0.0
Section	What it covers
1. Identity and Access Management	Root user, MFA, password policy, access keys, least privilege, IAM Access Analyzer, centrally managed identities.
2. Storage	S3 (HTTPS, MFA Delete, data classification, public access), RDS (encryption, updates, public access, Multi-AZ) and EFS.
3. Logging	Multi-region CloudTrail, log integrity and encryption, AWS Config, KMS key rotation, VPC flow logs, S3 object-level logging.
4. Monitoring	15 CloudWatch metric filters and alarms on sensitive events, Security Hub enabled.
5. Networking	EC2 (EBS encryption by default, CIFS access), NACLs and security groups on admin ports, default security group, VPC peering, IMDSv2.

What changed since v3.0

Sections 3 and 4 keep their numbering. Sections 1, 2 and 5 are renumbered: a gap reported as "CIS 1.10" in a v3.0 report is "CIS 1.9" in v5.0.

Main differences between CIS AWS Foundations v3.0.0 and v5.0.0
Topic	v3.0.0	v5.0.0
Account security questions	1.3	Removed; the following recommendations of section 1 move up one place
Root MFA / console users MFA	1.5 / 1.10	1.4 / 1.9
IAM Access Analyzer / AWSCloudShellFullAccess	1.20 / 1.22	1.19 / 1.21
EBS encryption by default	2.2.1 (Storage section)	5.1.1 (new EC2 subsection of Networking)
RDS / EFS	2.3.x / 2.4.1	2.2.x / 2.3.1, with a new recommendation 2.2.4 (Multi-AZ)
CIFS access (port 445)	Not covered	5.1.2: restricted to trusted networks
NACLs, security groups, peering, IMDSv2	5.1 to 5.6	5.2 to 5.7

In Security Hub, the v5.0.0 standard adds controls such as RDS.5 and RDS.15 (Multi-AZ) and EFS.8. Both versions can run at the same time: enable v5.0.0 before disabling v3.0.0, so the assessment has no gap.

Section 1: protect the root user and identities

This is the largest section, and the one where the most serious gaps are found.

Root user: no access keys (1.3), MFA enabled (1.4, hardware in 1.5), used only for the rare tasks that require it (1.6).
Passwords: at least 14 characters (1.7), no reuse (1.8).
MFA for every IAM user with console access (1.9), with no access key created at initial setup (1.10).
Unused credentials: disabled after 45 days (1.11); a single active key per user (1.12), rotated every 90 days (1.13).
Least privilege: permissions granted through groups (1.14), no policy granting *:* (1.15), a dedicated AWS Support role (1.16), instance roles rather than keys on servers (1.17).
IAM Access Analyzer enabled in all regions (1.19), to spot unintended external access.
Hygiene: expired SSL/TLS certificates removed from IAM (1.18), identities managed centrally through federation or AWS Organizations (1.20), AWSCloudShellFullAccess access restricted (1.21).

Section 2: storage

S3: unencrypted HTTP requests denied in the bucket policy (2.1.1), MFA Delete on critical buckets (2.1.2), Block Public Access at account and bucket level (2.1.4).
S3 data: discovered, classified and secured when necessary (2.1.3), for instance with Amazon Macie.
RDS: encryption at rest (2.2.1), automatic minor version upgrades (2.2.2), no public access (2.2.3), Multi-AZ deployment (2.2.4).
EFS: encrypted file systems (2.3.1).

Section 3: logging

CloudTrail enabled in all regions (3.1), with log file integrity validation (3.2) and encryption with a KMS key you manage (3.5).
Access logging on the S3 bucket receiving CloudTrail (3.4), and logging of S3 object writes and reads (3.8, 3.9).
AWS Config enabled in all regions (3.3).
Rotation enabled on symmetric KMS keys (3.6).
VPC flow logs enabled, at least for rejected traffic (3.7).

Section 4: monitoring

Recommendations 4.1 to 4.15 require a CloudWatch metric filter and alarm on CloudTrail logs, so you are alerted when:

API calls are denied, a console sign-in happens without MFA or fails, the root user is used;
an IAM policy, the CloudTrail or AWS Config configuration, or an S3 bucket policy changes;
a KMS key is disabled or scheduled for deletion;
a security group, NACL, network gateway, route table or VPC is modified;
the AWS Organizations structure changes.

Recommendation 4.16 requires Security Hub to be enabled. Security Hub does not check these metric filters itself: verify them separately. Without these alarms, an incident can go unnoticed for weeks.

Section 5: networking

EC2: EBS encryption by default enabled in every region (5.1.1), CIFS access (port 445) restricted to trusted networks (5.1.2).
No NACL (5.2) and no security group allows 0.0.0.0/0 (5.3) or ::/0 (5.4) to admin ports such as 22 (SSH) and 3389 (RDP).
The default security group of every VPC blocks all traffic (5.5).
VPC peering routes are limited to what is strictly needed (5.6).
EC2 instances require IMDSv2 for the metadata service (5.7).

Where to start

If you are starting from scratch, first close the major risks:

MFA on the root user, and removal of its access keys.
Multi-region CloudTrail with integrity validation.
S3 Block Public Access at account level.
Closing admin ports and port 445 open to the Internet.
MFA on every console access.
Then the section 4 alarms, which warn you if one of these settings is undone.

Track compliance over time

Enable the Security Hub CIS v5.0.0 standard in every region you use: it continuously re-evaluates the automated controls. If v3.0.0 is enabled, keep it until v5.0.0 has produced its first results.
Add AWS Config rules for the controls specific to your context.
Have the account audited regularly: the Silamir audit computes a CIS v5.0 score separate from the FSBP score, lists the failed controls with the affected resources and prioritises them with the other findings.

Where does your AWS account stand?

Ten questions, three minutes, no access to your account: a security score, a FinOps score and the article to read for each of your three weakest points. Your answers stay in your browser.

Take the free self-assessment

Ready to audit your AWS account?

Subscribe on AWS Marketplace, deploy the read-only role and get your reports within the hour.

Subscribe on AWS Marketplace See how it works