Palo Alto sells managed detection by arguing that managed detection is the wrong model. Their own launch material for the current version says traditional SIEM and MDR were built to react to alerts rather than to continuously improve detections and response against threats moving at machine speed. Whether or not you accept the framing, the product built on it occupies an architectural position nothing else in this series does, and it is the one most likely to collide with decisions you have already made about your log platform.
The service is Unit 42 Managed XSIAM. It combines their security operations platform with the Unit 42 organisation, which is a threat intelligence and incident response practice with a long history rather than a managed service team assembled to staff a product. Analysts, threat hunters, responders and embedded security operations engineers run the platform in your environment, twenty four hours a day, with continuous detection, investigation and full-cycle remediation. Version two of the offering arrived in February 2026.
The mirror image of the endpoint replacement
The distinction that matters here is easy to miss because both look like buying a platform. CrowdStrike, elsewhere in this series, replaces your endpoint agent and adds a log platform alongside it. Palo Alto does the reverse: the platform they operate is the analytics and data layer, and it explicitly ingests from native and third-party endpoint tooling, including what you already run. Your Defender deployment can stay exactly where it is.
What gets displaced instead is the layer above. Their material describes holistic visibility across more than a thousand native and third-party integrations, with what they call zero-touch data onboarding, where their team handles ingestion, mapping and ongoing maintenance rather than leaving it as your engineering burden. That is an attractive proposition for anyone who has tried to keep a log pipeline healthy without a dedicated team, and it is also the moment your security data platform decision gets made for you.
They will operate the endpoints you own. The thing they replace is the platform your security data lives in, which is a larger commitment than most buyers realise they are making.
If you have already chosen Sentinel, or you are in the middle of that decision, this profile is not really a managed detection evaluation. It is a data platform evaluation with a service attached, and it needs the people who own your log architecture and its ingestion economics in the room. That conversation deserves more room than this article, and I will treat it properly when I write about the security information and event management decision on its own terms.
Detection engineering as the actual product
Most providers in this market sell you their detection content and improve it globally. This one sells you detection engineering applied to your environment specifically, and that is the substantive difference behind the marketing about continuous optimisation.
The described cycle runs as follows. Their research organisation finds a technique in the wild, produces an assessment of how that technique applies to your particular environment, and then translates it into custom detections and automated response actions for you. They also monitor and investigate correlation rules your own team has written, which is a meaningfully different posture from providers who work only their own content and treat your rules as noise.
For an organisation with detection engineering ambitions and no capacity to sustain them, this is the strongest argument on the list. It is also the part hardest to evaluate from outside, because detection engineering quality is invisible until the day it matters. Ask for the threat impact assessments as artefacts during a trial, and ask what happens to the custom detections built for you if you leave, because content developed for your environment on a platform you do not own is a form of lock-in that nobody prices.
Response, tiers, and what is not published
Full-cycle remediation is the stated model, meaning containment and cleanup rather than notification, and the service is sold in tiers running from platform operations through to embedded security operations engineering. That tiering is the right shape: the difference between an organisation buying analysts and one buying an engineering function is real and most providers pretend it is not.
What I could not establish from public material is the authority boundary in the terms this series cares about most: which actions their analysts take in your environment without contacting you, whether that is configurable, and whether any of it is scoped by asset class. Given the platform-operated model, the practical answer is likely broad, and broad is defensible, but it should be established in writing rather than inferred. The same applies to service levels: response commitments are described qualitatively rather than as a defined clock with a remedy, which after the previous article in this series is a comparison worth making explicitly.
The incident response heritage is a genuine advantage and it is not marketing. Unit 42 has been doing breach response for a long time, and their annual reporting is among the better primary sources on how intrusions actually unfold; the current edition observes that some end-to-end attacks now complete in under an hour. Buying detection from an organisation that also runs the incident response practice means the escalation path from monitored to breached does not involve finding a firm on the worst day of your year.
Overlap, and the honest cost question
For an organisation on E5 the overlap is narrower than CrowdStrike and wider than the agentless providers. You keep Defender for Endpoint and Defender for Identity, and those keep producing signal that the platform ingests. What you stop using, or never start, is Sentinel, along with whatever you had planned for long-term log retention and correlation. Whether that is duplication or substitution depends entirely on how far down the Microsoft path you already were.
Model it as a three-year data platform cost rather than a managed service subscription, because that is what it is. Include ingestion volume, retention, what you were already paying Microsoft, and what your own team currently spends keeping pipelines alive, since removing that burden is a real part of the value and belongs in the arithmetic rather than in the sales deck.
There is also a network adjacency to keep in view. This company’s secure access platform overlaps the ground Entra now covers with its own internet and private access capabilities, and the same concentration question raised elsewhere in this series applies: one vendor holding your network path, your security data platform and your response authority is coherent, and it is concentrated. Neither word is a criticism on its own.
Identity, and the AI claims
Identity is covered as one of several attack surfaces the platform correlates across, alongside endpoint, cloud and network. That is a data-layer treatment rather than an engineered identity discipline, so there is nothing here comparable to inline authentication decisions or to the specific hybrid directory containment work two other providers in this series built. The correlation across surfaces is genuinely valuable, since real intrusions cross domains and single-domain tools miss the movement between them. It is simply a different strength from identity depth, and if identity is where your incidents start, weigh accordingly.
On artificial intelligence, the two tests. For governing your users’ generative AI usage, nothing in the managed service does this; anything in that direction would come from the network platform rather than from the detection engagement, which is the same licensing seam that appears elsewhere in this series and should be asked about the same way. Inside their own operations, AI-driven analytics and agentic automation are central to the product story rather than decorative, and the mechanism is at least described: models and dynamic detectors doing correlation and containment across surfaces, with human analysts and engineers running the service around them. That clears the bar I set, though the specific question of what a model may execute without a human deciding is one I would put in writing during evaluation, because agentic automation and delegated response authority are the same question asked twice.
Where this lands
This is the right conversation for an organisation that has outgrown alert-driven monitoring, has data volume and correlation problems rather than a simple staffing gap, and has not yet committed its security data platform. You get engineering capacity and an incident response practice attached to a product built for exactly that shape of problem.
It is the wrong conversation if what you actually need is somebody watching a Defender tenant overnight. The capability is real and the commitment is large, and buying a security data platform to solve a rota problem is an expensive way to solve a rota problem.
MDR
‹ Previous: [MDR 8] Critical Start: The Only Service Level With a Clock and a Remedy
Next: [MDR 10] What the Contracts Actually Say: Authority, SLAs, Overlap, and the GenAI Claim ›
