SecHB security, privacy & compliance

AWS security baseline: the first 20 settings

A secure AWS baseline is mostly settings, not products: lock down the root user, send people through single sign-on, log every account to somewhere an intruder cannot reach, and close the switches that make data public by accident. The twenty below are the ones we switch on first, in order. Most take minutes; the hard part is doing all of them in every account and Region.

How should you lock down root and identity?

  1. MFA on the root user, ideally a hardware key (IAM.9, IAM.6), with the sign-in email a group address rather than a person.
  2. No root access keys. Delete any that exist (IAM.4).
  3. Centrally manage root access in an organization, removing root credentials from member accounts altogether.
  4. People sign in through single sign-on, which AWS names IAM Identity Center, federated to your identity provider, rather than as IAM users.
  5. Workloads use IAM roles and temporary credentials. Any long-lived access key is an inventoried exception.
  6. A security contact on every account (Account.1), so a notice reaches someone who will act on it.

AWS’s own root user best practices and IAM best practices are the source for these.

Which organization guardrails should you set?

  1. Separate accounts for workloads, log archive and security tooling, with service control policies setting the maximum permissions: no leaving the organization, no disabling CloudTrail or GuardDuty, no unused Regions.
  2. IAM Access Analyzer for external access across the organization (IAM.28), and a regular pass over unused access.

What logging and detection should be on?

  1. An organization CloudTrail trail, multi-Region, with management events (CloudTrail.1). Event history alone keeps only 90 days of management events.
  2. Log file validation on and the trail encrypted (CloudTrail.4, CloudTrail.2), delivered to the log archive account.
  3. GuardDuty in every account and every Region you use.
  4. Security Hub CSPM with the AWS Foundational Security Best Practices and CIS AWS Foundations Benchmark standards enabled.
  5. AWS Config recording (Config.1). Security Hub CSPM uses Config rules for most of its controls, so without it most of those checks cannot run.
  6. VPC flow logs for every VPC (EC2.6).

How do you stop data being made public by accident?

  1. S3 Block Public Access at account or organization level (S3.1). New buckets are private by default, but a bucket policy can still open one; the account setting overrides it.
  2. EBS encryption by default (EC2.7). It is set per Region and does not touch existing volumes.
  3. Block public sharing of EBS snapshots and AMIs in each Region.
  4. Databases not publicly accessible and encrypted at rest (RDS.2, RDS.3).

Which compute and network defaults should change?

  1. IMDSv2 as the account default in each Region (EC2.8). The default applies to new instances only; existing ones need changing.
  2. No administration ports open to the internet (EC2.53, EC2.54), and default security groups closed (EC2.2).

The control IDs are those Security Hub CSPM lists, as of September 2026, for the CIS AWS Foundations Benchmark v5.0.0, so each item maps to a check you can run.

Which AWS settings should you fix first?

Which settings matter most on day one? Root MFA with no root access keys, human access through single sign-on, and an organization-wide CloudTrail trail. Those three decide whether an attacker can take the account and whether you can see what happened if one does. Everything else improves a position those three make defensible.

The common mistake is treating a green dashboard as the finish line. Does a clean Security Hub score mean you are secure? No. It means the configuration checks it runs are passing. It says nothing about what your application exposes, whether your IAM policies are sensibly scoped, or whether anyone reads the findings. Decide who owns GuardDuty and Security Hub findings before you switch them on.

The second is fixing by hand. Put the baseline in code so a new account inherits it; our Terraform security checklist covers that side. How identity and network controls fit together is in zero trust without buying a product, and an independent look at an existing estate is a cloud security review.

How the work is bounded

The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.

SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.

Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.

Questions we are asked

Which settings matter most on day one?

Root MFA with no root access keys, human access through single sign-on, and an organization-wide CloudTrail trail. Those three decide whether an attacker can take the account and whether you can see what happened if one does.

We only have one AWS account. Does this still apply?

Yes, apart from the settings that need AWS Organizations. Moving to an organization early is easier than moving later, because logs and security tooling can then sit in accounts that workload administrators cannot touch.

Is this the same as the CIS AWS Foundations Benchmark?

It overlaps heavily with it. The benchmark is a scored list of checks, which Security Hub CSPM can run for you; this page is the order we would switch things on in a new or neglected account.

Does a clean Security Hub score mean we are secure?

No. It means the configuration checks it runs are passing. It says nothing about what your application exposes, whether your IAM policies are sensibly scoped, or whether anyone reads the findings.

Check your baseline

Send us a Security Hub CSPM export or a description of your account structure. The reply says which of the twenty are missing and which to fix first. More of our writing is indexed at writing.

Discuss a scope