Endpoint detection is one of the genuine success stories in security. It works. Over the past decade it got very good at the thing it was built for, which is spotting malicious code running on a machine you control.
That success is exactly why attackers stopped writing malicious code.
The clean process problem
Walk through what an identity attack looks like from the endpoint's point of view.
Somebody's credential gets phished, or their session token gets lifted from a browser. The attacker loads that token into their own browser and opens Outlook Web, or SharePoint, or Teams. They read mail. They search a document library. They download a few thousand files. They create some sharing links. They add a forwarding rule.
Now ask an endpoint tool to describe what it saw.
On the victim's machine: nothing. The attack didn't happen there. The token was taken, possibly weeks ago, possibly by an infostealer that the endpoint tool did catch and clean, which is its own kind of painful, because cleaning the malware doesn't invalidate the token it already sent.
On the attacker's machine: also nothing, because you don't have an agent on it and never will.
And on the service side, where the actual damage happened, there's no process to inspect at all. Every request that arrives at Microsoft 365 is a well-formed authenticated API call from a legitimate client. There's no binary, no injection, no persistence mechanism on disk, no privilege escalation. The most sensitive operation in the whole chain, downloading several thousand documents, is a series of ordinary HTTPS requests that look exactly like a person syncing their files.
The credential is the malware. That sentence gets repeated a lot, and its operational meaning is specific: there's no artefact for a signature to match and no behaviour on the host for a behavioural engine to flag, because the malicious behaviour isn't on a host.
Three assumptions that no longer hold
EDR's model rests on three premises. Each was reasonable. Each is now optional for an attacker.
"The attack runs on a machine." It runs on a machine, and increasingly that machine is a virtual server the attacker rented for the afternoon. Your agent coverage is irrelevant to a device you'll never own.
"Malicious activity looks different from normal activity." It looks different at the volume level and identical at the action level. Every single download the attacker performed is an action the user was entitled to perform. Nothing in the request distinguishes them. The only distinguishing feature is that there were three thousand of them in twenty minutes, and volume over time is not a thing an endpoint agent is positioned to see, because the endpoint isn't where the volume accumulated.
"Compromise means code execution." It means credential possession. There's a whole class of incident now where no code ever ran anywhere in your estate, and the entire event was an attacker using a token correctly.
The token theft loop, and the trap inside it
There's a specific sequence worth spelling out, because a lot of teams have lived through it without recognising the shape.
An infostealer lands on a laptop. The endpoint tool detects it, quarantines it, and closes the ticket. Genuine detection, correct response, good outcome.
Except the stealer's job was done in the first few seconds. It read the browser's cookie store and sent session tokens out. Those tokens are now somewhere else, and they're still valid. Killing the process doesn't recall them. Resetting the password often doesn't invalidate them either, depending on how sessions were issued. The account looks fine, the endpoint looks fine, the ticket is closed, and somebody else is signed in as your user.
The trap is that the endpoint incident closing successfully is what stops anyone from looking further. The tool did its job and reported a win, and the win is real, and the compromise continues.
If your incident process ends when the malware is cleaned rather than when the sessions are revoked and the account's subsequent activity is reviewed, this is a gap you currently have.
What actually closes the gap
If the attack has no process, no file and no host, then detection has to happen where the attack does have a footprint, which is the service side. Three signals carry almost all of the weight, and none of them is available to an endpoint agent.
The device, reconstructed from activity rather than from enrolment. An enrolment-based inventory can't describe a machine that never enrolled, which is precisely the category the attacker's machine falls into. Rebuild devices from what actually shows up in audit activity and an unfamiliar machine becomes a row with history: how many users it's been seen with, how many addresses, whether it ever authenticated at all. That last one is the sharpest single signal in this whole space. Data accessed by a machine with no observed sign-in means the credential and the machine using it have come apart, which is token theft described without using the phrase.
The origin, resolved to a place rather than an address. Country, city and the network that owns the connection. A hosting provider in a country you don't operate in is one of the cheapest tells available, and it costs nothing to compute. It's also the signal most commonly ruined by noise, because a lot of Microsoft 365 operations record Microsoft's own datacenter address rather than the user's, and teams that get flooded with phantom foreign logins end up suppressing the exact category the attacker is hiding in.
The volume, measured against that identity's own history. The attacker's actions are individually legitimate and collectively absurd. An account whose normal is forty document reads a day doing two thousand this morning is the whole detection, and it only works if the baseline already existed before today.
EDR is not the thing that failed
It's worth being fair here, because the point isn't that endpoint tooling is bad.
Endpoint detection answers "is something malicious running on this machine?" That's a real question, it still matters, and the tools answer it well. The problem is that a different question became the important one, and the industry kept pointing the old instrument at it.
The new question is: is this identity behaving like itself?
That question needs data the endpoint doesn't have and can't get. It needs the identity's own history, the machine's history across sessions and users, the origin of each action, and the permission graph that says what the identity could reach. All of that lives on the service side, in audit activity, which is a completely different collection surface.
So it isn't a replacement argument. It's a coverage argument. Endpoint tooling covers the machines you own. Identity monitoring covers the sessions that use your data, including from machines you'll never own, which is where the modern incident actually happens.
The test worth running
A short exercise that tends to end the debate internally.
Take a real user account. Assume, as a thought experiment, that someone in another country has held a valid session token for it since Monday and has been reading files ever since.
Now ask, honestly, which of your current tools would have produced a signal.
- The endpoint agent on that user's laptop: no. The activity isn't happening there.
- Access control: no. Every request was authorised.
- DLP: maybe, if the content matched a policy and the operation was one it watches. Often not, since reading is not exfiltration until something leaves.
- Sign-in risk detection: possibly, depending on tier and on whether the origin was interesting enough.
- Anything comparing today's volume against that account's own normal: only if you have it.
The number of organisations for whom the honest answer to that list is "nothing would have fired" is much higher than anyone likes to admit, and it's usually not because the tools are misconfigured. It's because the tools they own were built for a different attack.
How 1Security fits
1Security is built for the attack that looks like an employee, which means it sits on the service side and correlates the three signals above on one timeline.
Devices get reconstructed from real activity and classified as registered, unregistered or shadow, with shadow meaning data access with no observed authentication at all. Every action resolves to a stable location of country, city and network owner, with Microsoft's own infrastructure recognised and labelled so real foreign origins stay visible instead of being suppressed along with the noise. Every identity, including applications and AI agents, carries a continuously maintained baseline, so a volume spike is measured against that account's own normal rather than against a threshold someone guessed.
Then the part that decides the response rather than the detection: the permission graph is resolved in advance, so the moment an account looks compromised, every file, site and mailbox it could reach is a lookup rather than a week of log stitching.
It runs read-only, on standard Microsoft 365 licences, with no agent to deploy anywhere.
Frequently asked questions
Should we drop EDR then? No. It covers a real attack class that hasn't disappeared, and it's often what catches the infostealer that started the identity incident. The argument is that it can't cover this one, so treating it as your identity control leaves a gap.
Doesn't MFA solve token theft? MFA protects authentication. A stolen session token represents an authentication that already succeeded, which is precisely why attackers target tokens. Phishing-resistant methods and shorter session lifetimes both help, and neither makes the post-authentication activity visible.
Isn't this what Defender or a sign-in risk engine does? Partly, and if you have those tiers, use them. They score the sign-in. They don't tell you which machine, don't resolve the origin into a place you can reason about, don't hold a per-identity activity baseline, and can't tell you what the account could reach. Those are the four things a verdict needs.
What's the single highest-value signal to add first? Device discovery from activity. It's the one that surfaces the attacker's machine, it requires no premium licensing, and on most tenants the first run finds unregistered devices touching data that nobody knew existed.
