Identity First: The Only Control Plane That Survives Every Cloud Decision
When people talk about cloud architecture, they usually start with infrastructure. Networks, regions, services, platforms. Identity comes later, something to “wire up” once the real decisions are made.
That ordering worked once. It doesn’t anymore.
In modern environments, identity is the first thing that touches every system and the last thing that remains when everything else fails. Whether you’re running infrastructure, PaaS, SaaS, or something that hasn’t been named yet, identity is the connective tissue that makes any of it usable, or dangerous.
I’ve watched cloud environments grow over time. What starts simple rarely stays that way. A single cloud becomes two. SaaS sneaks in. PaaS accelerates delivery. Automation multiplies access. And suddenly, the environment isn’t defined by where workloads run, but by who and what is allowed to act. That’s where identity stops being a feature and becomes architecture.
At the center of everything is user identity. Humans still decide what gets built, deployed, approved, and changed. Even in highly automated environments, people initiate actions, approve pipelines, respond to incidents, and carry accountability. User identity defines intent, ownership, and responsibility, and nothing else in the system makes sense without it.
Device identity follows closely behind. Devices are no longer passive endpoints. They are trusted or not based on posture, health, location, and behavior. A secure user on an untrusted device is still a risk. Device identity determines how a user can interact with systems, not just whether they can log in.
Then there is code identity — the fastest-growing and least understood part of the puzzle. Service principals, managed identities, IAM roles, API keys, certificates, tokens, CI/CD identities. These identities don’t get tired, don’t ask questions, and don’t hesitate. They execute at machine speed, across clouds and services, often with broad permissions granted “temporarily” and never revisited.
This is where most modern breaches, outages, and misconfigurations live.
What’s important is not the tools used to manage these identities, whether they come from Azure, AWS, on-prem directories, PAM systems, or something homegrown. Tools change. Clouds change. Services come and go.
What doesn’t change is the structure.
Every cloud, every service model — IaaS, PaaS, SaaS — ultimately relies on the same hierarchy:
- A user identity that establishes intent and authority
- A device identity that establishes trust
- A code identity that executes actions
If you lose clarity in any one of those layers, the entire system becomes harder to reason about.
This is why identity awareness matters more than identity tooling. True identity awareness means being able to answer, at any moment:
- Who is acting?
- From where?
- On behalf of what?
- With what level of authority?
- And what happens if this goes wrong?
When those answers are clear, environments scale safely. When they’re not, complexity compounds silently until something breaks under pressure.
In Expert Mode — full speed, no guardrails — identity is the only thing that allows control to exist at all. Networks can be bypassed. Tools can fail. Dashboards can go dark. But identity remains the last line of understanding between chaos and containment.
That’s why user identity is the critical factor. Everything else inherits from it.
So, where is the single source of trust?
This is usually where the conversation gets uncomfortable. We talk about a “single source of truth” as if it must be a single system, a single directory, a single identity provider, or a single control plane to rule them all. In reality, modern environments don’t work that way anymore.
There isn’t one source of truth. But there must be a source of trust. And in most environments, that trust starts with identity.
Identity doesn’t mean a single directory or a single cloud-native IAM. It means a consistent way to establish who or what is acting, and whether that action should be trusted in this moment, under these conditions.
The challenge is that trust is no longer binary. A user can be trusted — but only from a compliant device. A device can be trusted — but only for certain actions. A workload can be trusted — but only when running in a known context. A service can be trusted — until its credentials are reused somewhere they shouldn’t be.
In multi-cloud, hybrid, and SaaS-heavy environments, trust is inherently distributed. Multiple identity systems exist. Multiple providers assert identity. Multiple services rely on those assertions.
The mistake isn’t having multiple sources. The mistake is not knowing which authority governs each decision. Identity-first architecture doesn’t eliminate multiple trust sources — it orchestrates them.
It defines:
- Where identity originates
- Where trust is evaluated
- Where authority is enforced
- And where ambiguity is not allowed
When that’s clear, multiple clouds and services can coexist without collapsing into chaos. When it’s not, trust becomes implicit, undocumented, and dangerously assumed.
That’s why identity awareness matters more than identity centralization. You don’t need one system to do everything. You need a single way to reason about trust consistently across humans, devices, and code. That’s the difference between an environment that scales and one that only looks like it does.
This post is part of a longer project I’m committing to in 2026, slowing down and examining the foundational decisions we keep revisiting but rarely resolve. This month, it’s identity. Next month, I’ll explore platform decisions and how “paved roads” shape and sometimes constrain teams.
Because cloud architecture isn’t really about clouds anymore. It’s about whether we understand who and what we’ve given power to, and why.
So here’s the question I keep coming back to:
If everything else in your environment failed, dashboards, tooling, pipelines, would you still know which identities matter most, and what they’re empowered to do?
If you’re interested in the broader framing behind this thinking, I explored it further in Expert Mode, No Guardrails — But With Control.
https://www.michaelearls.com/work/expert-mode-no-guardrails-but-with-control/