An MDR practice scales on two things: how much of each investigation is done before an analyst opens it, and how cheaply the next client can be onboarded. The two providers in this case study hit those limits in different ways. One was losing analyst time to swivel-chair investigations across every client’s CrowdStrike, Sentinel and XDR consoles, with playbooks that could not be managed as code. The other had outgrown its SOAR platform at 1,000-plus customer tenants. Both chose D3. Here is what each needed, how each is wired, and what they have in common.
Key takeaways
- Provider A chose Morpheus so analysts open a case that is already investigated, instead of pivoting across each client’s EDR, XDR and SIEM consoles to assemble it.
- Playbooks as code, created and deployed through an API in readable YAML or JSON under version control, was named a deciding requirement. Previous tooling exported playbooks encrypted and unreadable.
- Provider B replaced Palo Alto Networks Cortex XSOAR, which buckled at 1,000-plus tenants: queries that took 30 minutes, silent ingestion failures, no real multi-tenancy.
- On D3, Provider B onboards a customer in roughly ten clicks, runs regional deployments where residency demands it, and resumes any failed ingestion automatically from the point of failure.
- Both run autonomy per client. One client gets recommendations only; another gets bounded autonomous action. Same playbooks, different setting, every action recorded.
Terms used in this case study
The two providers
| Provider A | Provider B | |
|---|---|---|
| Business | Managed detection and response practice within a global technology company | Global managed detection and response provider, U.S.-headquartered |
| Footprint | Clients across multiple regions, each on its own detection stack | 1,000+ direct MDR customers across North America, EMEA and APAC |
| Client detection stacks | CrowdStrike, Microsoft Sentinel and other XDR platforms, varying by client | Customer endpoint, network and identity tools, varying by customer and region |
| Before D3 | Analysts pivoting across client consoles; playbooks managed one at a time with no API; no automated handling of low-priority noise | Palo Alto Networks Cortex XSOAR, which could not carry the tenant count: performance collapse, silent ingestion failures, single-instance multi-tenancy |
| Scale problem | Investigation effort per alert, multiplied by clients | Tenant count, onboarding speed and regional data residency, all growing at once |
| Status | Selected D3 Morpheus in 2026; onboarding the first client stacks | In production across the service delivery platform and the internal SOC; growth plan of 2,000+ new tenants a year |
Provider AOne AI SOC over every client’s detection stack
Provider A’s analysts were building each investigation by hand, one client console at a time. The practice wanted investigations to arrive pre-built and playbooks to live in a pipeline.
What was wrong
Four problems, in the team’s own ranking. Swivel-chair investigations: analysts pivoted between each client’s EDR, XDR and SIEM consoles to gather context, and no single view of a threat existed until someone built one. Playbooks managed one at a time: previous tooling had no API to create, edit, export or import playbooks, and exports were encrypted and unreadable, so nothing could be version-controlled. Client communication that would not scale: no API access to the ticketing platform blocked a two-way channel with clients. And volume without triage: no automated handling of low-priority noise.
“I don’t want our team constantly having to swivel seat and log into customer EDR, XDR, and SIEM platforms. The idea behind purchasing D3 is that we don’t have to do that.”
MDR practice lead, Provider A
How it is wired
Nothing in a client’s environment is replaced. Each client’s tools stay the system of record for their own data. Morpheus connects bi-directionally: it ingests detections and incidents, Attack Path Discovery runs investigation queries across that client’s connected tools, and enrichment, containment and closure are issued from the case and written back. Analysts investigate and act inside Morpheus, with one login rather than one per client per tool.
Investigation runs on ingestion. By the time an alert is assigned, the AI summary, attack timeline and entity graph are populated. The analyst opens a case that already states what happened, what Morpheus found beyond the source alert, and what to check next. Low-priority alerts are dispositioned under the autonomy mode set for that client, with the evidence logged.
“Our idea of improving analyst efficiency is presenting them with as much pre-investigated information as we can and reducing the amount of in-platform pivoting they have to do. The less of that we can do, the better.”
MDR practice lead, Provider A
Playbooks as code
This is the capability that decides how fast the practice can add clients without adding engineers. Playbooks are created, exported, edited and deployed through the D3 API as human-readable YAML or JSON, kept in the practice’s repository with history and review, and promoted through the same pipeline as any other code. The practice’s own models can call the same endpoints to generate and maintain playbooks. Morpheus also maintains playbooks against integration and schema changes rather than letting them break silently.
“When y’all showed us the way Morpheus auto-maintains a playbook, I thought that was really cool. It’s one of the wild things where it’s like, how do you do that without Morpheus?”
MDR team, Provider A
The work ahead for Provider A, in its own words: connect the first client stacks and validate bi-directional sync on live alerts, stand up the playbook repository and promotion pipeline, set autonomy per client starting conservative, and define the client reporting format generated from each case.
Provider B1,000-plus tenants on one platform
Provider B was already a global MDR leader, running Palo Alto Networks Cortex XSOAR as the orchestration layer behind its services. XSOAR was not built for its scale, and the growth plan made that a business risk.
What was wrong
At 1,000-plus customer tenants XSOAR failed in four specific ways. Performance: a query in the main dashboard regularly triggered hours-long delays or crashed the system, and a single similarity check across the incident corpus took about 30 minutes. Silent ingestion failures: ingesting too many alerts at once crashed the tool with no visibility into which alerts had been dropped. No meaningful multi-tenancy: hundreds of customers fed a single instance, so one tenant’s disk-space problem flooded the master with alerts. Minimal vendor support: upgrades once a year, and extensive custom Python to bend the tool toward requirements, carried as maintenance debt indefinitely.
“If an incident doesn’t arrive in the SOAR, but we know it’s in our product’s UI, then it is very difficult to find out what happened. It’s like finding a needle in a haystack.”
Security systems engineer, Provider B
How it was evaluated
A structured proof of concept against more than 30 technical criteria: ease of use, custom playbook authoring, integration troubleshooting, playbook debugging, MITRE ATT&CK categorization, incident grouping and SOC metric tracking among them. The requirement was true multi-tenancy, dynamic ingestion resilience, rapid onboarding, regional data residency, and a vendor willing to engineer alongside the team. D3 met all of the POC requirements and was deployed across both the service delivery platform and the internal SOC.
Two things decided it beyond the scorecard. The first was scale: the provider needed a platform that could onboard thousands of new customers and absorb the event and incident volume of the whole client base, and D3’s multi-tenant architecture was the only one in the evaluation built for that. The second was fit with how the provider investigates. Its own detection platform groups related detections into a single correlated operation rather than a stream of isolated alerts, and D3’s event pipeline enriches and triages every alert inside that model, so responders work validated incidents with the full picture of an attack. The provider’s targets going in were a reduction in false positives of more than 90 percent, automated response to validated threats, and a better analyst-to-customer ratio, which for an MDR is the margin.
How it is wired
Full replacement of XSOAR after scale-driven failure. Each customer has its own segregated data and workflows. A master instance handles management, configuration, testing and synchronization across the estate. Containerized proxy agents, orchestrated with Kubernetes, scale ingestion resources up and down on demand per integration. If any ingestion fails, the platform resumes it automatically from the point of failure. Aggregated dashboards give cross-customer visibility without breaking tenant isolation.
“A single query would take 30 minutes. We were able to bring it down to a few seconds. Even the most complex queries take two or three minutes at most.”
Senior security systems engineer, D3 Security, on the Provider B deployment
Onboarding in ten clicks
Customer onboarding was a manual, per-customer setup in the old SOAR. At ten minutes or more each, it could not be sustained across thousands of customers. It now takes roughly ten mouse clicks and a few minutes. A ticketing integration ingests the onboarding request, which states the customer and the service start date; an event playbook reads it and creates the new customer’s site pre-configured with the playbooks, integrations and data ingestion schedule for that customer’s region. The only manual step is scheduling data ingestion from the customer’s tools. Offboarding follows the same pattern, with a playbook that deactivates the site and cancels ingestion. With 2,000-plus new customers a year planned, onboarding at that speed was not optional.
Regional isolation
Where local sovereignty or residency obligations apply, the provider runs an isolated regional deployment of the same architecture. Only the deployment region changes. Customer notifications are translated into local languages, so the service reads as native in each market. The embedded MITRE ATT&CK matrix tags events with TTPs, which the provider delivers as a kill-chain and gap-analysis service line.
Service lines on the platform
Most of the provider’s customers receive endpoint-focused MDR. For those, D3 orchestrates ingestion, enrichment, analysis and notification. Enrichment runs largely through integrations with the provider’s own microservices and internal tools, and the playbook writes the incident back into the provider’s own platform, so the customer-facing portal stays the system of record, then generates the customer notification in the local language. On top of that base, the provider launched a managed XDR service in which D3 ingests a wider range of telemetry, enriches it and presents it to the customer through the provider’s dashboard. D3 data is also the basis for the monthly reports every customer receives, reporting that was not reliable on the old SOAR because the queries behind it crashed it.
The metrics the provider tracks against the platform: mean time to triage, mean time to escalation, mean time to remediation, platform uptime, time to onboard a customer, search query time, and vendor response time, which now carries a one-hour support SLA. That last one is the direct answer to once-a-year upgrades.
What the two have in common
Autonomy set per client, on both platforms
- Every query is recorded, including those that returned nothing, so a client reviewer can see what was checked.
- Every finding is rated confirmed, inferred or gap. Nothing is presented to a client as certain that is not.
- Investigation is read-only. State-changing actions in a client environment go through playbooks under the mode set above.
- Nothing in the client’s stack is replaced. Detection tools stay the system of record; Morpheus is the investigation and response layer.
Scale is multi-dimensional for an MDR. Alert volume, tenant count, tool heterogeneity, regional geography and onboarding rate all grow at once. Provider A’s constraint was investigation effort per alert and engineering effort per client. Provider B’s was tenant count and residency. The same architecture answers both because it separates three things: a per-client workspace with its own data and autonomy setting, an investigation engine that works across whatever tools that client has, and playbooks that are code rather than clicks.
Results
- Provider B: 1,000+ tenants, one platform Full data segregation per customer, dynamic ingestion scaling, and automatic resume on any failed ingestion. Zero data-ingestion loss.
- Provider B: 30 minutes to seconds A similarity check that took about 30 minutes on XSOAR returns in seconds; the most complex queries complete in two to three minutes.
- Provider B: onboarding in ~10 clicks From a manual per-customer setup, with 2,000+ new tenants a year on the growth plan, and a managed XDR service launched on the same platform.
- Provider A: selected on investigation and pipeline Chosen so analysts open pre-investigated cases from one workspace and playbooks move through version control. Onboarding of the first client stacks is under way; results will follow.
“If you don’t go with D3, we’re wasting money, because look at what D3 does automatically compared to other platforms.”
MDR practice lead, Provider A
Why this matters for any MDR or MSSP
An MDR cannot scale on headcount. The economics only work if growth in clients, tenants and alert volume is decoupled from growth in analysts and engineers. Provider B proved the architecture holds at 1,000-plus tenants and thousands of onboardings a year. Provider A is applying the same architecture to the other end of the problem: the cost of each investigation and each new client’s playbooks.
Up to 95 percent of alerts triaged and investigated in under two minutes, per customer-reported production data, is what the investigation layer adds on top of the multi-tenant foundation. The provider keeps the client relationship and the judgement. The platform does the work that used to be assembled by hand, once per client.
Frequently asked questions
Can one SOC platform investigate across different clients’ detection stacks?
Yes. Provider A connects each client’s own tools, including CrowdStrike, Microsoft Sentinel and other XDR platforms, to Morpheus. Attack Path Discovery investigates across whichever tools that client has, and enrichment, containment and closure are written back to the client’s tool, which stays the system of record. Analysts work every client from one workspace.
How many customer tenants can an agentic SOC platform support?
Provider B orchestrates more than 1,000 customer tenants from a single D3 platform, with each tenant’s data and workflows segregated and a master instance handling configuration, testing and synchronization. Its growth plan adds 2,000 or more new tenants a year.
How long does it take to onboard a new MDR customer?
For Provider B, roughly ten mouse clicks. A ticketing integration ingests the onboarding request and the platform creates the customer’s site pre-configured with the playbooks and integrations for that region. The only manual step is scheduling data ingestion. Previously a manual per-customer setup that could not be sustained across thousands of customers.
Can MDR playbooks be managed as code?
Yes. Playbooks can be created, exported, edited and deployed through the D3 API as readable YAML or JSON, kept under version control with history and review, and promoted through a CI/CD pipeline. Provider A’s previous tooling exported playbooks encrypted and unreadable, which blocked any pipeline.
How does an MDR provider meet regional data residency requirements on one platform?
By deploying isolated regional instances of the same architecture where sovereignty or residency obligations require them, with customer notifications translated into local languages. Options include cloud, on-premises, hybrid, sovereign-region and fully air-gapped.
What does an agentic SOC add for an MDR beyond SOAR?
Investigation done before an analyst opens the case: Attack Path Discovery reads the alert, runs its own queries across the client’s connected tools, and presents a timeline, entity graph and root-cause narrative. Low-priority noise is dispositioned under the autonomy mode set per client. SOAR playbooks still govern response actions and run deterministically.
Related case studies
Related reading on D3Security.com
About D3 Security
D3 Security builds D3 Morpheus, the agentic SOC platform that investigates and responds to security alerts autonomously. Morpheus connects to the SIEM, EDR, XDR, identity and cloud tools an organization already runs, investigates every alert with Attack Path Discovery, and executes response through deterministic playbooks under a human-set autonomy mode. It is used by enterprise SOC teams, MSSPs and MDR providers that need to scale investigation without scaling headcount, and deploys in cloud, on-premises, hybrid, sovereign-region and air-gapped environments.
Customer details in this case study are anonymized at the customer’s request. Figures are the customer’s own, from its evaluation and production records. Request a demo or read the D3 glossary of agentic SOC terms.
Canonical URL: https://d3security.com/resources/global-mdr-agentic-soc-multi-tenant/
Scaling an MDR or MSSP on fixed headcount?
See Morpheus investigate across a client’s stack, onboard a tenant, and run per-client autonomy, on your own alerts. A working session with a D3 engineer, not a slide deck.