Identity Is the Control Plane of the Modern Enterprise

For decades corporate security had a simple map: inside, outside, and a perimeter between the two. The map was crude, but it worked, because it corresponded to something physical — cables, buildings, a door somebody had to walk through. You could draw it on one sheet of paper and argue about where things sat.

That map ended without ceremony and without an announcement. Operations today are made of third-party services, environments that appear and disappear in minutes, integrations that cross company lines, and people working from anywhere. What remains as an effective boundary is identity: who is asking, what that credential can do, and for how long. If identity is the boundary, then the reach of an incident is not measured in compromised machines. It is measured in authorisations reached.

Most identities are not people

In any company with some automation, human identities are a comfortable minority. The rest are service identities: build pipelines, scheduled jobs, connectors between systems, application keys, integrations a team stood up during a hard week. They receive a fraction of the attention given to people, and the asymmetry is structural — a person who joins goes through a process, a person who moves is reviewed, a person who leaves triggers a procedure. A project that ends simply ends, and its credential carries on working.

They also differ in a way that matters for detection. A person's credential is used from a place and at a time, which makes anomalous use at least conceivable. A service credential is used at any hour, by automation, with no human pattern — which is precisely the traffic profile of misuse. And nearly all of them are born too broad, because narrowing them requires knowing in advance which calls the integration will make, and the deadline says grant widely and revisit later. There is no later.

Credentials that outlive their own reason

The long-lived credential is the problem that compounds. It outlives the project that created it, the person who configured it, the vendor relationship and the architecture that justified it. Along the way it gets copied to a second place for a legitimate reason — a test environment, a new automation, someone's machine — and then to a third, and nobody records the copy, because each copy was a small and reasonable act.

A long-lived credential is not a secret. It is a secret with no stated expiry, held in places nobody can enumerate.

The engineering answer is known and unexciting: short lifetimes, issuance to a workload identity instead of a value pasted into configuration, scope limited to the operation that actually needs doing. What makes it hard is not the mechanism, which every serious platform has offered for years. It is the inventory: you cannot rotate what you cannot list, and the list, where it was not maintained from the beginning, gets discovered by breaking things. That is why moving to short-lived credentials is in practice an archaeology project with operational risk attached, and why it is always deferred.

Privilege only accumulates

The access lifecycle has three events, and the middle one is the orphan. Joining is handled because it is visible. Leaving is handled because someone chases it. Changing role is handled by nobody: the person receives the new access and keeps the old, because removing it might break something and nobody can say what. After a few moves, someone's permissions describe a career history rather than a job. The same holds for services that have survived migrations: they accumulate the permissions of every previous architecture. Four plain questions rarely have an answer about any given credential:

• —What exactly can it do today — not what was granted, but the effective result once groups, inheritance and policies are added together.
• —Who approved it, on what justification, and when was that last reviewed by someone other than the beneficiary.
• —When does it expire. And if the answer is never, who took that decision.
• —What breaks if it is revoked right now — the question that stops all the others from having consequences.

The last one is the real blocker, and it is organisational before it is technical. Revocation is avoided not because the risk is misunderstood but because the cost of being wrong lands immediately on the person who acts, while the risk of not acting lands diffusely on the company and with no date attached. That asymmetry has an engineering fix: make revocation reversible and rehearsed. A suspension that can be undone in a minute changes the calculus entirely, because it converts an irreversible act into a test — and tests get run on a Tuesday, with everyone awake.

The lateral path is now an authorisation graph

Classic lateral movement crossed the network. Current lateral movement crosses legitimate grants: a build pipeline that can publish to production, a connector with broad access to a document store, a directory integration that can create identities, a support tool that can act as any user. None of it requires a software flaw. It requires reaching one credential and reading what that credential reaches. And the identity provider is the highest-value target of all, because it does not merely hold access: it issues access.

Asking whether someone can get in has stopped being interesting. The question is: from here, where does the authorisation lead?

The position we hold is unmysterious. Identity is a system, and systems have an owner, an inventory, a lifecycle and a recovery path walked before it is needed — including the case nobody rehearses, which is the identity provider being the incident itself, with every response tool depending on it to authenticate the responders. For as long as identity is treated as a support function, measured by how quickly an access request is closed, the company is deciding by omission how far the next incident travels. That is an architectural decision, and it is being taken by people who do not know they are taking it.