The endpoint is where the exploit lands.
Identity tells you who got in. The endpoint is where they end up working — and where most architecture conversations stop, right at the point where the interesting failures start.
Why the endpoint
I spent years securing the perimeter, then years securing the data pipeline. Both were the right work at the right time. The endpoint is where I work now, for a simple reason: it is where attackers actually land, and it is the layer most security programmes measure least honestly.
When an exploit runs, the question of which endpoint is already answered. The open questions are the ones worth writing about — what executed, with what privileges, in what context, and what your detection stack did or did not do about it.
The detection gap
Endpoint detection is very good at a narrow band of behaviour and structurally blind outside it. The request that arrives after the code has already run. The response that is a perfectly ordinary HTTP 200. The interpreter that logs the error to a place nothing reads. These are not exotic evasion techniques; they are the shape of ordinary, successful exploitation in a web-facing stack — and they are invisible to tooling that was built to watch process trees.
Coverage as evidence
Most organisations can tell you what they deploy. Far fewer can tell you what is covered — and almost none can hand you a statement about it that anyone has signed. Detection coverage is measured constantly and attested almost never. That gap is not a product gap so much as an evidence gap, and it is the question that shapes everything I write here.
The current arc
The current arc: the runtime, the worker process, and the detection gap around them. Each post ships when it is finished — nothing is listed as published before it is.
The runtime is the host
A web-facing exploit is an endpoint problem: the interpreter, the worker process that executes it, and the EDR that never classed it as a host event.
The detection that should have fired
What endpoint detection should have caught and cannot reliably: the quiet HTTP 200, the “in Unknown on line 0” tell, the ASLR and error-display gap.
From token to foothold
The bridge post: how a credential or identity flaw becomes an endpoint foothold — auth is the door, the endpoint is the room.
What coverage should mean
The architect's view: detection coverage is measured but rarely attested. ATT&CK is the coordinate system; the signed statement on top of it is missing.
The history that got here
This site started on the Identity pillar, and that work is not retired — it is the reason the endpoint question is even interesting. An auth flow flaw is what puts someone inside; the endpoint is where they go next.
4 posts of identity attack-chain research — OAuth interception, redirect URI manipulation, and the lab blueprint that made them reproducible — all still live in the archive, alongside FlawedToken, the open vulnerable OAuth 2.0 lab.
What I bring to it
Endpoint security architecture with a research habit — IBM Security, CrowdStrike, Trend Micro — plus CISSP®, and a working lab for anything I claim publicly. The identity work on this site came out of that habit; the endpoint arc is the same method pointed at the layer where exploitation finishes.
I'm open to endpoint security architecture roles and to research collaboration.