A Flat Cloud Account Is Not a Blast-Radius Design

“Everything runs in one cloud account behind security groups, and our posture tool watches it, so we are segmented.”

Let me stop you before that sentence goes into the architecture decision record.

A flat cloud account is not a blast-radius design.

You have network rules inside a boundary.

You have a tool that reads those rules.

What you do not have is the boundary your provider was already offering you, enforced by default.

AWS’s own multi-account guidance describes an account as an isolation boundary for identity and access management.

By default, no access is allowed between accounts.

Not even between accounts in the same organization.

Cross-account access has to be granted explicitly.

That is a default-deny boundary the platform enforces whether or not anyone on your team remembered to write a rule.

Put every workload in one account and you have declined it.

Then you rebuild some version of it out of security groups and IAM policies, and hope every one of them stays right.

Nobody would say “we keep all the tenants’ records in one filing cabinet, but we labelled the folders very clearly.”

Put the filing cabinet in a cloud region and it becomes a segmentation strategy.

1. “But Security Groups Already Isolate the Workloads.”

They draw a network boundary inside the account.

That is useful.

It is also a boundary you configured, and one you have to keep configured.

The difference is not strength of a single rule.

The difference is which way the default points.

Between two accounts, nothing is allowed until somebody grants it.

Inside one account, the separation between workloads is whatever the current rule set and the current policy set happen to say.

One rule opened for a migration, one policy scoped to * because a deploy was failing on a Friday, and the separation is gone.

Nothing announces it.

The workloads keep running.

They are simply no longer separated.

Security architecture has names for this at three scales.

A DMZ separates internet-facing services from the internal network.

Microsegmentation puts the boundary at the individual workload, so two hosts on the same subnet cannot reach each other without an explicit rule.

A landing zone treats the account, subscription or project as the primary trust boundary, because that boundary carries default-deny isolation the provider itself enforces.

Security groups belong to the first two.

They don’t substitute for the third.

The question every boundary answers is the same: what should this stop a compromise from reaching?

In a flat account, the honest answer for most workloads is “whatever the rules forgot.”

2. “But the Posture Tool Alerts Us to Any Misconfiguration.”

It alerts you.

That is the whole of its authority.

CSPM and CNAPP tools, whatever the brand, work the same way.

They read configuration state through the provider’s own APIs and flag drift against a policy baseline.

They cannot alter the provider’s infrastructure.

They cannot compel you to remediate a finding.

They surface the misconfiguration. They don’t own the fix.

A finding is an observation about a boundary.

It isn’t the boundary.

Consider what the posture tool is watching in a flat account.

It is watching the only thing standing between your workloads: tenant configuration.

That is precisely the layer where cloud failures concentrate.

The Cloud Security Alliance’s 2024 Top Threats survey, drawing on more than 500 practitioners, ranked “Misconfiguration and inadequate change control” first among eleven named threats.

“Identity and Access Management” came second.

So the design has moved all of its isolation into the top-ranked failure category, and assigned a read-only tool to watch it.

Also worth stating plainly: the posture-tool business is continuous monitoring of a gap.

It isn’t a one-time fix, and its product does not stop being needed when you ignore its findings.

A dashboard of open findings with no owner and no deadline is a record of drift.

Nobody would say “the smoke detector is loud, so the building has fire doors.”

Put the smoke detector in a SaaS console and it becomes a compartmentalization control.

3. “But Multiple Accounts Are an Operational Headache.”

They are operational work.

That isn’t the same sentence.

The landing-zone pattern exists so that the work is done once, centrally, and inherited.

AWS frames it as a multi-account strategy: separate production from non-production, one business line from another, because the account’s default-deny boundary limits what a compromise in one account can reach without any additional network control.

Its guidance describes organizations ranging from a handful of accounts to thousands, depending on how finely they choose to draw the line.

A handful is allowed.

Azure structures it as one platform landing zone per Microsoft Entra tenant, centralizing governance, identity, connectivity and security monitoring.

Each workload gets its own application landing zone, with its own subscriptions for development, test and production.

Each subscription sits under a management group, Online, Corp or Local, and inherits policy from where it sits in the hierarchy.

Workload teams don’t share a subscription, and they don’t each rebuild governance either.

Google Cloud does it with its resource hierarchy.

Organization at the root, optional folders for departments or business units, and projects as the unit that actually holds the virtual machines and buckets.

Policies set at the organization or folder level cascade down automatically, so the same hierarchy bounds blast radius and governance scope together.

Three providers.

Three different units of isolation.

One idea.

The headache argument usually compares a governed multi-account estate against a flat account that has never had an incident.

Compare it against the flat account on the day something inside it is compromised, and the operational cost moves to the other column.

4. “But Our IAM Policies Are Least-Privilege.”

Good.

Keep them that way.

But notice what you are relying on.

Inside one account, the only thing separating the payments service from the marketing site’s build job is the correctness of every policy that names either of them.

Every one.

Continuously.

Across every change anyone makes.

That is least privilege as a property you must re-prove after each deployment.

The account boundary is a property you get by default and have to break deliberately.

Then there are the credentials the policies are attached to.

A static, long-lived credential embedded in a workload is a standing liability.

Whoever obtains it holds its permissions until someone notices.

Workload identities exist to remove that standing credential.

AWS’s own IAM documentation names the failure this class of identity is designed to prevent: the confused deputy problem, where a service holding legitimate permissions is tricked into misusing them on an attacker’s behalf.

The three providers don’t solve it the same way.

AWS issues temporary session credentials for a role.

Azure binds a managed identity to a resource’s lifecycle.

Google Cloud’s workload identity federation exchanges an external token for access.

Three distinct designs, not three brand names for one mechanism.

What they share is that migrating a workload onto any of them is engineering work, competing with delivery for the same attention.

Until that work is done, your least-privilege policy is attached to a key sitting in a config file.

And in a flat account, a confused deputy with a broad role is confused across everything in the account.

5. “But the Provider Secures the Infrastructure Under the Account.”

It does.

AWS is responsible for protecting the infrastructure that runs its services: hardware, host operating system patching, the virtualization layer, networking infrastructure and facilities.

You configure what sits on top of that layer.

You cannot inspect or alter what sits underneath.

That is exactly why the account boundary matters.

NIST SP 800-145, the 2011 definition of cloud computing, lists resource pooling as an essential characteristic: provider resources pooled to serve multiple consumers using a multi-tenant model.

Multi-tenancy is not a side effect of how clouds happen to be run.

It is in the definition.

The provider has already built the machinery that keeps one customer’s account away from another’s.

It exposes the same kind of boundary to you, between your own accounts, subscriptions and projects.

A flat account uses the provider’s isolation to keep strangers out and nothing to keep your own workloads apart.

And the provider’s responsibility for infrastructure does not extend to the configuration you put inside the account.

Where a regulator has had to decide, as in Capital One’s case, the penalty landed on the tenant, not the provider.

6. “But We Use SaaS for the Sensitive Parts, So the Provider Carries That Risk.”

It carries more of the controls.

It doesn’t carry your exposure.

In the summer of 2023, a threat actor Microsoft tracks as Storm-0558 compromised a Microsoft Services Account signing key.

It used that key to forge authentication tokens for specific Exchange Online mailboxes, including accounts at the US Department of State, the Department of Commerce and the US House of Representatives.

Microsoft did not detect it.

The Department of State, a customer, did, and reported it to Microsoft.

The US Cyber Safety Review Board’s review found that “Microsoft’s security culture was inadequate and requires an overhaul,” and that Microsoft “failed to detect the compromise of its cryptographic crown jewels on its own, relying instead on a customer.”

Exchange Online is SaaS.

The customer had essentially no configuration surface to get wrong.

It still had a blast radius, and that blast radius included a provider-held key the customer could not design around at all.

Moving a workload to SaaS moves controls into the provider’s column.

It doesn’t move your data out of the blast radius of the provider’s identity system.

That is not an argument against SaaS.

It is an argument for writing down which provider keys and identity systems sit inside your blast radius, and what you would see if they were misused.

The Department of State saw something.

That is how Microsoft found out.

7. No, This Does Not Mean Every Workload Needs Its Own Account.

It doesn’t.

And account separation does not replace network segmentation or IAM design.

Landing zones layer all three.

Azure’s reference architecture is explicit about this: a hub-and-spoke or Virtual WAN topology routes connectivity, DNS and firewall inspection through a central hub, with application subscriptions in isolated spokes.

A network boundary on top of the subscription boundary, not instead of it.

The mature layering reads from the outside in.

Account, subscription or project separation bounds what a compromised environment can reach.

A DMZ bounds what a compromised internet-facing host can reach inside that environment; the dual-firewall form puts a second, separately configured control between the DMZ and the internal network.

Microsegmentation bounds what a compromised workload can reach among its neighbours, enforced by host firewalls, host agents, the hypervisor or network ACLs.

IAM decides what each identity may do inside all of them.

The evidence for inner layers is real but should be stated at its actual weight.

Akamai’s Segmentation Impact Study 2025, surveying roughly 1,200 security and IT decision-makers, found organizations using microsegmentation contained ransomware 21.4% faster on average, and 32.6% faster among organizations above USD 1 billion in annual revenue.

That is a self-reported survey.

It isn’t a controlled measurement of matched incidents.

Mandiant’s M-Trends 2025 recommends zero trust and microsegmentation “to restrict connectivity even if valid credentials are obtained.”

That is guidance, not a measured segmented-versus-flat comparison.

The claim here is narrower than either. The platform’s own boundary should be the first line a compromise has to cross.

Not an option left unused.

8. What You Should Actually Do.

Separate by what a compromise must not reach. Production from non-production.

One business line from another.

Put them in distinct accounts, subscriptions or projects under a governed hierarchy: AWS Organizations, Azure management groups, Google Cloud folders.

Make cross-boundary access explicit, and inventory it. The default is deny.

Every exception is a grant somebody made.

Each one needs an owner, a purpose and a list of the principals, resources and actions it allows.

Move workloads off static keys. Use role-based or federated workload identities on whichever provider you run.

Then scope the role, because a temporary credential carries every permission the role was given.

Give every posture-tool finding an owner and a deadline. The tool will not remediate it.

The tool cannot remediate it.

For SaaS, record the provider-held keys and identity systems inside your blast radius. Write down what detection you have for their misuse.

If the honest answer is “the provider will tell us,” write that down too, and read the Storm-0558 review before you sign it.

Layer the inner boundaries anyway. Network segmentation and IAM design inside each account are still needed.

They are just no longer the only line.

9. The Model Is Not Complicated.

Your provider enforces isolation between accounts, subscriptions and projects by default.

Your configuration enforces isolation inside one, for as long as it stays correct.

Your posture tool reports when it stops being correct.

A boundary the platform enforces by default is stronger than isolation rebuilt from configuration inside one boundary.

Survey figures, provider guidance and review-board findings will date.

That sentence won’t.

Use the provider’s boundary first.

Segment inside it.

Scope the identities.

Own the findings.

Otherwise “we are segmented” means one account, a lot of rules, and a tool that will tell you, afterwards, which one was wrong.