Managed XDR is an operating model, not a product. A provider runs an XDR platform on your estate: watching it around the clock, tuning what it detects, investigating what it raises, and acting on what turns out to be real.
The platform is usually one you could licence yourself. What you are buying is the operation around it.
Why organisations do not run XDR themselves
The usual answer is a skills shortage, which is true enough to be unhelpful. The more precise answer is that XDR has three running costs that are invisible at the point of purchase.
Detection content is never finished
Out of the box, detection rules are written for everybody, which means they are written for nobody. Making them fit one estate means learning what is normal in it — which service account legitimately touches that share, which admin behaviour is expected during a month-end close, which travelling user always signs in from somewhere new.
That knowledge decays. Staff change, applications are retired, a migration moves a workload and six rules quietly stop matching anything. Tuning is not a deployment task that ends; it is a standing job, and it is the single largest determinant of whether an XDR deployment is useful eighteen months in.
Coverage is a staffing problem, not a technology one
Genuine round-the-clock cover needs enough people to rotate sustainably, which is more than most organisations expect. Below that number you do not have 24/7 cover — you have an on-call rota, and the difference shows up at three in the morning on a Sunday, which is when it matters.
Investigation quality varies with who is on shift
The same alert handled by an experienced analyst and a new one produces different outcomes. Consistency comes from written procedure, review and enough volume for people to have seen the pattern before. A small internal team sees too few incidents to build that fluency quickly.
What an MXDR service actually covers
Scope varies more than the acronym suggests, but a complete service covers four things.
Monitoring and triage. Someone or something assesses every incident the platform raises, and separates the real from the routine. This is where volume is absorbed.
Investigation. The ones that survive triage get examined properly — what happened, what else it touched, whether it is still happening — and reach a verdict with evidence attached.
Response. Acting on the estate: isolating a device, disabling an account, blocking an indicator, quarantining mail. The important question here is not whether the provider can act, but under what authority and within what limits.
Engineering. Detection tuning, new content, and the ongoing work of keeping the platform matched to the estate. Services that omit this are selling monitoring, not XDR operations, and the difference compounds.
MXDR, MDR, SOC-as-a-service and co-managed SIEM
These overlap enough to be sold interchangeably and differ enough to matter.
| Model | What distinguishes it |
|---|---|
| MDR | Managed detection and response, usually anchored on endpoint telemetry and often on the provider's own agent. Broad term, variable scope. |
| MXDR | MDR where the detection surface is explicitly cross-domain — identity, email and cloud as well as endpoint — normally on an XDR platform you also own. |
| SOC-as-a-service | Describes the whole function being outsourced, including reporting, service management and often compliance support. Broader than detection alone. |
| Co-managed SIEM | You keep the platform and the content; the provider supplements your team. Shared responsibility rather than transferred. |
The labels matter less than two questions underneath them: whose platform is it, and who is accountable for the decision to close or escalate an incident. Those two answers tell you more about a service than its acronym.
Questions worth asking before you sign
Most MXDR proposals look similar. These are the questions that separate them.
Who owns the tenant and the detection content? If the provider builds rules, parsers and playbooks inside your platform, establish now whether those stay with you at the end of the contract. If they leave with the provider, your switching cost is far higher than the notice period suggests.
What is the provider allowed to do without asking? There should be a written answer, per action, that you set and can change. "We will contain threats" is not an answer. Isolating a device during a trading window and disabling an executive's account at the start of a board meeting are decisions with business consequences, and the boundary should be yours.
What happens when the alert volume spikes? Service levels calculated on a normal month describe a normal month. Ask what the commitment is during a genuine surge, which is exactly when the service either proves itself or does not.
Who answers at three in the morning, and where are they? Specifically: is overnight cover staffed at the same level as daytime, or is it an on-call rota, and how is an escalation actually reached.
How is it metered? Per incident, per user, per device and per ingested gigabyte all behave differently as you grow — and some of them bill you most in the months you were least protected. Understand the shape of the bill before the size of it.
What do you get when it ends? Data export format, notice period, and whether the provider is obliged to help you transition. Ask at the start, when you have leverage.
Where MXDR does not fit
It is a poor answer to a problem that is not detection. An organisation without asset inventory, patching discipline or identity hygiene will buy MXDR and receive a well-run stream of incidents arising from the gaps it already had. The service will work exactly as described and the risk will not move much.
It also fits badly where the estate is genuinely heterogeneous and no XDR platform covers the majority of it. At that point the correlation layer is doing less work than the integration effort costs, and a SIEM-led approach is usually more honest.
And it is the wrong model for organisations that need the security team in the room — handling regulated decisions, or where incident response is so entangled with business process that an external party cannot reasonably make the call. Co-managed suits that better.
The decision underneath
Choosing MXDR is mostly a decision about where accountability sits.
The platform question is usually settled by the estate. If the bulk of an organisation's identity, email and endpoints already sit with one vendor, the XDR that covers them natively is the obvious choice, and the remaining variable is who operates it.
That is the decision worth spending time on. Two organisations with identical licences and different operators get materially different outcomes, and the difference is not in the product — it is in how well the detection fits the estate, how fast an incident reaches somebody who can act, and whether that person is there when it arrives.