Ward · endpoint defence
Ward is not another endpoint security product.
It manages whichever engine you already run — Microsoft Defender, SentinelOne, Huntress, whatever is there — watches what that engine cannot see, and does something when it fires.
It ships no kernel driver
On 19 July 2024 a content update to one took down 8.5 million machines. The enforcement stays with Microsoft, who sign it, certify it and carry it. Ward decides what to do about what it sees; it does not sit in your kernel to do it.
The number a console cannot produce about itself
Your RMM reports 247. Ward finds 289.
A worked example — not a customer estate
A console can only show you machines that already carry its agent. It cannot show you the ones that do not, and those are the only ones that matter. Ward has both halves — the console and the estate — so it can name the difference.
Protected and reporting
The agent is installed and the telemetry is arriving. This is the state every console shows you, and it is the least interesting of the four.
Protected and silent
Installed, present in a console, sending nothing. Disabled, broken, or excluded by a policy somebody wrote in 2023. A console cannot tell you this, because from where it is standing the machine simply stopped.
Unprotected
On the network, no agent, nobody managing it. Ward finds it because it is looking at the estate rather than at the console.
Unknown
A machine nothing has ever seen. Recorded as unreachable, never as clean — absence is not confirmation.
The argument a single-vendor stack cannot answer
When somebody blinds the EDR, Ward is still watching.
A killed sensor cannot report that it has been killed. Its console shows a machine that stopped checking in, which looks identical to a laptop somebody closed.
Ward sees it from the other side. The estate, the RMM and the collector all still see that machine. If the agent is silent and the RMM is not, the machine is alive and the sensor is not. That is not a cleverer detection — it is a second vantage point, and a vendor whose product is the sensor does not have one.
A file arrives, and this is what happens
Sixty seconds, from an endpoint to the brain and back.
Two moments matter. The line stops at nine seconds — she cannot establish whether it is malicious, and says so rather than guessing. And at forty-eight the file does not cross. A shape and a hash rise to the fleet; the file itself stays on your hardware, where it was.
Detonation runs locally by default · a shape and a hash go up, a detection and a block come down
An investigated alert, not an alert
A detection opens an investigation that runs itself.
The process tree. What that binary is and where it came from. What this user normally does on this machine at this hour. What else the machine touched. Whether a change ticket explains it. And what four hundred practices have seen.
And the question a junior never asks
What would make this benign? An investigation that only looks for confirmation is a confirmation.
And the rest of what it does
One incident, not nine alerts
Nine quiet events across four machines over six days are one incident. Every one of them individually beneath any threshold worth alerting on — which is exactly why they are the ones that get through.
The hunt that publishes nothing
“We looked for this on your estate on Tuesday and did not find it.” A negative result, written down. An empty answer is only worth something if you can show the looking.
A file nothing legitimate touches
A canary sits where no process has business going. A touch has one meaning rather than a false-positive rate to argue about.
Identity, at runtime
Sixty-seven per cent of incidents at this size are identity-related, so Ward watches what an account does rather than only what a binary does.
The false-positive rate, published
Per detection, on the page. Every endpoint vendor has this number and none of them publishes it.
Thirty days · read-only · no card
Point it at your estate and see how many machines nobody is managing. That number is the whole argument.