Security 1 publisher2 min readPublished September 17, 2026 at 1:28 PM PDT

AWS's new sign-up flow hides two of the three accounts it creates

Wiz's walkthrough of AWS's new sandboxed sign-up finds an Organization management account and an identity account the customer cannot see, a $20 monthly budget tied to a deny policy, and six AWS security services blocked outright.

The Watch · Security desk

What happened

AWS's new sign-up experience creates three AWS accounts inside an AWS Organization, and its blog post calls the result a Project.
No CloudTrail is configured at either the account or the Organization level, leaving CloudTrail Event History as the record of activity.
The sandbox denies GuardDuty, SecurityHub, Detective, Inspector, Macie and Access Analyzer, including their free features, while permitting Config and CloudTrail.

Compiled by The WatchSomething wrong?How this is made

Why it matters

exposure An attacker working inside a sandbox project is in an environment where the owner cannot switch on GuardDuty or Access Analyzer to find out what was touched.
constraint Response work in the sandbox runs on 90 days of Event History through a limited console view, with nothing landing in a bucket the customer controls.
decision Teams that need a security baseline have to leave the sandbox to get one, so the upgrade is a security decision as much as a spending one.
precedent New sign-ups now start inside an Organization someone else administers, making the Organization, not the account, the default boundary a new customer inherits.

The policy that constrains a sandbox project lives in an account its owner cannot open. AWS applies SCPs and RCPs to the customer's member account from the Organization management account, and the customer has no access to that account while the project sits in the sandbox ^[3]. Visibility arrives with the upgrade: Wiz got access to the management account, then read the setup artifacts and the CloudTrail Event History ^[5]. Three of the sandbox SCPs are documented by AWS, and one of them, covering account contact information and settings controlled by the new settings.aws.com, is removed on upgrade ^[16].

Two of the three accounts stay out of view: the management account and an identity account ^[2]^[1].

Logging is the thin part. No CloudTrail trail is configured at the account or the Organization level ^[6]. What remains is CloudTrail Event History, 90 days of events through a limited interface ^[7]. The sandbox denies GuardDuty, SecurityHub, Detective, Inspector, Macie and Access Analyzer, free features included ^[8], and allows Config and CloudTrail ^[9]. Of the eight AWS security services named in the post, six are blocked ^[2].

The old mistakes are still available. Wiz created an IAM user with an access key, though AWS warned against it, and could not give that user a console password ^[10]. A public S3 bucket worked after turning off the bucket-level Public Block Access, which is on by default for new buckets while the account-level setting is off ^[11]^[13]. An EC2 instance with IMDSv1 launched after the default was changed away from IMDSv2-only ^[12].

No CVE is involved here. The exposure is a long-lived access key in an account where the owner cannot enable a threat detection service and the record of activity is a 90-day console view ^[8]^[7]. Wiz expected Control Tower behaviour with the security features switched on, and found a sandbox aimed at a simplified experience and cost control ^[18]. The $20 monthly budget is wired to an SCP called BudgetsSpendLimitDenyNewWorkloads, which denies more than a hundred actions, mostly the creation of compute; the budget is removed when the account leaves the sandbox ^[14]^[15].

Wiz wrote that "a strong security posture still requires upgrading out of the sandbox" ^[17]. One piece of that does not wait for the upgrade: CloudTrail is on the allowed list, so a customer can create a trail inside the sandbox even though none is configured for them ^[9]^[6].

What to watch

Whether AWS publishes the full set of SCPs and RCPs applied from the hidden management account so sandbox customers can read the policy that constrains them.
Whether the sandbox deny list ever extends to Config or CloudTrail, removing the last logging option available inside it.
Whether sandbox projects start appearing in leaked-credential incidents where the only available record is 90 days of Event History.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
AWS's new sign-up experience creates three AWS accounts that are part of an AWS Organization; AWS's blog post refers to a new account as a Project.
ReportedSupportedSource: Wiz blog post 'Exploring the new AWS Sign Up experience'View cited source
[2]
AWS gives the customer access to one of the member accounts while hiding the Organization management account and the other member account, which is an identity account.
ReportedSupportedView cited source
[3]
The customer has no access to the Organization management account, but AWS uses that account to apply SCPs and RCPs to the sandboxed account.
ReportedSupportedView cited source
[4]
While in the sandbox the customer does not have much visibility into what was set up.
ReportedSupportedView cited source
[5]
Once the account is upgraded, the customer is given access to the Organization management account; from there Wiz was able to look at the artifacts of what had been done and review the CloudTrail Event History.
ReportedSupportedView cited source
[6]
There is no CloudTrail configured, at the account or the Organization level.
ReportedSupportedView cited source
[7]
CloudTrail Event History is still present, which gives 90 days of events through a limited interface.
ReportedSupportedView cited source
[8]
The sandbox denies access to GuardDuty, SecurityHub, Detective, Inspector, Macie and Access Analyzer, including their free features.
ReportedSupportedView cited source
[9]
AWS Config and CloudTrail are allowed in the sandbox.
ReportedSupportedView cited source
[10]
Wiz was able to make an IAM user with an access key, with warnings shown, but was prevented from setting a password for that IAM user for console sign-in.
ReportedSupportedView cited source
[11]
Wiz was able to make a public S3 bucket after turning off the bucket-level S3 Public Block Access.
ReportedSupportedView cited source
[12]
Wiz was able to launch an EC2 instance with IMDSv1 after changing the default from IMDSv2 only.
ReportedSupportedView cited source
[13]
S3 Public Block Access is not enabled at the account level in the sandbox, but is enabled by default at the bucket level when new buckets are created.
ReportedSupportedView cited source
[14]
While in the sandbox, AWS creates a Budget of $20 per month with an associated action that applies the SCP BudgetsSpendLimitDenyNewWorkloads if the Budget will be breached; that SCP denies over one hundred actions, mostly associated with creating compute resources such as EC2 instances.
ReportedSupportedView cited source
[15]
Once the account is upgraded out of the sandbox, the $20 Budget is removed.
ReportedSupportedView cited source
[16]
Three of the sandbox SCPs are documented in the AWS docs; one is removed once the account is upgraded and protects some of the account contact information and other settings controlled by the new settings.aws.com.
ReportedSupportedView cited source
[17]
"a strong security posture still requires upgrading out of the sandbox"
ReportedSupportedSource: Wiz blog postView cited source
[18]
Wiz's initial assumption was that the new sign-up experience would be like Control Tower with all security features enabled, and found instead that the sandbox is focused on providing a simplified experience and limiting costs.
ReportedSupportedView cited source
[d1]
Of the three accounts created at sign-up, two are hidden from the customer.
DerivedSupported1 source— sign in to open
[d2]
Of the eight AWS security services named in Wiz's post, six are denied in the sandbox and two are allowed.
DerivedSupported1 source— sign in to open
[19]
The expectation is that people new to AWS try AWS inside the sandbox and upgrade once they hit its restrictions, such as budget controls and restrictions on services they can use.
ReportedInsufficientView cited source

Sources

Publishers with included, body-backed reporting in this cluster.

wiz.io
1 article · September 17, 2026
Exploring the new AWS Sign Up experience

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Wiz signed up through AWS's new flow and wrote down what it got: three accounts in an Organization, one of them usable, and no CloudTrail trail. For anyone building on a fresh account the operative items are the FreeTierSCP allowlist and the resource control policy that denies sts:AssumeRole from outside the Organization. The allowlist blocks GuardDuty, Security Hub, Detective, Inspector, Macie and Access Analyzer even at their free tiers. That second policy breaks any third-party integration built on cross-account IAM roles until the account is upgraded and the policy edited. The sandbox still permits an IAM user with an access key, a public S3 bucket and an EC2 instance running IMDSv1, each behind a warning screen. Wiz does not say when the new flow became the default.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence66

0100

First-hand, one account, unreplicated

The specifics are the kind you can only get by doing it: policy names such as FreeTierSCP and AdvancedModeRegionRestrictionSecurityControlPolicy, the $20 cap and the SCP its budget action applies, the six denied services. Wiz got them by signing up, then reading the management account's own record after upgrading, and three of the SCPs are cross-checked against AWS documentation. It is still one account, at one moment, with no confirmation from AWS and nobody repeating the exercise.

Adoption28

0100

Flow is live, scope unknown

The new experience works end to end for at least one real customer path: Wiz signed up, operated inside the sandbox, and upgraded out of it into the management account. How widely AWS has rolled the flow out, and whether it is now the default for every new sign-up, is unknown from this reporting, so the score stays low.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

build
AWS says GuardDuty catches the universal attacks. The rest is your detection engineering.
1 publisher
build
Object Lock in the PDNS rebuild has to be checked before the bucket exists
1 publisher
build
AWS's SIRT traced one SSRF bug to Bedrock calls in a second Region
1 publisher
build
GuardDuty says exfiltration and the patch is four hours out: revoke the sessions first
1 publisher

AWS's new sign-up flow hides two of the three accounts it creates

What happened

Why it matters

What to watch

Claim ledger

Sources

Topics and entities

Topics

Entities

Claim ledger

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Sources

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Related stories

Sources