An alert lands. A user account did something slightly odd. Maybe a sign-in from somewhere unusual, maybe a burst of downloads, maybe a support ticket from someone whose mailbox rules changed on their own.
You now have exactly one question in front of you, and every other decision waits behind it.
Does this look like an attack?
Not "was this authorised", because it was. Not "did a control fail", because none did. Just: is this our employee, or is this somebody holding our employee's credential?
The honest experience in most organisations is that answering it takes the rest of the day. Someone pulls sign-in logs. Someone else exports SharePoint activity. A third person messages the user, who is in a meeting. The device identifier gets cross-referenced against Intune, which has never heard of it, which might mean something or might mean nothing. Around 6 p.m. a picture forms.
Twelve hours from alert to verdict is normal. It is also, in the specific case of an identity attack, close to useless.
Why the clock matters more here than anywhere else
For a malware incident, twelve hours is survivable. The payload is on disk, the process tree is recorded, the machine can be isolated at any point and the evidence keeps.
An identity attack behaves differently, and the difference is the whole argument.
The session is the asset, and sessions are short. A stolen token has a lifetime. The attacker knows it. The work gets done in one sitting, not over a week of patient lateral movement. By hour twelve the session that mattered has usually ended on its own.
The damage is copies, and copies don't get recalled. Once several thousand files have been downloaded, containment stops being about access. You can disable the account, revoke every session and reset the credential, and none of it reaches the copy. The window where response changes the outcome closes when the download finishes, not when you understand it.
The persistence gets planted early and it outlives the session. A forwarding rule. An OAuth grant to an application nobody recognises. Sharing links on the interesting folders, which is the one people forget, because a link keeps working after the account is disabled. Every hour you spend deciding whether this is real is an hour those artefacts sit there looking like configuration.
So the twelve-hour investigation isn't slow in a general sense. It's slow relative to a thing that finishes in forty minutes.
Where the twelve hours actually goes
Here's the part worth being precise about, because the usual explanations are wrong.
It isn't that the data is missing. Nearly every fact you need is already recorded somewhere in your tenant. It isn't that the team is inexperienced, and it isn't tooling in the sense of "we should buy a better console."
The twelve hours goes into joining things that were never joined.
The sign-in lives in one place. The file activity lives in another. The device is an identifier in both, but a meaningful description of it lives in a third system that only knows about devices it enrolled. The address needs an external lookup to become a location. The user's normal behaviour isn't recorded anywhere as such, so establishing whether today is unusual means eyeballing a few weeks of history by hand.
Five sources, each individually fast to query, and the work is entirely in the joins. Worse, each join is done manually, once, by a person, under pressure, at the exact moment when careful work is hardest.
That is why the number is twelve hours rather than twelve minutes. Not query time. Assembly time.
The four things that settle it
A login-shaped attack has no signature. It does have tells, and there are fewer of them than people expect. In practice a verdict comes down to four questions, and if you can answer all four quickly you can answer the big one quickly.
Who is the actor, and what is normal for them? Not the account's permissions. Its habits. How much does this person usually do in a day, and what does today look like against that? A finance clerk who reads forty documents a day and read two thousand this morning has already answered most of the question.
What machine is this? The one thing an attacker with a valid token usually can't supply is your user's laptop. Is the device enrolled, has it been seen before, how many other people have used it, and did it authenticate at all? A machine that accessed data with no observed sign-in behind it is the strongest single tell there is, because it means the credential and the machine using it have come apart.
Where did it come from? Not the raw address, which is noise. The place: country, city, and who owns the network. A hosting provider in a country you don't operate in reads very differently from the user's home ISP, and both are legitimate-looking sign-ins in every log you have.
Does the timeline hold together? Sign-in, then reads, then a burst, then sharing links created near the end. A real working day has a different shape from a session that arrived, took what it came for, and left.
None of these four is decisive alone. Together, they're usually conclusive within minutes, and the reason they aren't conclusive within minutes today is that they live in four different systems.
What "ten minutes" requires
The difference between a twelve-hour verdict and a ten-minute one isn't speed. It's what was computed before the alert arrived.
Baselines have to already exist. You can't establish what normal looks like for a user during an incident. Either their daily volume has been tracked continuously, in which case today's number has meaning immediately, or it hasn't, in which case you're building a baseline while under pressure and grading your own homework.
Devices have to be reconstructed from activity, not from enrolment. If your device inventory begins at enrolment, then the machines that matter most in an identity incident, the ones that never enrolled, are the ones it can't describe. Reconstructing them from real activity means an unfamiliar device identifier resolves to a row with history rather than to a dead end.
Addresses have to already be places. Resolving an address during an incident means an external lookup, a copy-paste, and a judgement call about whether a datacenter in Virginia is Microsoft's relay traffic or an attacker's rented server. Doing that resolution continuously, and labelling the platform's own infrastructure so it stops generating phantom foreign logins, means the location is a fact on the row rather than a task.
The permission graph has to be resolved in advance. The second question after "is this an attack" is always "what could they reach", and that answer is a graph traversal across direct grants, sharing links, group membership, site membership and inheritance. Computed on demand, at tenant scale, it's a project. Precomputed, it's a lookup.
Put differently: the ten-minute answer isn't a faster investigation. It's the same investigation, with the joins already done.
The uncomfortable version of the argument
There's a claim buried in this that's worth saying out loud, because it explains why we built what we built.
If you can't tell whether something is an attack within the hour, your detection quality barely matters.
A detector that fires accurately but hands you a question you can't resolve until tomorrow produces the same outcome as a detector that didn't fire. Both leave you understanding the incident after the copies were made. Improving the detector doesn't help. The bottleneck moved downstream of it, to the part where a human has to decide, and nothing in most stacks was built to make deciding fast.
This is also why "reduce alert volume" is a half-solution. Fewer alerts help only if each surviving alert is resolvable. Ten alerts a day that each take twelve hours to adjudicate is a worse position than a hundred that each take ten minutes.
The metric that actually predicts how an identity incident goes isn't detection coverage and isn't mean time to detect. It's time to verdict. Almost nobody measures it, and everybody has one.
How to measure yours this week
You don't need to buy anything to find out where you stand. Take a real alert from the last month, or invent a plausible one, and time the following.
- Pull this user's activity volume for the last thirty days and say whether today is unusual. Target: under a minute.
- Identify the machine behind the activity and say whether it's known, enrolled, and previously seen. Target: under a minute.
- Say what country, city and network the activity came from, and whether the user has ever been seen there. Target: under a minute.
- List every file, site and mailbox this account could reach, through every path. Target: under five minutes.
Add up the real times. That total is your time to verdict, and it's the number that decides how the next real incident goes. If it's measured in hours, the fix isn't a better alert. It's making those four answers available before you need them.
How 1Security does it
1Security exists because of that number. The design goal was a blast-radius investigation that takes ten minutes instead of twelve hours, and everything in the product follows from precomputing the joins rather than performing them during an incident.
Every identity carries a continuously maintained activity baseline, so "is today unusual for this account" is a value on the screen rather than a query. Devices are reconstructed from real activity and classified as registered, unregistered or shadow, so a machine that accessed data with no observed authentication shows up as exactly that. Every action resolves to a stable location of country, city and network owner, with Microsoft's own relay traffic recognised and labelled so it stops manufacturing phantom foreign sign-ins. And the permission graph is resolved in advance, so every file, site and mailbox a compromised account could reach, through direct grants, links, groups and inheritance, is a question with an answer rather than a week of log stitching.
Three years of activity memory sit behind it, without a SIEM contract, so the question "when did this actually start" has somewhere to look. It connects read-only, runs on standard Microsoft 365 licences, and produces its first findings the same day.
Frequently asked questions
Isn't this what a SOC is for? A SOC does the deciding. It doesn't fix the fact that the evidence arrives in five disconnected pieces. Give the same analysts pre-joined data and the same decision takes minutes, which is why this is an architecture problem rather than a staffing one.
We have a SIEM. Doesn't it already correlate this? A SIEM stores and searches events. Correlation across sources is something you configure, per use case, in advance, and it still doesn't understand permissions, so it can't answer "what could this account reach". It's excellent at showing you what happened once you know what to ask.
What if the verdict is "not an attack"? That's the common case and it's still valuable. Most of the cost of identity alerting is the time spent clearing the ones that turn out to be an employee working late from a hotel. Fast verdicts help the false positives more than they help the true ones.
How fast is realistic? The four checks above, when the underlying data is already joined, run in under ten minutes for a single account. What stays slow is the human judgement at the end, which is the part that should be slow.
