The Identities That Do Not Sleep – Why Most Users Aren’t Users

Why most of the users in your enterprise are not, in any meaningful sense, users at all.

The first essay in this series argued that the tense of defense is wrong — that we inspect what was, while the adversary works in what is. This second essay argues something more uncomfortable: that the subject of defence is also wrong. We have spent thirty years building identity management programmes around the assumption that an identity is a person. It has not been true for some time. It is now spectacularly untrue. And nobody, in most institutions, has noticed.

The headcount of your bank, your insurer, your hospital, your logistics company, is published in the annual report. The headcount of identities in your enterprise is not. The first number is a few thousand. The second number, if anyone bothered to count, is somewhere between fifty thousand and several million. The first set of identities have HR records, performance reviews, and termination procedures. The second set has none of these things. They are, in the eyes of most governance frameworks, invisible.

We have spent thirty years building identity management programmes around the assumption that an identity is a person. It has not been true for some time. It is now spectacularly untrue. And nobody, in most institutions, has noticed.

This essay is, again, written from the vantage point of financial services. But, again, the problem is industry-agnostic. Manufacturing, healthcare, logistics, government, and education are all running on the same architecture, with the same blind spot, at the same scale. Substitute the bank with any other digital institution, and the absolute numbers move but the proportions do not.

This is the second essay. It is about the strangers in your own building.

The strangers in your own building

Open a senior banker’s laptop on a Tuesday morning and ask them how many identities are currently logged into their bank’s systems. They will say something like forty-five thousand staff, around twelve thousand contractors, give or take. This is the answer you would expect from someone whose mental model of identity was last updated in 2008. It is also, in a serious sense, wrong by a factor of about a hundred.

The actual answer, in any large bank today, runs to several million. Most of them are not people. They are service accounts created by an engineer in 2014 who has since left for a fintech that has since collapsed. They are API keys issued to a vendor who has since merged with another vendor whose name nobody can now remember. They are robotic process automation bots running reconciliations at 3:00am. They are machine identities for microservices that exist for forty-five seconds at a time and are gone before anyone has written down what they were doing. They are AI agents — increasingly, swarms of AI agents — that have credentials, make decisions, and move money, with no one quite sure who provisioned them or what they are supposed to be doing this week.

The bank, of course, has an Identity and Access Management programme. It has been running for years. It has cost a great deal of money. It governs, with considerable care, the forty-five thousand humans. It also, in theory, governs everything else. In practice, governs everything else means a quarterly report in which someone notes that there are 1.2 million non-human identities in the estate, that this is up 14% on last quarter, and that the team is working on a plan to rationalise. The report is approved. The plan does not appear. The number keeps growing. The next quarter’s report begins with the words as previously noted.

The report is approved. The plan does not appear. The number keeps growing. The next quarter’s report begins with the words as previously noted.

The credentials have been waiting

Meanwhile, the threat landscape has worked this out. Attackers have noticed, with great interest, that the most heavily monitored identities in an enterprise — the humans — are also the smallest population, the least privileged on average, and the slowest. They have therefore turned their attention to the other population. Compromise a service account from 2014 that nobody can name an owner for, and you do not need to phish anyone. You do not need to defeat multi-factor authentication. You do not need to study a user’s behavioural rhythm for three weeks. You simply use the credentials. The credentials have been waiting for you, patiently, for over a decade.

The credentials have been waiting for you, patiently, for over a decade.

This is the part of the discussion where the security team will say, we have privileged access management. They will say it with confidence, because they have indeed bought privileged access management. It is in the budget. It is in the slide. It is, in many institutions, in the second decade of its implementation. What it is not, in most institutions, is covering the non-human identities. PAM was designed for humans. It assumes someone will check out a credential, use it, and check it back in. Non-human identities do not check things in. They use credentials continuously, by definition — that is what machine in machine identity means. Most PAM deployments cover the top 5% of privileged accounts — the ones with names — and leave the other 95% in a folder labelled legacy, to be addressed in next year’s roadmap. The roadmap, like the report, is approved annually.

The agents have arrived

Now consider what has happened in the last eighteen months. AI agents have arrived. Not the chatbots — the autonomous ones. The agents that can be given a task, decide which systems to access, take action across multiple systems, and report back. They are, in the technical sense, identities. They have credentials. They have privileges. They make decisions that humans used to make. In many institutions, they are already moving money, approving exceptions, and writing entries into the general ledger. The institutions in question would prefer not to talk about this in detail, because they have not, strictly speaking, governed it. It is on the roadmap. The roadmap, you will recall, is approved annually.

The result is a category of identity that did not exist three years ago, is multiplying faster than any other identity class, has agency that no service account ever had, and is governed — in most enterprises — under a control framework written for a world in which the user was a person. The agents themselves do not mind this. The attackers do not mind it either.

The agents themselves do not mind this. The attackers do not mind it either.

A failure of category

The shape of the problem, then, is this. Your enterprise is full of identities. Most of them are not people. Most of them are not governed as identities — they are governed, if at all, as infrastructure, on a different team, with a different budget, reporting through a different chain, escalating to a different committee. Most of them have privileges that exceed those of your average human user, because they need to in order to do their work. And the population is growing, not by hiring, but by deployment, at a rate that has nothing to do with HR’s calendar and everything to do with whichever engineer most recently shipped a feature.

In a sane world, the response would be to elevate identity governance — all identity, human and non-human, machine and agent — to a single discipline, with a single owner, a single risk lens, and a single board-level oversight. In our world, the response has been to create three different teams, with three different vendors, three different sets of reports, and a quarterly meeting at which everyone agrees the problem is important and nothing structural changes. The meeting is well attended. Pastries are served.

The board, when it is briefed on identity, is shown a graph of human user accounts. It looks orderly. It is orderly. It is also a graph of the smallest, best-governed, slowest-moving population in the enterprise. The other graph — the one with the millions of identities the bank does not know how to count — is not in the deck. The deck is forty-eight slides long. Nobody has time.

This is not a failure of any single team. It is a failure of category. The category of user has quietly become obsolete, and the governance built on it has not noticed. As long as identity is defined as a person who logs in, the architecture will keep producing the same answer: things are fine. They are not fine. They have never been less fine. They are, however, beautifully reported on.

They are not fine. They have never been less fine. They are, however, beautifully reported on.

Identity has become the new perimeter — every security framework now says so, in roughly the same words, on roughly the same slide. What none of them say, with quite the same clarity, is that the new perimeter is mostly populated by entities the old governance does not see. The perimeter is not at the edge of the network. It is wherever the next service account, API key, automation bot, or AI agent quietly comes into being — which is to say, somewhere in your estate, several times an hour, all year.

The shift required is not a tool. It is a change of definition. Identity is no longer a property of people. It is a property of anything that acts inside the enterprise — human, machine, code, model. Governance built on the older definition will continue to produce orderly reports about a vanishing minority while the actual risk surface expands somewhere off the dashboard. Governance built on the newer one will look messier, more uncomfortable, and considerably more accurate. The choice between the two is, by now, a choice between feeling secure and being secure. Boards are usually paid to know the difference.

The first question to ask, the next time identity appears on the agenda, is not are our users provisioned correctly. It is: how many of our users are users, in any sense that matters? If the honest answer is a small minority, and you govern only those, you have not yet started.

The third and final essay in this series turns to the question that follows naturally from the first two: when both sides of a meaningful security interaction are machines — the attack is automated, the defence is automated, the identities are non-human, the speed is millisecond — what exactly is the human in the loop doing? It is the essay nobody wants to write and most boards will need to read.

If you’d like to read it when it’s published — along with the longer working paper for boards on how to ask better questions about cyber, information security, and operational risk — leave a note in the comments or write to me directly. I read everything. I reply to most of it. I do not, ever, add anyone to a mailing list. That is a promise of a kind.


Comments

2 responses to “The Identities That Do Not Sleep – Why Most Users Aren’t Users”

  1. […] Part 2. The Identities That Do Not Sleep […]

  2. […] first essay in this series argued that the tense of defence is wrong. The second argued that the subject of defence is wrong. This third and final essay argues something that […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from Sumir Nagar

Subscribe now to keep reading and get access to the full archive.

Continue reading