AWS Publishes Its New Secure-by-Default Account Model: A Checklist to Bring Existing Accounts Up to the Same Baseline

On 11 November 2026 AWS published “Ease of use and secure defaults in the new AWS experience” on the AWS Security Blog. It describes defaults applied to accounts created through the new getting-started flow. It is a description of AWS’s own product design, not a vulnerability report, and it makes no claims about attacks.

The AWS post describes these defaults for accounts created in the new flow and says nothing about existing accounts. Our inference is that older accounts do not receive them automatically, so this guide turns each default into a check you can run on an existing account.

What AWS said

AWS lists these defaults for the new experience:

• Builder ID sign-in with MFA available from the start. Each person signs in with a personal identity rather than a shared login, and MFA can be registered for whichever sign-in method is used.
• A managed organization. A new user lands in a project, which AWS describes as an account paired with its own spend limit and collaborators, created as a member account inside an organization AWS manages.
• A foundational data perimeter. AWS says access to resources from principals outside your organization is restricted by default, and that this is a starting point rather than the complete perimeter a larger organization would build.
• A single Region by default, assigned at sign-up, apart from globally scoped services.
• A hard spend limit per project, starting at $20 a month, with notifications. AWS says a project is paused when it reaches the limit.
• IAM Role Manager on by default, which creates and attaches roles with permissions that AWS says are “not meant to last forever” and that owners should right-size later.

AWS also says it is working on account-level S3 Block Public Access for newly created environments and gave no timeline. We do not treat that as shipped.

Checklist for existing accounts

Everything below is our suggestion, not AWS guidance from the post. Replace the placeholders and test in a non-production account first.

1. Confirm root and human sign-in protection

aws iam get-account-summary --query "SummaryMap.AccountMFAEnabled"

A result of 1 means the root user has MFA. This checks only the root user. Review your workforce sign-in separately, for example in IAM Identity Center. See our IAM Identity Center guide.

2. Put the account in an organization with guardrails

aws organizations describe-organization
aws organizations list-policies --filter SERVICE_CONTROL_POLICY
aws organizations list-policies --filter RESOURCE_CONTROL_POLICY

If the first command fails, the account is standalone. Our baseline SCP patterns are in AWS Organizations SCPs.

3. Approximate the data perimeter with a resource control policy

AWS does not publish its default perimeter policy in the post, so the policy below is our own illustration of an organization identity perimeter for S3, not AWS’s implementation. It denies S3 access to principals outside your organization, with exceptions for AWS service principals. Three behaviours to know before attaching it (from AWS’s RCP documentation; we have not tested the policy in an account):

• Anonymous requests are denied. Neither condition key is present on an anonymous request, so with the IfExists operators both conditions are true and the Deny applies. This breaks public buckets and public static website hosting.
• The service-principal exception is narrow. aws:PrincipalIsAWSService is true only for direct calls made by an AWS service principal. It is false for IAM roles used by services and for service-linked roles, so those are not exempt.
• The management account is not covered. RCPs do not affect resources in the organization’s management account.

Service integrations and cross-account partners can also break, so run it against CloudTrail history before attaching.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "EnforceOrgIdentityPerimeterS3",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-exampleorgid" },
      "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
    }
  }]
}

aws organizations enable-policy-type --root-id r-exampleroot --policy-type RESOURCE_CONTROL_POLICY
aws organizations create-policy --name s3-identity-perimeter --description "Org identity perimeter for S3" \
  --type RESOURCE_CONTROL_POLICY --content file://rcp-s3-perimeter.json
aws organizations attach-policy --policy-id p-examplepolicy --target-id <ou-or-account-id>

Review this against the AWS data perimeter documentation before use; the exact exception set depends on your integrations.

4. Restrict Regions you do not use

AWS says the new experience starts with a single home Region. For an existing organization, an SCP can approximate that with the aws:RequestedRegion condition key. Exempt global services in a NotAction list. See the SCP guide linked above, and check the list of global services against current AWS documentation.

5. Block public S3 access at the account level

AWS said this protection is in progress for new environments. You do not have to wait for existing accounts.

aws s3control put-public-access-block --account-id <account-id> \
  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
aws s3control get-public-access-block --account-id <account-id>

Check for buckets that rely on public access first, because this setting will break them. Our S3 ransomware hardening guide covers related bucket controls.

6. Add a spend alert

AWS describes a hard limit that pauses a project. In an existing account, AWS Budgets alerts notify by default, and AWS Budgets actions can enforce a limit, for example by automatically applying an IAM policy that denies provisioning additional resources (see the AWS Budgets documentation linked below). The example below creates an alert only. AWS itself notes that unexpected spend is a classic indicator of inappropriate access or a runaway process.

aws budgets create-budget --account-id <account-id> \
  --budget file://budget.json --notifications-with-subscribers file://notifications.json

{
  "BudgetName": "monthly-cost-guardrail",
  "BudgetLimit": { "Amount": "100", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}

notifications.json is a list of entries, each with a Notification (for example NotificationType ACTUAL, ComparisonOperator GREATER_THAN, Threshold 80, ThresholdType PERCENTAGE) and a Subscribers list (for example SubscriptionType EMAIL and an Address).

7. Right-size starter roles

AWS says its generated roles are a starting point. Whatever tool created a role, review what it actually uses.

aws iam generate-service-last-accessed-details --arn arn:aws:iam::<account-id>:role/<role-name>
aws iam get-service-last-accessed-details --job-id <job-id>

Remove services the role has not accessed in a period you choose. Permission boundaries help cap what role creators can grant; see our permission boundaries guide.

Limits

The AWS post is a design statement. It gives no details on how the perimeter is implemented and no measurements of security outcomes. The checks above are our own mapping, not a verified equivalent of the new experience.

References

• AWS Security Blog: Ease of use and secure defaults in the new AWS experience
• AWS documentation: Resource control policies
• AWS documentation: Blocking public access to Amazon S3 storage
• AWS documentation: Managing costs with AWS Budgets