MDR Platform Development: How Do You Run 40 Customer Estates From One Analyst Team?

The moment the service stops scaling

You started with six customers and one analyst who knew all of them. Now you have thirty four. Customer 12 runs CrowdStrike and Google Workspace. Customer 19 runs Defender, on premise Active Directory and a Fortinet estate. Customer 27 is a hospital group with a clinical network nobody is allowed to touch after 6pm. An analyst on a Tuesday night sees an alert, and before she can decide anything she has to remember which tenant this is, what that tenant's normal looks like, whether their contract includes host isolation or only notification, who is on their escalation list this month, and whether it is 2am for them too.

The failure is not that she gets it wrong. It is that answering those five questions takes four minutes per alert, thirty four times over, and it is unbillable. Meanwhile the same detection that is genuinely valuable at customer 12 fires forty times a night at customer 19 because their backup service does something unusual at 1am, and nobody has a clean way to suppress it for one tenant without weakening it everywhere. Then the quarterly business review comes around and the customer asks you to prove you met the one hour response commitment, and someone spends a day in ticket exports building a chart.

That is the shape of the problem. The platform is not a cost centre supporting the service. In a managed detection business the platform is the product, because it determines how many customers one analyst can carry and whether your SLA claims are evidence or assertion.

What the incumbents actually offer a service provider

There are two different things being sold under similar names, and conflating them is expensive. Arctic Wolf, Sophos MDR and Huntress sell MDR as a service to end customers. If you resell them you are a channel partner, your margin is a discount, and you do not own the relationship at the technical level. That is a legitimate business but it is not your platform.

Stellar Cyber, Blumira and Secureworks Taegis sell platforms that partners can deliver a service on. They are real products and they solve the ingestion and detection problem competently. Where they constrain a service provider is that the shape of the service becomes theirs. Your tiering, your detection content, your reporting and your customer facing portal are configured within their model rather than designed as yours. When your commercial differentiation is that you do something specific for mid market manufacturers that generic MDR does not, and that difference has to show up in tuning, reporting and escalation, you are trying to express your product through someone else's schema.

There is also a structural issue that catches providers late. Your customer relationships, your detection history and your service evidence accumulate inside a platform whose pricing scales with the volume you ingest. Growth makes your cost base grow with it, and a repricing or an acquisition of that vendor becomes an event that hits every customer contract you hold. Providers who build the orchestration and service layer themselves, while continuing to buy detection where it makes sense, keep that risk contained.

Tenant isolation is an architecture decision, not a feature

Get this wrong and you cannot fix it later without a rewrite, so decide it deliberately in week one. Every query, every API call, every background job and every report must carry a tenant context that is enforced at the data layer rather than checked in application code. Row level security in the database, tenant scoped credentials for downstream tool access, and a test suite whose job is specifically to try to leak data across tenants.

The reason to be strict is that a single cross tenant disclosure is not a bug in this business, it is an existential event. You will be asked about it in every subsequent sales cycle, and prospects will ask your architecture questions with their own security team in the room. Providers who chose shared tables with a tenant column and application level filtering usually discover the gap during a customer penetration test, which is the expensive way to find out.

Separate the analyst view from the customer view completely. Your analysts need a cross tenant queue prioritised globally, because that is how you actually staff a shift. Your customers need a view of exactly their estate and nothing else, including in exported reports and in emailed alerts where a copy and paste error becomes a disclosure.

Per customer detection tuning without forking your content

The hardest engineering problem in a multi tenant MDR platform is that detections must be shared to be maintainable and tuned to be usable. Fork the content per tenant and within a year you have thirty four divergent copies and no way to push an improvement. Keep it uniform and every noisy environment poisons your queue.

The pattern that works is a detection library held once, with a tenant overlay carrying suppressions, thresholds, asset exclusions and severity adjustments. The overlay is data, not code, and it is versioned so you can answer why a detection was suppressed at customer 19 in March and who approved it. Sigma style portable rule definitions help here because they let you author once and translate to whatever query language each tenant's backend speaks, which matters when your customers are split across Defender, CrowdStrike and an Elastic cluster.

Build a tuning workflow into the analyst interface rather than a separate admin task. When an analyst closes the eleventh false positive of a detection at one tenant, the suppression proposal should be one click from that case, routed to whoever approves tuning, and applied with a note attached. Tuning that requires opening a different tool at the end of a shift does not happen, and the noise stays.

SLA evidence has to be a byproduct, not a project

Your contracts commit to something like acknowledgement within fifteen minutes for critical alerts and a defined response action within an hour, usually with business hours definitions that differ per customer. If those timestamps are derived from a ticketing system afterwards, three things go wrong: the clock start is ambiguous, timezone and business calendar handling is inconsistent, and you cannot see a breach until after it happened.

Model the SLA explicitly. Each alert class at each tenant carries a target derived from that customer's contract, the clock starts at a defined event you can defend, pauses are recorded with a reason, and the analyst interface shows time remaining rather than time elapsed. Then the quarterly report is a query, and more usefully, the shift lead can see at 3am which cases are about to breach. Providers who add this consistently report that the operational value of seeing the clock live exceeds the reporting value, which is the opposite of what they expected when they asked for it.

What a full platform includes

• Multi tenant ingestion normalising telemetry from each customer's own endpoint, identity, network and cloud tooling into a shared schema.
• A shared detection library with per tenant overlays for suppression, thresholds and severity.
• Cross tenant analyst queue with global prioritisation, plus per tenant context that loads with the case rather than being remembered.
• Case management carrying disposition, reasoning and indicators so repeat alert classes are not re-investigated.
• Contracted response actions per tenant, with the platform enforcing what your contract with that customer permits.
• SLA modelling with live countdowns, defensible clock start, recorded pauses and automatic reporting.
• Branded customer portal and scheduled reporting, including onboarding status for new customers.
• Onboarding automation, because the time from signed contract to first detection is a commercial number you should be shortening deliberately.

What it costs and how long it takes

From the projects Digital Heroes has delivered, a first release covering multi tenant ingestion for two or three telemetry types, tenant isolation done properly, the analyst queue and case management, and the tenant overlay tuning model runs $110,000 to $220,000 and ships in 16 to 22 weeks. The full platform adding contracted response actions, SLA modelling, the branded customer portal, scheduled reporting and onboarding automation runs $300,000 to $700,000 phased over 9 to 18 months.

Cost drivers specific to this business: the diversity of your customers' tooling, since each endpoint or identity vendor is a separate integration with its own API behaviour under rate limits. Response actions, because each one touches a customer's production estate and needs permission modelling. Data residency, if you serve customers in jurisdictions that will not allow telemetry to leave. And retention, since holding a year of telemetry for forty customers is an infrastructure cost decision that shapes the architecture rather than a line item you add later.

What keeps it down: standardise the tooling you support. Providers who say plainly that they support three endpoint vendors and will onboard anything else as a custom engagement grow faster and build cheaper than those who accept whatever a prospect already owns.

When you should not build

Under about fifteen customers, or when your customers all run a similar stack, a partner platform is the right call and building is premature. If your differentiation is relationship and response quality rather than anything technical, the platform is not your product and you should not fund it as though it is.

Build when the manual work between tools starts capping your growth: when adding a customer means a week of analyst onboarding, when tuning debt is degrading your queue, when a prospect's security team asks architecture questions you cannot answer favourably, or when the platform vendor's pricing is taking a growing share of the margin on every contract you win.

How to choose a developer for an MDR platform

Ask how they enforce tenant isolation, and accept only an answer that puts enforcement at the data layer with tests that actively try to cross the boundary. Application level filtering with a tenant column is the answer that fails a customer penetration test.

Ask how they will keep detection content shared while allowing per tenant tuning. If the proposal is copying rules per customer, you will have an unmaintainable estate within a year and they should know that.

Ask what they have integrated specifically. CrowdStrike, Defender, SentinelOne, Okta and Google Workspace all behave differently under sustained load and their rate limits shape your ingestion design. Ask for the vendor name and the telemetry type, not a general claim about integrations.

Ask how onboarding a new customer works on day one after launch, and expect a real workflow rather than a runbook. Time from signature to first detection is a number your sales team will quote.

Get ownership of the code, the repository and the infrastructure accounts written into the contract before kickoff. At Digital Heroes the client owns the code from the first commit. When the platform is the product, owning it is not a preference, it is the business.