The Last Mile of Identity: The Thesis
Identity systems get 'deployed' and still don't work, because the work that makes them work has no owner. The thesis, drawn from a decade of incidents.
I have spent years writing up identity breaches one at a time, on the other half of this site, refusing to draw the conclusion out loud. This is me drawing it.
The claim
Identity does not break inside the product you bought. It breaks in the stretch of work between "the product is deployed" and "identity is actually under control" — and that stretch belongs to no one.
The vendor's responsibility ends at the edge of their product. They ship an identity provider, a directory, a privileged-access vault, a CRM with OAuth, and their job is done when those things work as specified. The client, on the other side, is supposed to carry it the rest of the way — but the client doesn't have the expertise, the staffing, or the continuous attention that the rest of the way requires. Between the vendor's edge and the client's reach lies a zone that is nobody's: the configuration nobody hardened, the account nobody decommissioned, the OAuth grant nobody reviewed, the help-desk reset nobody verified, the secret nobody rotated. That zone is where every incident I have ever documented actually happened. I call it the last mile of identity, and the single most important fact about it is that it has no owner.
Why now
The mile has always existed, but two things are making it both bigger and more dangerous at the same time.
The first is the explosion of identities that aren't human. A decade ago "identity" mostly meant people, and we spent that decade getting good at securing people — MFA, conditional access, phishing-resistant factors. We won that fight reasonably well. But every company now runs hundreds of non-human identities: service accounts, integrations, connected apps, and now AI agents, each holding a standing authorization that no human watches and no MFA protects. The attackers noticed the ground had moved before most defenders did, which is why the recent incidents in my archive keep landing on OAuth tokens and connected apps rather than passwords.
The second is AI, and it cuts the wrong way. The reflexive assumption is that automation will close the last mile. It does the opposite. AI automates the vendor's side of the stack — the deployable, repeatable, day-1 work — far faster than it touches the client's messy day-2 reality. So the part of the problem that was always ownerless is the part that doesn't automate, and it is growing as a share of the whole. Worse, AI is itself becoming a new population of non-human identities: every AI tool connected to a system is another standing grant handed out faster than anyone can govern it. The mile is lengthening, and it still has no owner. (I'll take that argument apart properly in the next post.)
The evidence
I didn't arrive at this by theory. I arrived at it by writing up incident after incident and noticing they were all the same incident wearing different clothes. The forensic series is the evidence; here is the pattern it makes.
Sometimes the vendor is breached and the incident still belongs to the customer — as when an identity provider's support system leaked session tokens and the customers, not the vendor, had to detect and contain it. Sometimes every technical control is in place and an attacker simply talks a help desk into resetting a factor — and then does it again two years later, through an outsourced service desk, because nothing structural had changed. Sometimes the vendor is genuinely not at fault and the customer is breached anyway, because multi-factor authentication was available but never enforced. And increasingly the human is bypassed entirely, and a stolen integration token or a forgotten OAuth grant to an AI tool does the work.
Different mechanisms, one constant: in every case, the control that would have caught it sat in the gap between the vendor and the client, owned by neither. Enforcing MFA on the forgotten account, scrubbing the diagnostic file, verifying the caller, reviewing the grant, rotating the secret — none of these is a feature you can buy, and none of them is a thing a busy internal team reliably does forever. They are the mile.
There's a tell that confirms it. In the incidents where someone detected a vendor's breach early, it was almost never the vendor — it was a customer with an operation watching its own identity events closely enough to notice. A customer flagged the CircleCI compromise from the outside; a customer caught the Okta support breach before Okta confirmed it. The organizations that come out of these incidents intact are the ones where someone was standing on the mile full-time. That someone is not a product. It is a role — and at most companies, the role is empty.
The objection
The strongest argument against all of this is worth stating in its full strength, because if I can't answer it, I don't have a thesis. It goes: this isn't a structural problem, it's just bad implementation. Competent integrators and a decent professional-services engagement close this gap. You're describing sloppy work and calling it a law of nature.
Here is why that's wrong, and it comes down to a single word: when.
Integrators are real, and good ones do real work. But an integration project closes day one. It deploys the product, configures it well, migrates the accounts, documents the runbook, and hands off. Every incentive in that engagement points at a finish line. The last mile is day two, and it never ends. It is not a task you complete; it is a posture you hold — re-checking that MFA is still enforced on every account today, including the legacy tenant someone spun up last week; noticing the new OAuth grant this morning; verifying the reset this afternoon; rotating the secret that just showed up in an infostealer dump. No integration project I have ever seen concludes with "and now someone will do all of this, every day, across the whole estate, for years." That sentence has no owner, and the gap between "deployed correctly" and "operated correctly forever" is precisely the mile. Good implementation closes the front door. It does nothing about the fact that the door has to be re-checked every day, by someone whose job that is.
So no — this is not sloppiness. The sloppiness, when it happens, is a symptom. The disease is that continuous identity operation is structurally unowned: too operational for the vendor, too specialized and relentless for the client, and not the kind of thing that fits inside a project with an end date.
What follows
If the work is real, continuous, and ownerless, then the practical question is not "which product do we buy" but "who owns the mile." And the honest implication — which I'll develop across this series rather than assert here — is that the only party structurally positioned to own it is the one already standing on it across many clients, seeing the same failure modes repeat often enough to recognize them. That is a managed operator's natural position, whether or not anyone has named it as the job.
For anyone running identity today, the shift is one of framing. Stop treating identity as something you deploy and start treating it as something you operate. The unit of work is not "implement the IdP"; it is "hold posture across the estate, indefinitely." Budget for the day-2, not just the day-1. Assume that some of your incidents will pass authentication cleanly, so your defense lives in continuous review and detection, not in the login screen. And count the identities that aren't human, because that is where the mile is growing fastest and where almost no one is looking.
None of that is a pitch. It's just what the incidents have been saying, over and over, for years, to anyone willing to read them as a set instead of one at a time.
Where this is going
This is the first piece in a series that argues the thesis properly. Next I want to take apart the claim that AI will rescue us — the way automation rewrites the split of responsibility between vendor, operator, and client, and why it moves the line without ever supplying an owner. After that: who can actually own the mile and why they avoid it, a responsibility map for when identity breaks, and why "build versus buy versus framework" is a false choice that misses the real axis.
The thesis won't change as the series goes on. The evidence will keep arriving — because the mile is still ownerless, and it is patient. The principles behind all of this are written down separately, and the incidents that prove it keep coming.