Your cloud has more admins than you think.

The goal isn’t to make cloud access harder to get. It’s to make sure privileged access doesn’t outlive the work it was granted for.

Every access grant made sense at the time. A developer needed temporary administrator rights to build a new environment. A project team needed elevated permissions to meet a deadline. A service account was given broad access because properly scoping the role would have taken time the team didn’t have.

I see this as an important distinction: most privilege sprawl doesn’t begin with a careless decision. It begins with someone trying to solve a legitimate business or technical problem.

The problem is what happens afterward. The project ends, the environment changes and everyone moves on. The access remains.

The problem isn’t one bad decision. It’s a thousand reasonable ones.

Privileged access rarely looks like a problem when it is first granted. It becomes one over time, accumulating across accounts, projects, teams and cloud platforms faster than most organizations can manually track.

In AWS, that may include administrator and service roles, cross-account access, temporary project permissions and access keys that were never rotated or removed. In Azure, it may be subscription owners, contributor roles, service principals, managed identities and inactive accounts that outlasted the work they supported. In Google Cloud, it can include project owners, custom IAM roles, service accounts and permissions inherited through groups or resource hierarchies.

What matters is not whether the word “administrator” appears in the role name. An identity may still be able to modify policy, assume another role, access secrets or control a workload. That is why counting named administrator accounts rarely gives you the complete picture of privileged access.

Each entitlement may look reasonable in isolation. Collectively, they expand the attack surface and make governance harder. And because cloud permissions can be inherited, combined or exercised through automation, the effective level of access is not always obvious from the individual role assignment.

The question I would ask isn’t simply, “How many administrators do we have?” It’s, “How many identities can perform an administrative action—or become administrative through the access they already hold?”

Why it’s hard to see

Cloud environments change constantly. New accounts, subscriptions and projects are created. Infrastructure is deployed through code. Applications create service identities, teams add new tools and automation generates access without someone manually assigning every permission.

The challenge is that no single team owns the whole picture. Cloud engineering may manage platform roles. Application teams own service accounts. Security sets policy. Identity teams manage directories and federation. Each team can understand its part of the environment while no one sees how much privilege has accumulated across all of it.

Traditional access reviews also capture a moment in time. In the cloud, access may change the next time a deployment pipeline runs, a workload assumes a role or a new resource inherits an existing policy. A quarterly review can be accurate on the day it is completed and outdated soon afterward.

That creates a gap between the access model an organization believes it has and the access identities can exercise today. Security teams often discover the difference during an incident, when the permissions already in place determine how far an attacker can move and what they can reach.

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

Getting ahead of privilege sprawl doesn’t mean replacing every identity tool or redesigning the entire cloud environment. It means getting a complete view of privilege and building a consistent way to control it.

When I look at privileged access, I focus on four things: discovery, understanding, reduction and control.

Discovery means finding every identity that can perform a privileged action—not just the human accounts with “admin” in the role name. Service accounts, service principals, managed identities, automation tools and workloads may be able to modify policy, access secrets, create credentials or assume more powerful roles.

Understanding means looking at effective access, not only the role originally assigned. Where did the permission come from? What does the identity inherit? Can it assume another role? What resources can it control? Is the access still being used, and who is responsible for it?

Reduction means removing access that no longer supports a business need and narrowing what remains. Some permissions can be removed immediately. Others support applications or automation that need to be tested first. The goal is to reduce risk without discovering an undocumented dependency through an avoidable outage.

Control means changing how elevated access is provided going forward. Human administrators should receive just-in-time access for a specific task and duration, with the permission removed automatically when the work is complete. For workloads and automation, the same principle means using narrowly scoped roles and short-lived credentials instead of leaving powerful, long-lived secrets in place.

Most organizations are somewhere in the middle. They have identity tools, but visibility is divided across cloud platforms. They have access policies, but enforcement still depends on tickets, spreadsheets and someone remembering to remove a role later.

The secure process has to be practical enough that teams will use it. If requesting temporary access takes longer than the work itself, permanent access will continue to feel like the easier option.

The place to start

Start by measuring the access that exists—not the access you assume exists.

I would want to know which identities can change policy, create credentials, access secrets, assume privileged roles or control critical workloads. I would also want to know who owns those identities, whether their access is still being used and which permissions could be removed without disrupting the business.

A useful assessment should provide more than a count of administrator accounts. It should show where standing privilege exists, how identities obtained it and which changes will reduce the most risk. That gives cloud, identity and security teams a practical place to begin.

Most organizations find more privileged access than they expected. Finding it through an assessment gives you the opportunity to address it deliberately—before an incident reveals it for you.