MDR Platform Problems: The 7 That Break a Growing Provider, and How to Avoid Them

Why does an MDR build turn into a second SIEM instead of a service platform?

The scope failure that eats these projects is deciding, somewhere around week six, that you also need to build the detection engine. It happens for an understandable reason. Once you are ingesting telemetry from customer endpoints to normalise it, writing a correlation rule feels like the next obvious step, and the team is already in the data. Six months later you own a mediocre search index, a query language nobody outside the team knows, and you have not yet shipped the thing that actually caps your growth.

What caps your growth is not detection quality. It is the four minutes an analyst spends per alert reconstructing which tenant this is, what their normal looks like, what your contract with them permits, and who is on their escalation list this month. Multiply that across thirty four customers on a night shift and you have the whole problem.

The fix is a decision written into the statement of work before kickoff: you are building the orchestration, context and service layer, and you are buying detection. Keep buying it. Let CrowdStrike, Defender or an Elastic cluster do what they already do at a customer's own estate, and spend your engineering on the layer none of them will ever build for you, which is the multi tenant analyst experience and the evidence trail behind your contracts. If a proposal you receive includes writing your own correlation engine, ask what business outcome that specifically delivers that a bought engine does not, and expect a weak answer.

What goes wrong when you migrate tenants and detection history off a partner platform?

Two things, and providers underestimate both. The first is that your case history is not portable in the way you assume. Alerts export reasonably. Dispositions, analyst reasoning, the note explaining why a particular alert class at customer 19 is benign, and the tuning decisions that produced today's queue tend to live in fields that either do not export or export as unstructured text. That reasoning is the asset. Without it your new platform starts with an analyst team that has lost several years of institutional memory about what normal looks like at each customer.

The second is that migration is per tenant, not per platform, and each tenant is a scheduling negotiation with a customer who did not ask for this. Every one needs connector credentials reissued, a baseline period where you are running both platforms and comparing, and a named person at their end. Forty customers at even a light touch is a programme, not a cutover weekend.

Do it in waves and pick the first wave deliberately: two or three customers with simple estates, cooperative contacts and no clinical or regulated constraint. Run parallel for at least a full month per wave and reconcile on alert counts by class rather than totals, because totals hide the case where one noisy detection is masking the absence of three others. Extract tuning decisions and dispositions as structured data first, before you touch anything else, because that is the part your vendor has the least incentive to make easy and the part your analysts cannot rebuild.

Why do the CrowdStrike, Defender and Okta integrations break after launch?

They break under sustained load, at a specific time, for the same three reasons every time. Rate limits are the first, and the failure is rarely a hard error. It is a throttle that silently degrades your polling frequency until a detection that should have fired within minutes fires within an hour, and nothing in your monitoring notices because data is still arriving. The second is credential lifecycle: a customer rotates an application secret during their own hygiene work and tells nobody, so ingestion for one tenant stops while thirty nine keep flowing and your dashboard averages look healthy. The third is schema drift, because these vendors evolve their event formats and your normalisation layer was written against last year's shape.

All three share one root cause, which is monitoring the aggregate rather than the tenant. Alert on per tenant per source freshness, with an expected volume band learned from that tenant's own history, so a customer whose identity telemetry has been quiet for six hours raises a ticket even though your platform ingested millions of events tonight.

Then build for backpressure honestly. Ingestion needs a queue with replay, so a downstream outage becomes a delay rather than a permanent gap in a customer's evidence. And keep raw events alongside the normalised form for a defined window, because when a vendor changes a field you will need to reprocess, and a platform that only stores the normalised version cannot.

What happens when contracted response authority is not modelled?

An analyst at 3am sees a genuine compromise at a customer and isolates the host. Correct instinct. That customer bought notification only, and the isolated host is a clinical system in a hospital group whose network you are contractually not allowed to touch after 6pm. The platform let it happen because response actions were built as a capability rather than as a permission.

This is the failure mode that damages a provider fastest, because it converts a technically good outcome into a contractual breach and a very hard conversation. It is also entirely preventable, and it is skipped constantly because response actions get scoped as buttons in a user interface rather than as an authority model.

Model it as data per tenant. What actions are permitted at all, in what hours, against what asset classes, with what approval, and what is the fallback when the action is not permitted. The platform should make the impermissible action impossible to reach rather than showing it and relying on the analyst to remember, because at 3am under pressure they will not. Where an action needs a customer's approval, that request and the response belong in the case record, timestamped, so the evidence exists later.

Add a blast radius check on top. An action that would isolate more than a set number of hosts, or any host in a tagged critical group, requires a second named approver. Providers who add this consistently find it catches operator error far more often than it catches anything malicious, which is exactly the point.

Should you build custom or configure what you already own?

Under roughly fifteen customers, do not build. Stellar Cyber, Blumira and Secureworks Taegis are real products that solve ingestion and detection competently, and white labelling or reselling an established service preserves your margin without funding an engineering programme. If your differentiation is response quality and the relationship rather than anything technical, the platform is not your product and you should not fund it as though it is.

Before concluding your current platform cannot do what you need, check what you have actually configured. Most partner platforms support per tenant suppression, custom severity mapping and scheduled reporting, and providers routinely run without any of it because nobody owned the configuration. Fixing tuning debt inside the platform you already pay for is weeks of analyst time, not a capital project, and it will tell you honestly whether the constraint is the product or the process.

Build when the constraint is structural rather than configurational. When the shape of your service has to be expressed through someone else's schema and your commercial differentiation gets flattened. When onboarding a customer costs a week of analyst time and that is now your growth ceiling. When ingestion based pricing is taking a rising share of margin on every contract you win. Even then, the sane split is to build the service, context and evidence layer and keep buying detection underneath it.

How do hidden costs get into the quote?

Retention is the big one and it is almost never in the build number. Holding a year of telemetry for forty customers is an ongoing infrastructure cost that shapes your architecture, and it grows with every customer you win. Ask for the monthly storage and query cost at your current customer count and at double it, and ask what the tiering plan is when data ages past ninety days.

Four more that get left out routinely. Each additional endpoint or identity vendor is a separate integration with its own behaviour under load, so a quote that prices three sources is not a quote for a prospect who runs a fourth. Onboarding automation, which providers assume is included and which is genuinely a workflow product of its own. Parallel running through migration, where you pay for both platforms and your analysts do more work, not less. And the validation work if any customer requires evidence about your platform's own controls, which mid market prospects increasingly do.

Then the one specific to this business: response actions are the most expensive component per feature, because each one touches somebody else's production estate and needs permission modelling, approval flow, blast radius checks and a rollback story. Pricing them as user interface buttons is how a quote comes in low and a project comes in late.

What separates an MDR platform build that works from one that fails?

Isolation decided in week one, enforced at the data layer with row level security and tenant scoped credentials for downstream tool access, and a test suite whose explicit job is to attempt cross tenant reads and fail the build when one succeeds. Everything else in this list is recoverable. This one is not, and retrofitting it is why some of these projects get abandoned rather than fixed.

Shared detection content with per tenant overlays as versioned data, decided before the first rule is written. Forking rules per customer feels reasonable at ten tenants and is unmaintainable at forty, and the transition back is manual reconciliation of thirty four divergent copies with nobody able to say which differences were deliberate.

The SLA modelled rather than derived. Each alert class at each tenant carries a target from that contract, the clock starts at an event you can defend, pauses carry reasons, and the analyst view shows time remaining. Providers who add this consistently report the live countdown matters more operationally than the report does commercially, because the shift lead can see a breach coming rather than reading about it in a quarterly review.

Standardised tool support, stated plainly in your own sales process. Providers who say they support three endpoint vendors and onboard anything else as a custom engagement build cheaper platforms and grow faster than those who accept whatever a prospect already owns.

And ownership settled in writing before kickoff: the repository, the infrastructure accounts, the customer data and the right to hire anyone else to continue the work. When the platform is the product, owning it is not a commercial preference. It is the business.