Part 2 — Identity Is Becoming the New Cloud Control Plane
CSA Top Threats 2026 — Part 2 of 8
Why identity is no longer merely an access mechanism but increasingly the mechanism through which infrastructure itself is controlled.
By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.
There was a time when identity security was relatively easy to explain.
A user wanted to access a system.
The system asked:
Who are you?
The user authenticated.
The system then asked:
What are you allowed to do?
Authorization provided the answer.
Identity was therefore primarily an access mechanism.
It stood at the door.
That mental model still shapes much of enterprise IAM.
But in modern cloud environments, identity has moved far beyond the door.
Identities deploy infrastructure.
Identities modify configurations.
Identities retrieve secrets.
Identities invoke APIs.
Identities trigger pipelines.
Identities create other identities.
Identities assume roles.
Identities obtain temporary credentials.
And increasingly, identities are attached to autonomous software actors capable of making decisions and taking actions without a human initiating every individual transaction.
That changes the role of identity fundamentally.
Identity is no longer merely controlling access to the cloud.
Identity is increasingly controlling the cloud itself.
Why Identity Moved to Number One
The Cloud Security Alliance’s Top Threats to Cloud Computing 2026 places inadequate identity and access management at the top of its ranking.
It has moved up from number two.
That should not be interpreted simply as another reminder to deploy MFA.
The more interesting explanation is architectural.
Cloud computing has progressively separated authority from physical infrastructure.
In a traditional data center, administrative power was often closely connected to physical and network location.
You needed access to the environment.
You needed administrative credentials.
You needed connectivity.
You might need a privileged workstation.
Cloud changed that.
Infrastructure became software-defined.
Networks became programmable.
Storage became programmable.
Security policies became programmable.
Compute became programmable.
And almost every administrative function became accessible through an API.
Once infrastructure becomes programmable, something must determine who or what is allowed to program it.
That something is increasingly:
identity.
The Control Plane Changed Everything
The concept of a control plane is fundamental to understanding modern cloud risk.
The data plane performs the work.
The control plane determines how the environment behaves.
Create a workload.
Assign a role.
Modify a network.
Change a policy.
Create a secret.
Deploy an application.
Grant access.
Disable logging.
Configure a backup.
Delete a resource.
These are control-plane actions.
And in cloud environments, they are overwhelmingly identity-mediated.
This produces an important inversion.
Historically, we protected identities because identities provided access to infrastructure.
Today, we increasingly need to protect infrastructure by controlling the identities capable of changing it.
The direction of dependency has shifted.
It is no longer simply:
Identity → Access → Resource
Increasingly it becomes:
Identity → Authority → Infrastructure State
That makes identity part of the infrastructure itself.
The Most Powerful Cloud Asset May Not Be a Server
Ask an organization to identify its most critical cloud assets and the answers will usually be familiar.
Production databases.
Customer information.
ERP systems.
Cloud subscriptions.
Critical applications.
Backups.
Perhaps encryption keys.
But what about an identity capable of changing all of them?
A sufficiently privileged cloud identity may be more consequential than any individual server it can access.
Compromise a server and you may control a workload.
Compromise the right identity and you may control the environment that creates, modifies, monitors and destroys workloads.
This is why the old distinction between “identity security” and “infrastructure security” is becoming increasingly artificial.
In software-defined infrastructure:
authority is infrastructure.
And authority is expressed through identity.
The Human User Is No Longer the Default Identity
There is another reason the CSA finding matters.
The identity population itself has changed.
For decades, IAM programs were primarily designed around people.
Employee joins.
Account is created.
Employee changes role.
Permissions change.
Employee leaves.
Account is disabled.
The famous Joiner-Mover-Leaver lifecycle made sense because the identity represented a human being embedded in an organizational structure.
There was an HR record.
A manager.
A department.
A job function.
A contract.
A beginning.
And an end.
Modern cloud environments contain a rapidly growing second identity population.
Service accounts.
Service principals.
Managed identities.
Workload identities.
Application identities.
API credentials.
Automation accounts.
CI/CD identities.
Machine identities.
Temporary tokens.
And now:
AI agent identities.
The CSA explicitly highlights the security challenge created as non-human identities outnumber human users.
That is not simply a scaling problem.
It is a governance problem.
Machines Do Not Have Managers
Consider a normal employee account.
If I ask:
Who owns this identity?
there is usually an answer.
The employee.
If I ask:
Who is accountable for the employee’s access?
there is usually another answer.
A manager.
Now consider a service principal created two years ago during a cloud migration.
Who owns it?
The developer who created it?
The application owner?
The platform team?
The business process owner?
The cloud operations team?
The supplier that implemented the solution?
What happens if the developer leaves?
What happens if the project closes?
What happens if the application is replaced but the identity remains?
What happens if nobody knows what would break if the identity were disabled?
This is where many non-human identity problems begin.
Not with malicious intent.
Not even necessarily with excessive privilege.
But with orphaned authority.
An identity continues to possess the ability to act even though the organizational context that justified that authority has disappeared.
That should concern every CISO.
Every Identity Needs an Accountable Human
There is a principle I believe organizations will increasingly need to establish:
Every non-human identity needs a human owner.
Not a technical contact.
Not merely the team that created it.
An accountable owner.
Someone who can answer:
Why does this identity exist?
What business process does it support?
What systems can it access?
What permissions does it have?
What credentials does it use?
Where are those credentials stored?
When were they last rotated?
Which other identities can assume it?
Which APIs can it invoke?
What happens if it is compromised?
What happens if it is disabled?
And when should it cease to exist?
If nobody can answer those questions, the organization does not really govern the identity.
It merely operates it.
Those are not the same thing.
The New Joiner-Mover-Leaver Problem
Human IAM has spent decades refining lifecycle management.
Provision.
Modify.
Review.
Revoke.
We now need something comparable for machines.
A workload identity is created.
What triggered its creation?
A new API token appears.
Who approved it?
An automation receives additional permissions.
Was that treated as an access change?
An application is retired.
Are its identities automatically retired as well?
An AI agent moves from experimentation into production.
Does its identity change?
Does its tool access change?
Does its credential model change?
Does its monitoring change?
An agent is decommissioned.
Are its tokens revoked?
Are its delegated permissions removed?
Are downstream credentials invalidated?
Are its tool registrations deleted?
These are increasingly ordinary IAM questions.
But many enterprise IAM processes were never designed to ask them.
Authentication Is No Longer the Hardest Question
For human users, security architecture has invested heavily in authentication.
Passwords.
MFA.
Passwordless authentication.
FIDO2.
Conditional Access.
Device trust.
Risk-based authentication.
These controls have significantly improved human identity security.
But what does strong authentication mean for a machine?
A workload cannot respond to a push notification.
A service principal cannot use a biometric factor.
An AI agent cannot independently prove that the business process invoking it is legitimate.
Machine identities therefore rely on different trust mechanisms:
certificates,
secrets,
tokens,
federated identities,
managed identities,
workload attestation,
short-lived credentials.
This changes the security emphasis.
For machine identities, the difficult questions increasingly become:
Where did this identity originate?
Which workload is allowed to use it?
What can it obtain after authentication?
Can another workload impersonate it?
Can its credential be replayed elsewhere?
Can it delegate authority?
Can it create additional credentials?
The problem moves from authentication alone toward authority propagation.
Tokens Are Becoming the Currency of Cloud Authority
This is particularly visible in modern API-driven environments.
Users authenticate.
Applications receive tokens.
Workloads exchange tokens.
Services obtain temporary credentials.
OAuth delegates authority.
APIs accept bearer tokens.
Agents receive access to tools through tokens.
The token becomes the portable representation of trust.
And portable trust is powerful.
A stolen password may still encounter MFA.
A valid token may represent an already completed authentication event.
A compromised workload identity may operate without any human interaction at all.
An excessively scoped token may bridge systems that were never intended to form one security domain.
This makes token governance one of the increasingly important dimensions of cloud security.
The question is no longer simply:
Who has credentials?
It becomes:
Where can authority travel?
Identity Paths Matter More Than Individual Accounts
This brings us back to the argument from Part 1 of this series.
The attacker sees a graph.
The defender often sees an inventory.
The same is true for identity.
Traditional IAM tends to inspect individual identities.
User A has roles X and Y.
Service Principal B has permissions C and D.
Application E can access resource F.
But an attacker is interested in something else.
Can User A modify Service Principal B?
Can B assume Role C?
Can C retrieve Secret D?
Can D authenticate to Application E?
Can E modify production?
The individual permissions may all appear reasonable.
The path may not.
This is why effective cloud identity security increasingly requires us to understand identity attack paths.
Not merely:
Who has privilege?
But:
Who can reach privilege?
That is a much larger population.
Privilege Can Be Transitive
This creates a concept that deserves far more attention in IAM programs:
transitive privilege.
Imagine that I cannot administer a production environment.
My direct permissions therefore appear safe.
But I can modify an automation.
That automation runs under a privileged workload identity.
The workload identity can modify production.
Do I effectively possess production privilege?
From an attacker’s perspective, the answer is obvious.
The path is:
Human → Automation → Workload Identity → ProductionNo direct administrative permission is required.
This is why entitlement reviews alone can provide a misleading picture.
Direct privilege is visible.
Transitive privilege often hides in relationships.
Cloud security must understand both.
AI Agents Make Identity Dynamic
Agentic AI adds another layer.
An application identity normally represents software executing predefined logic.
An agent identity may represent software that determines its next action dynamically.
That means the identity’s effective capability is not determined only by its permissions.
It is determined by:
**Identity
- Permissions
- Context
- Memory
- Tools
- Data
- Instructions
- Reasoning**
This makes agent identity fundamentally interesting from a security perspective.
Suppose an agent can:
read email,
search documents,
query an ERP system,
create a ticket,
invoke an API.
A conventional IAM review may conclude that none of these permissions is individually administrative.
But the agent can combine them.
The security question therefore becomes:
What can this identity accomplish through composition?
That is where conventional least privilege begins to reach its conceptual limit.
And it is where the idea of least agency becomes relevant.
We will return to that later in this series.
An Agent Should Never Own Its Own Authority
There is also an important governance principle here.
Autonomy must not become self-authorization.
An agent may decide how to accomplish a task.
But it should not decide what authority it deserves in order to accomplish that task.
The system that acts should not independently determine its own security boundary.
That means agentic architectures need clear separation between:
reasoning,
identity,
authorization,
and policy enforcement.
An agent may request an action.
An external control should determine whether that action is permitted.
The more autonomous the agent becomes, the more important this separation becomes.
Otherwise we risk creating systems in which the actor, the decision-maker and the authority mechanism collapse into the same component.
That is the opposite of separation of duties.
Zero Trust Becomes More Literal
For years, Zero Trust has been summarized through principles such as:
Never trust, always verify.
Assume breach.
Use least privilege.
Verify explicitly.
These principles become even more relevant when the majority of transactions may eventually involve non-human identities.
But Zero Trust must then extend beyond human authentication.
We need to verify:
the workload,
the identity,
the execution context,
the requested action,
the target resource,
the current risk,
and potentially the purpose of the transaction.
A valid identity should not imply unlimited trust in everything that identity chooses to do.
This distinction becomes particularly important for autonomous actors.
Authentication establishes who or what is acting.
It does not establish that every action the actor takes is legitimate.
Identity Governance Must Become Runtime Governance
Traditional identity governance is often periodic.
Quarterly access reviews.
Annual recertification.
Role reviews.
Entitlement cleanup.
Those mechanisms remain useful.
But cloud authority is increasingly dynamic.
Temporary credentials may live for minutes.
Workloads may exist for hours.
Containers may exist for seconds.
Agents may dynamically invoke different tools.
Permissions may be granted just in time.
Federated identities may cross cloud environments.
A quarterly review cannot govern a transaction that exists for five minutes.
Identity governance therefore needs to become increasingly runtime-aware.
Can we detect unusual token use?
Can we identify a workload assuming an unexpected role?
Can we see an agent invoking a tool it rarely uses?
Can we recognize a new identity path toward a critical resource?
Can we revoke authority quickly?
Can we constrain an identity based on context?
Can we reconstruct exactly which identity performed which action under which delegated authority?
This is where IAM, cloud security and the SOC increasingly converge.
The CISO Cannot Delegate Identity to IAM Alone
There is an organizational implication.
Identity is often treated as a specialist discipline.
IAM teams manage directories.
IGA teams manage lifecycle processes.
PAM teams manage privileged access.
Cloud teams manage workload identities.
Developers manage application credentials.
Platform teams manage service principals.
AI teams may soon manage agent identities.
Each team may perform its task competently.
But the systemic risk exists across them.
If identity has become the mechanism through which infrastructure is controlled, identity governance is no longer simply an IAM operational concern.
It becomes a CISO-level architectural concern.
The CISO does not need to operate IAM.
But the CISO should be able to answer:
What identity populations exist?
Who governs each population?
Where does privileged authority reside?
How is machine identity lifecycle managed?
How do we detect orphaned identities?
How do we map transitive privilege?
How are tokens governed?
How are agent identities created?
Who owns them?
What can they reach?
And how quickly can we revoke their authority?
If those answers require five different teams and nobody can assemble the complete picture, that is itself a governance finding.
Identity Inventory Is Becoming as Important as Asset Inventory
Security organizations have spent years demanding accurate asset inventories.
Quite rightly.
You cannot protect what you do not know exists.
The same principle now applies to identity.
But the inventory must extend beyond employees and administrators.
A modern identity inventory should increasingly answer:
Which human identities exist?
Which privileged identities exist?
Which service accounts exist?
Which workload identities exist?
Which service principals exist?
Which API credentials exist?
Which certificates represent identities?
Which automation identities exist?
Which external identities are trusted?
Which federated identities can enter the environment?
Which AI agents have identities?
Which identities can obtain other identities?
And which identities no longer have a valid owner?
That last category may prove particularly interesting.
Because an unknown server is dangerous.
An unknown identity with authority may be worse.
The New Crown Jewels May Be Identities
For years, security strategies have asked organizations to identify their crown jewels.
Critical data.
Critical applications.
Critical infrastructure.
Perhaps we should add another category:
critical identities.
These are identities whose compromise would create disproportionate control over the organization.
Not simply Domain Admin.
Not simply Global Administrator.
A CI/CD identity capable of modifying hundreds of applications may qualify.
An automation identity capable of changing security policy may qualify.
An identity capable of creating new credentials may qualify.
A backup administrator may qualify.
A federated identity controlling trust relationships may qualify.
An AI orchestration identity with access to multiple enterprise tools may eventually qualify.
Criticality should therefore not be based solely on the nominal role.
It should be based on reachable consequence.
What can happen if this identity is compromised?
That is the question that matters.
Identity Is Becoming the New Cloud Control Plane
The CSA’s decision to place inadequate identity and access management at the top of its 2026 cloud threat ranking therefore captures something larger than an IAM problem.
It reflects an architectural transition.
Infrastructure has become programmable.
APIs have become ubiquitous.
Automation has become normal.
Machine identities are proliferating.
Tokens carry authority between systems.
And AI agents are beginning to turn identity into autonomous action.
The result is a cloud environment in which control increasingly follows identity.
That changes what identity security means.
It is no longer enough to authenticate users strongly.
It is no longer enough to review entitlements periodically.
It is no longer enough to protect privileged administrator accounts.
We must understand the entire authority system.
Human identities.
Machine identities.
Workload identities.
Agent identities.
Tokens.
Delegation.
Trust relationships.
Transitive privilege.
And the paths connecting them.
Because the fundamental cloud security question is changing.
It used to be:
Who can access the infrastructure?
Increasingly, it is:
Which identities can control the infrastructure — directly, indirectly or autonomously?
And that leads to an uncomfortable conclusion.
In the modern cloud, the most important control plane may no longer be the management console.
It may not even be the cloud platform itself.
It may be identity.
Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.
This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.
For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.
Member discussion