Identity as the Control Plane

Identity · June 11, 2026 · 9 min read

“Identity is the new perimeter” is the tidiest sentence in this field and one of the least examined. It is usually offered as reassurance: the old boundary dissolved, but a new one formed around the account, so the shape of the problem is unchanged. That reading is wrong in a way that matters. A perimeter is a place. Identity is not a place — it is a claim production system, and moving policy on top of it changes what you are actually depending on.

What “control plane” is claiming

Borrowed from networking, a control plane is the part of a system that decides what happens; the data plane is the part that carries it out. Saying identity is the control plane is a specific architectural assertion: that the inputs to every access decision are attributes of a principal, and that the systems handling traffic merely enforce conclusions reached elsewhere.

That has an immediate consequence people tend to skip past. If policy is written against identity attributes, then whatever can write those attributes can write policy outcomes. Group membership becomes an authorisation primitive. So does the process that grants group membership. So does the person who approves that process. Authority is not created at the enforcement point; the enforcement point only reads it.

Most of the interesting failures in identity-centric architectures are not authentication failures at all. Nobody defeated a login. Somebody was legitimately added to a group whose meaning had drifted, or a service account acquired a role during an incident and kept it, or a synchronisation job promoted an attribute from a directory that a supplier could edit. The claims were all genuine. The production of them was the problem.

Authentication is the small half

Authentication answers a narrow question: is this the principal it says it is, right now, with acceptable confidence? It is well understood, the mechanisms are mature, and phishing-resistant methods make the remaining attacks meaningfully harder.

Authorisation answers a much larger one: given that it is, what may it do? This is where estates come apart, and the reason is structural rather than technical. Authentication has a correct answer that can be tested. Authorisation has an intended answer that exists only in somebody’s head, is never written down completely, changes whenever the organisation changes, and is compared against reality only when something goes wrong.

So identity systems accumulate. Roles are created for a project and outlive it. Permissions are added to unblock a release and never removed, because removing them risks breaking something nobody can name. Access reviews turn into recertification of the existing state by people who cannot evaluate it, which converts drift into policy by signature. The directory ends up describing the organisation as it was, in layers.

Entitlement is not the same as identity

A useful discipline is to keep two things separate that most implementations merge. Who the principal is is a fact about the world with a definite answer. What the principal may do is a decision your organisation made, which could reasonably have been made differently.

When those are merged — when a group is simultaneously a description of a person and a grant of access — the grant becomes invisible. Nobody reviewing an org-chart-shaped group thinks they are reviewing permissions. Nobody adding a new hire to the obvious group thinks they are issuing authority. But the policy decision point reads the same attribute either way.

Keeping them separate costs something: a second layer, and explicit rules mapping attributes to entitlements. What it buys is the ability to answer “why does this principal have this access” with a rule rather than an archaeology exercise. That question, asked about a real production entitlement, is the fastest diagnostic available for how healthy an identity-centric estate really is.

Human identity is the easy case

Human accounts have properties that make them tractable. There are a bounded number of them. Each maps to a person who can be asked. Joiners, movers and leavers arrive through a process that at least nominally exists. And a human can be interrupted — pushed to a second factor, asked to re-authenticate, blocked until someone approves.

Machine identity has none of that. Workloads are created by automation, in numbers that no review process can absorb, with lifetimes measured in minutes. There is no person to ask. There is no leaver event; a container simply stops existing, and if its credential was long-lived, the credential does not stop existing with it. And nothing can be interrupted for a challenge, because there is nobody at the other end to answer.

The result is that most estates run two identity regimes: a governed one for people and an ungoverned one for everything else, with the second growing faster. When a programme says identity is its control plane and means only the human half, the majority of the principals that actually initiate traffic sit outside the claim entirely.

Concentration is the trade you are making

Centralising authority is the point. It is also the cost, and it should be stated plainly rather than discovered.

In a perimeter estate, compromising the firewall gets you network reachability; you still have to defeat whatever each application does on its own. In an identity-centric estate, the issuer’s signature is the thing every enforcement point trusts. Control over token issuance — the signing key, the federation configuration, the directory that feeds it, the administrative accounts that manage all three — is not equivalent to breaching one system. It is the ability to mint valid authority for anything downstream, and every enforcement point will honour it correctly, because a correctly signed token from the trusted issuer is exactly what they were built to accept.

This is not an argument against the model. Distributed, per-application authority was worse in every practical respect, including this one, because it failed quietly and unevenly. It is an argument for treating the identity infrastructure as a different class of asset from the systems it protects: administered from dedicated paths, with separated duties for federation and key material, with issuance and configuration changes logged somewhere the identity system itself cannot rewrite, and with a rehearsed answer to the question of how you would revoke everything currently outstanding.

The question that measures it

Ask what a request carries into an access decision. If the answer is a cryptographically verifiable statement about a specific principal, issued recently by a known authority, scoped to a particular resource, and evaluated against a rule someone can point at — identity is genuinely the control plane.

If the answer is that the request arrived on an interface that only trusted things can reach, the control plane is still the network, and the identity products are decoration on top of it.

Most estates are somewhere between, and the useful work is knowing precisely where the boundary between the two runs.