It is a little after two in the morning and a laptop in your business starts behaving oddly. One process starts another, a set of credentials is reused, and a connection opens to somewhere it has no reason to go. Your endpoint tool sees it and raises an alert.
What happens over the next half hour comes down to a plain question: who reads that alert, and how quickly can they act on it? In a lot of businesses the alert waits until someone logs in at eight or nine.
Ransomware was involved in 48% of the breaches in Verizon's latest Data Breach Investigations Report (Verizon 2026 DBIR). Much of the damage happens in the gap between a tool that detects at 2am and a person who responds at 9am.
Three terms that get used as one
EDR, XDR, and MDR are often treated as interchangeable, and they describe different things. EDR (endpoint detection and response) is the sensor: the agent on each device that records what runs and can act on it. XDR (extended detection and response) is the correlation, joining the endpoint signal to identity, email, cloud, and network, so that a quiet event in each becomes one visible story. MDR (managed detection and response) is the people: a team watching the alerts around the clock and containing the problem on your behalf.
Which of those three you are buying usually matters more than whose logo is on it.
Who operates it
When we think about the IT leaders making this decision, it helps to start with who they are. They range from infrastructure managers to heads of security, in teams of two people or a hundred, and the message I hear over and over is the same: we're too busy. In my experience the larger teams have the skills to run detection well a good part of the time. The capacity to watch it every hour of every day, including weekends and public holidays, is much rarer. They've got the smarts, just not the capacity.
That is why the operating model tends to decide the outcome more than the sensor does. For most of the businesses we work with, the sensible route is the platform vendor's own managed service, because it puts experienced people on the alerts at 2am without the business building a security operations centre of its own. We resell and help run that service. We don't sit in the chair, and it would be wrong to suggest we do.
A capable floor, and what it leaves
Microsoft Defender belongs in this conversation. It is a capable floor, and for many businesses it is a sensible place to start. The gaps it tends to leave are round-the-clock operation, which still needs people watching, and correlation beyond the endpoint, which depends a good deal on the licence you hold.
Ask an IT lead what a good outcome looks like and the answer is often the platform they rarely have to open, because it caught the problem and contained it before it became their morning. Features earn their place as evidence of that outcome: how fast the team contains, how lightly the agent sits on a machine, and how the vendor behaves when something goes wrong.
Detection and response is also one of three layers on the endpoint, alongside prevention, which decides what is allowed to run, and hygiene, which closes known weaknesses through patching. The less a prevention layer lets run, the less the team watching at 2am has to chase.
See it in your own environment
You can test this before committing. A proof of concept on machines that look like yours will show what the platform catches and how quickly the team behind it responds. Where the worry is the rollout itself, the vendor can treat the deployment as the proof of concept, showing it installs cleanly on a small group before it touches production.
The number to ask for is mean time to respond, because it is the one a board can act on. Cyber insurers increasingly ask about detection and response at renewal, so the exercise often gives you a straight answer to a question you will be asked anyway.