Your endpoint vendor says they do MXDR. Here is how to check.

Sep 1, 2026, 2:36:04 PM

11:02

Your EDR vendor has a managed service, and the datasheet now says MXDR. The question is not whether the EDR service is good. Most are really good. The question is what it covers, because the label has been stretched to fit almost anything.

An endpoint vendor's managed service qualifies as MXDR when it does three things: ingests telemetry from sources outside its own agent, correlates those sources into a single incident, and executes response actions beyond the endpoint under controlled authorization. Ask for evidence on all three. The questions below can be worked through in one meeting, and every answer should be verifiable in your own console and contract.

What is the difference between managed EDR and MXDR?

Gartner defines Managed Detection and Response (MDR) as remotely delivered SOC functions running on "a predefined technology stack that commonly covers endpoints, networks, logs and cloud," and requires "immediate remote mitigative response, investigation and containment activities (such as quarantining hosts), beyond alerting and notification." The X in MXDR just makes it clear that the vendor's service is built upon an XDR platform.

Managed EDR is a legitimate service. It monitors the vendor's agent on hosts where the agent runs, and it responds at the host: kill a process, quarantine a file, isolate a device, roll back a change. That work stops real attacks, and it is the fastest containment available at the endpoint layer.

The difference is scope, not quality. A service that watches one domain very well is not the same as a service that watches several and connects them. Both are worth buying under the right conditions. However, only one of them answers the question "what happened across my environment?". You should know which one you are paying for before you find out during an incident.

Why does scope matter more in a mid-market environment?

Because endpoint agent coverage is never complete, and mid-market environments are where the gaps concentrate.

In a 100 to 5,000 employee organization, the following typically have no endpoint agent: network gear, printers and multifunction devices, cameras and building systems, manufacturing and lab equipment, legacy servers that can’t take the install, contractor laptops, personal devices touching email, and whatever arrived through the last acquisition. Attackers don’t avoid those systems. They prefer them.

There is also the staffing gap. Enterprise buyers have people who can pull three consoles together at 2 a.m. and reconstruct an attack timeline. Mid-market IT teams have two to twelve people covering all of IT and security. Correlation across tools is not a task that fits into that day.

What should you ask your endpoint vendor?

Ten questions, in four groups. Ask for specifics, not categories. "Yes, we integrate with identity providers" is a category. "We ingest Entra ID sign-in logs and audit logs by API, and here is what we detect from them" is a specific.

Coverage: what do you actually see?

Q1. Which telemetry do you ingest besides your own agent? Ask for the list by name: firewall, identity, email, SaaS, cloud, network. Then ask which of those are ingested for detection rather than displayed for reference.

Q2. What do you see on a device where your agent cannot run? Every environment has them, and the answer is usually "nothing." Take that seriously. The follow-up question is how many such devices you have. The honest way to find out is to compare your agent count against your DHCP leases or your switch port inventory. The delta is your blind spot, measured. A vendor who says "nothing" plainly is at least being straight with you. That's worth more than a vague claim of partial visibility, but it's still not coverage.

Q3. Is east-west network traffic in scope, and how do you collect it? Firewall logs show traffic crossing the perimeter. They do not show a compromised workstation moving laterally to a file server. Those are different data sources and the distinction is worth understanding.

Correlation: do the signals get connected?

Q4. When endpoint, identity, and network signals belong to the same event, do I receive one incident or three alerts? Correlation is the entire premise of XDR. If the output is three alerts with three severities, the correlation is happening in your head (maybe) - not within an intelligent platform.

Q5. Are findings mapped to MITRE ATT&CK techniques across all ingested sources, or only endpoint sources? Consistent mapping across domains is a reasonable proxy for whether the domains are genuinely unified.

Response: what can you execute, and who authorized it?

Q6. What response actions can you take outside the endpoint? Can you disable an account, revoke active sessions, force a credential reset, change a firewall rule, delete a malicious inbox rule, remove a malicious OAuth application?

Q7. Which of those actions are pre-authorized, and where is that documented? There should be a written standard operation procedure (SOP) that names each action and states whether it is pre-authorized or requires your approval. If it lives in someone's memory, well...

Q8. What happens if containment fails? A quarantine that does not take, an isolation command that does not land. Ask what the fallback is and who is called.

Output and accountability: what do I receive, and from whom?

Q9. What do I receive when something happens? An alert? A ticket? Or a written report with a timeline, affected users and systems, business impact, and prioritized next steps? There is a sizable difference between being told something happened and being told what to do about it.

Q10. What is your response time commitment by severity, and is it in the contract? Also ask what is explicitly out of scope. Full digital forensics, litigation-driven investigation, on-site containment, threat actor negotiation, and system recovery are commonly excluded from MXDR and sold separately. That exclusion is normal. Discovering it mid-incident is not.

How do you verify the answers instead of taking them on faith?

Three checks you can run yourself this week.

Read the last 90 days of incidents you were notified about. Count how many referenced a data source other than the endpoint agent. If the answer is zero across a quarter, the service is operating as managed EDR - regardless of what the datasheet says.

Search the statement of work for the words "out of scope." Whatever appears there is the real boundary of the service. Everything else is marketing.

Take one real incident and ask them to walk the timeline with you. If the timeline opens and closes on a single host, that is your coverage, demonstrated rather than described.

What if the answers come back thin?

You have three options, and replacing your EDR is not in that set:

Expand the telemetry you already own into the service you already pay for, if the vendor supports it.
Add a layer above the EDR that ingests across sources and correlates.
Accept the scope, document the gap, and plan around it deliberately.

All three are plausible. #2 is the best.

Gradient Cyber built Quorum AI for the middle option. QAI ingests telemetry from endpoint, network, identity, SaaS, and cloud, normalizes it to OCSF, and runs it through an eight-stage detection pipeline before a Cyber Analyst validates the finding and writes it up. Network traffic is collected out of band by the Quorum Collector, so lateral movement and command-and-control traffic are visible whether or not an agent is present on the device involved. Enforcement runs through the tools you already own, including CrowdStrike, SentinelOne, Microsoft Defender, Sophos, Palo Alto Cortex XDR, and others, plus supported firewall and identity platforms. Keep your EDR. Add correlation and response above it.

Held to our own checklist: full digital forensics, litigation-driven investigation, on-site containment, threat actor negotiation, and system recovery are out of scope for our MXDR service. We engage an established incident response partner for that work and keep our own detection, advisory, and reporting workflow running alongside it. Active Response, where we execute containment directly, is governed by a customer-approved authorization matrix per action type, and every action is logged in QAI.

Run these ten questions against whoever monitors your environment today. If you want our answers, ask, and we'll put them in writing, including the ones where the answer is no.

Frequently asked questions

Is managed EDR the same as MXDR?

No. Managed EDR monitors and responds within endpoint telemetry from the vendor's own agent. MXDR extends detection and response across endpoint, network, identity, SaaS, and cloud, and correlates those sources into a single incident. Managed EDR can be excellent within its scope. The distinction is coverage, not quality.

Can an endpoint vendor deliver real MXDR?

Yes. Several endpoint vendors run legitimate managed detection and response services with genuine cross-domain capability. The question for a buyer is not whether the service is real but whether its coverage, response authority, and output fit your environment - and your budget. Ask which third-party sources are ingested for detection, what response actions are available outside the endpoint, and what is written as out of scope.

What telemetry should an MXDR service ingest?

At minimum, endpoint, network, identity, cloud, and SaaS or email. Network telemetry matters most in environments with unmanaged devices, because it observes activity on systems where no agent can be installed.

What response actions should an MXDR provider be able to take?

Beyond endpoint actions such as kill, quarantine, isolate, and rollback, an MXDR provider should be able to act on identity and network: disabling an account, revoking sessions and tokens, forcing a credential reset, and changing firewall rules. Each action should be covered by a standard operating procedure (SOP) stating whether it is pre-authorized or requires customer approval.

Do I have to replace my EDR to get MXDR?

No. A data-source agnostic MXDR service ingests telemetry from your existing EDR, firewall, identity, and cloud platforms and uses those same platforms as enforcement points. The EDR stays. The correlation and response layer sits above it.