Identity
Your cloud has more admins than you think.
Because the goal was never to make access harder to get. It's to make sure it doesn't outlive its purpose.
Every access grant made sense at the time. A developer needed temporary admin rights to spin up a new environment. A project team got elevated permissions to move faster on a deadline. A service account was provisioned with broad access because scoping it down would take time no one had.
None of those decisions were wrong. But they compound. And in most cloud environments, they compound silently.
The problem isn’t one bad decision. It’s a thousand reasonable ones.
Privileged access doesn’t start as a problem. It grows into one—accumulating across accounts, projects, teams and clouds faster than any team can manually track.
In AWS alone, that means admin roles, service roles, forgotten access from temporary projects and unused access keys that were never rotated or removed. In Azure: subscription owners, contributor roles, service principals, temporary resources and inactive accounts that outlasted the work they were created for. In Google Cloud: project owners, IAM custom roles, service accounts, ephemeral projects and legacy access that no one has reviewed in months.
Each one looks reasonable in isolation. Collectively, they expand the attack surface, weaken governance and—on average—grow the number of cloud identities with admin access by 2.5x year over year.
That number is worth sitting with. Not 25%. Two and a half times. Every year.
Why it’s hard to see
The nature of cloud environments makes privilege sprawl particularly easy to miss. Access is spread across accounts, environments and services. New projects, teams and tools create more access by default. Temporary access becomes permanent without anyone noticing. And because each entitlement looks legitimate on its own, no single alert fires.
The result is a growing gap between what your organization thinks its access landscape looks like and what it actually is. Security teams often discover the full scope only after something goes wrong—and by then, the blast radius is already set.
The IBM Cost of a Data Breach Report found that breaches caused by compromised credentials cost organizations an average of $4.79 million. When those credentials belong to an account with admin-level access, the damage is rarely contained.
Nobody sets out to create excess privilege. It just accumulates. Visibility is the first step. Control is the next.
What getting ahead of it looks like
Reducing privileged access risk doesn’t require replacing every tool or rearchitecting every environment. It requires four things done consistently.
The first is discovery—finding every identity with privileged access across your cloud, not just the ones you know about.
The second is understanding: seeing who has what access, where it exists and whether it’s still needed.
The third is reduction—removing unnecessary access and right-sizing permissions so accounts carry only what they need.
The fourth is control: granting just-in-time access and revoking it automatically when the work is done, so standing privilege doesn’t accumulate in the first place.
Most organizations are somewhere in the middle of that path. They have identity tools, but the tools don’t talk to each other across clouds. They have policies, but enforcement is manual and inconsistent. They know privilege sprawl exists; they just don’t know how much of it is out there.
The place to start
The organizations that get ahead of this problem share one thing in common: they looked first. They ran an assessment, mapped their actual access landscape and found out what they were working with before assuming they already knew.
What they found was usually more than they expected—and finding it early, before an incident forced the issue, made the difference.
See how many identities really hold privileged access in your cloud. ConRes offers a complimentary identity security review—no commitment, just clarity on where you actually stand.