How to stop “just one more role” from becoming our next incident

Rapid growth is meant to feel like momentum. In the cloud, it often feels like waking up to find your AWS org has doubled, your Entra tenant has sprouted 400 new service principals, and nobody can answer the simple audit question: “Who can do what, where, right now?”

That’s cloud access sprawl. Not “too many resources.” Too many identities and entitlements, human and machine, are spreading across accounts, subscriptions, projects, and SaaS integrations faster than our controls can keep up. It’s a slippery slope to a compliance nightmare and a breach that’s the PR department's month from heck. No one wants to see share prices plummet in a hard-fought growth stage.

And the annoying bit? Attackers don’t need novel exploits. They need access. Verizon’s 2025 DBIR notes that 88% of breaches in the “Basic Web Application Attacks” pattern involved stolen credentials. Microsoft reports 600 million identity attacks per day, with password-based attacks accounting for over 99%. 

If growth created that cloud sprawl, and it does by default, identity will monetize it.

Why Growth Turns Into Cloud Identity Sprawl

Growth multiplies three things at once:

1. Cloud surface area (more accounts/subscriptions/projects, more regions, more “temporary” sandboxes that become permanent)
2. Identity count (employees, contractors, partners, plus a growing army of non-human identities)
3. Privilege pathways (role chaining, cross-account trust, delegated admin, app consent, IaC pipelines)

Multi-cloud is now the norm. According to Forbes, over 92% of large enterprises operate in a multi-cloud environment, and 89% of all organizations have embraced multi-cloud strategies to diversify their infrastructure. That’s not a moral failing; it’s a business reality in a world of mergers and acquisitions and corporate expansion. It also means your identity story isn’t “one IAM.” It’s an entitlement graph spanning AWS + Azure + GCP + SaaS + CI/CD.

Most of those permissions aren’t even used. Microsoft’s research on cloud permissions found workload identities using less than 5% of granted permissions, and reported that more than 80% of workload identities were inactive in one Entra dataset. Their earlier cloud permissions risk report also called out that less than 2% of permissions granted to “super identities” were used. 

So growth tends to produce permission mass: lots of standing access, minimal actual need.

Why Sooner Beats Later

(and why “later” usually means “after something bad”)

The cost argument isn’t just “breaches are expensive” (though they are). IBM’s Cost of a Data Breach Report 2025 puts the global average breach cost at $4.44M. 

The real ROI of fixing sprawl early is operational:

• Faster engineering with fewer exceptions. When access is time-boxed and policy-driven, teams stop begging for “just make me admin for the sprint.”
• Less SOC ambiguity. Clear ownership and logging shrinks the “is this suspicious or just Tuesday?” problem.
• Audit evidence becomes a byproduct. Request → approval → grant → revoke → logs. Not screenshot archaeology.

Once sprawl hardens, it’s no longer “cleanup.” It becomes identity debt: inherited permissions, zombie service accounts, and brittle trust relationships that everyone is afraid to touch.

What “Cloud Sprawl” Looks Like Technically (In The Weeds)

AWS: Role Chaining, Trust Sprawl, And The PassRole Trap

Sprawl often hides in the edges:

• Cross-account role assumptions (sts:AssumeRole) that multiply with every new account.
• Trust policies that start specific and slowly become “any principal in this org” for convenience.
• Privilege escalation primitives like iam:PassRole combined with services that can run code (Lambda, ECS, Glue, etc.).

AWS’s own IAM guidance is blunt: use roles and temporary credentials, preferably via federation/Identity Center, rather than long-lived credentials.  AWS also documents that role sessions can be as short as 15 minutes (900 seconds). If our “admin role” effectively lasts forever, that’s not AWS’s fault. That’s ours.

Azure/Entra: App Sprawl Is Identity Sprawl

In growth phases, Entra app registrations and service principals proliferate because everything integrates with everything. The danger isn’t just “too many apps.” It’s:

• Over-broad delegated permissions and admin consent granted under pressure
• Privileged role assignments that drift without strong lifecycle control
• Long-lived app secrets/certs that outlive teams and projects

GCP: Project + Service Account Sprawl

GCP sprawl is often “project sprawl,” with service accounts bound at multiple levels (org/folder/project). If you’re still relying on long-lived keys rather than short-lived federation patterns, you’re basically leaving a spare key under the mat and acting surprised when it gets used.

A Practical Control Model For Fast-Growing Clouds

If you want a simple mental model that works across AWS/Azure/GCP:

1. Discover and normalize identities + entitlements across clouds. You need one place to answer “who has access to what,” including non-human identities.
2. Kill standing privilege for sensitive actions. Replace “permanent admin” with time-bound elevation (just-in-time access) and automatic revocation.
3. Put approvals where engineers actually are. If it’s not in Slack/Teams, it will be bypassed in Slack/Teams.
4. Continuously re-check the need, not just the scope. Access should expire not only on a timer, but when context changes (team moves, project ends, contractor offboards).
5. Make the logs audit-grade by default. “Who approved, what was granted, what happened, and when it was revoked” should be automatic. 

That set of capabilities is exactly what modern CIEM + JIT access platforms (i.e., Trustle) aim to operationalize: multi-cloud visibility, time-boxed privilege, workflow-based approvals, and clean evidence trails, without forcing your senior engineers to soak up their days being part-time spreadsheet curators. 

The Reality of Cloud Sprawl

Cloud sprawl after rapid growth isn’t a sign we’re failing. It’s a sign we’re scaling.

But uncontrolled standing privilege is not “scaling.” It’s just leaving yesterday’s shortcuts in place long enough for an attacker or an auditor to find them.

We don’t need perfection. We need grip: visibility, least privilege in practice, and access that expires like milk, not like fine wine.

‍