{"id":1731,"date":"2026-08-25T07:35:00","date_gmt":"2026-08-25T13:35:00","guid":{"rendered":"https:\/\/raffy.ch\/blog\/?p=1731"},"modified":"2026-08-17T13:11:08","modified_gmt":"2026-08-17T19:11:08","slug":"mdr-may-be-splitting-into-three-managed-services","status":"publish","type":"post","link":"https:\/\/raffy.ch\/blog\/2026\/08\/25\/mdr-may-be-splitting-into-three-managed-services\/","title":{"rendered":"MDR May Be Splitting Into Three Managed Services"},"content":{"rendered":"\n
\"\"<\/a><\/figure>\n\n\n\n

I have argued for a while that MDR has to move beyond alert triage<\/a> and become a cyber risk reduction service. A recent conversation with an experienced MDR operator added another piece to that thesis. The future may not be one ever-expanding MDR bundle. We may be forcing three different jobs into one category:<\/p>\n\n\n\n

    \n
  1. managing the security data and detection foundation<\/li>\n\n\n\n
  2. operating the detection and response workflow; and<\/li>\n\n\n\n
  3. proactively reducing risk.<\/li>\n<\/ol>\n\n\n\n

    The second is the MDR service we know today. The third is where I believe MDR ultimately has to go. But the first may be a new service category of its own: the managed security data fabric<\/strong>.<\/p>\n\n\n\n

    TL;DR<\/h2>\n\n\n\n
    Service<\/th>Primary Job<\/th>Core Outcome<\/th><\/tr><\/thead>
    Managed security data fabric<\/td>Operate the telemetry, context, threat intelligence, and detection foundation<\/td>Trusted, current, actionable security data<\/td><\/tr>
    MDR<\/td>Monitor, investigate, hunt, triage, and respond<\/td>Threats are found and contained<\/td><\/tr>
    Managed risk reduction<\/td>Find and remove exposures before they become incidents<\/td>Measurable risk reduction<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    These layers can be sold together, but they do not have to be. An enterprise may want to keep its own SOC while outsourcing the data and detection foundation underneath it. Another company may want a full MDR service. A third may need help driving remediation and proving that its exposure actually went down.<\/p>\n\n\n\n

    That creates a more flexible model than trying to sell every customer the same MDR bundle.<\/p>\n\n\n\n

    The Missing Service Under The SOC<\/h2>\n\n\n\n

    Most security teams have a SIEM, data lake, EDR platform, or some combination of the three. Many also have an MDR provider. Yet it is often unclear who owns the quality of the security data layer end to end.<\/p>\n\n\n\n

    The SIEM vendor provides the product and does not manage the customer’s entire data environment. The MDR provider consumes the data it needs to deliver its service. Internal platform teams keep pipelines running. Detection engineers maintain content. Threat intelligence is purchased from several sources. Asset, identity, cloud, and business context live in still more systems. In smaller environments, an MSSP might own the entire chain, but at what quality and what depth? Do they really understand what assets are used for what purpose, understand infrastructure changes, escalation points, etc?<\/p>\n\n\n\n

    Everybody owns a piece. Nobody necessarily owns whether the complete foundation is accurate, current, cost-effective, and usable.<\/p>\n\n\n\n

    A managed security data fabric<\/strong> would take responsibility for that foundation. It could:<\/p>\n\n\n\n

      \n
    • onboard, route, store, and monitor security telemetry (logs)<\/li>\n\n\n\n
    • normalize schemas and reconcile duplicate or conflicting entities (by the way, ask your SIEM vendor about this)<\/li>\n\n\n\n
    • maintain asset, identity, cloud, control, and business context<\/li>\n\n\n\n
    • curate and operationalize threat intelligence<\/li>\n\n\n\n
    • build, test, tune, and update detection content<\/li>\n\n\n\n
    • identify missing telemetry and broken detection coverage<\/li>\n\n\n\n
    • optimize storage, query, and AI consumption costs<\/li>\n\n\n\n
    • expose trusted context to SIEMs, data lakes, internal applications, and AI agents<\/li>\n<\/ul>\n\n\n\n

      This is not just co-managed SIEM under another name. A co-managed SIEM service usually starts with the SIEM as the center of gravity. A managed security data fabric starts with the information and context the security operating model needs, then serves that foundation into whichever SIEM, analytics platform, workflow, or agent the customer chooses.<\/p>\n\n\n\n

      It also does not have to operate the SOC. It may generate detections, but it does not necessarily triage every alert. It can maintain detection quality without owning 24\/7 monitoring, threat hunting, incident investigation, or response.<\/p>\n\n\n\n

      That boundary is what makes it a distinct service.<\/p>\n\n\n\n

      Why AI Makes The Data Layer More Important<\/h2>\n\n\n\n

      AI SOC products initially focused on the visible labor problem: too many alerts and too much analyst time spent investigating them. That produced a clear economic pitch. If an agent can resolve a large percentage of alerts, an MDR provider or internal SOC can reduce cost.<\/p>\n\n\n\n

      But AI does not remove the underlying data problem. In some cases, it makes it more obvious. And that’s another reason supporting the introduction of a managed security data frabric.<\/p>\n\n\n\n

      An agent that has to query five systems, interpret five schemas, reconcile conflicting records, and determine which source is authoritative may be technically impressive, but it is also expensive and difficult to govern. Replacing telemetry parsers with agents does not eliminate complexity. It moves complexity into a less deterministic layer.<\/p>\n\n\n\n

      A well-managed security data fabric changes the economics. The expensive work of collection, normalization, deduplication, entity resolution, and context assembly happens before the agent starts reasoning. The agent receives a smaller, cleaner, better-structured set of information through a stable interface.<\/p>\n\n\n\n

      That should reduce tool calls and token consumption. More importantly, it should improve the quality and consistency of the result, ie the attacks prevented.<\/p>\n\n\n\n

      Context Has To Be Managed<\/h2>\n\n\n\n

      The word “managed” matters here. Building a context graph once is not enough. Data sources change. Schemas drift. Assets appear and disappear. Identities move. Business owners change. Two systems disagree about the same endpoint. Detection logic decays as products and attacker behavior evolve.<\/p>\n\n\n\n

      Getting data into one place is not the hard part. Making it trustworthy over time is.<\/p>\n\n\n\n

      That requires ongoing operational work: resolving conflicts, validating relationships, monitoring source health, testing detections, updating intelligence, measuring coverage, and deciding which source should be authoritative for which field. Some of this can be automated. Some still requires human judgment and customer input.<\/p>\n\n\n\n

      This is exactly the kind of recurring, technical, difficult-to-staff function that tends to become a managed service. Are there opportunities for automation and AI? Of course, but we are far from having this all automated completely.<\/p>\n\n\n\n

      The Three-Service Model<\/h2>\n\n\n\n

      Separating the layers makes the future security service stack easier to understand.<\/p>\n\n\n\n

      1. Managed Security Data Fabric<\/h3>\n\n\n\n

      This service operates the substrate. Its job is to make security data complete enough, clean enough, contextual enough, and current enough for humans and machines to use.<\/p>\n\n\n\n

      The output is not an investigated alert. It is a trusted security operating layer that makes sure attacks don’t go undetected because of missing detections, threat intel, data sources, or configurations.<\/p>\n\n\n\n

      2. Managed Detection And Response<\/h3>\n\n\n\n

      MDR consumes that substrate to operate continuous threat monitoring. It owns alert triage, investigation, threat hunting, escalation, containment, and response.<\/p>\n\n\n\n

      The output is not clean data. It is a threat that was detected, understood, and handled.<\/p>\n\n\n\n

      3. Managed Risk Reduction<\/h3>\n\n\n\n

      The risk reduction service works further upstream. It connects asset criticality, identity, exposure, control gaps, threat activity, and remediation workflows to reduce the likelihood and\/or impact of an incident.<\/p>\n\n\n\n

      It should identify what matters, route the required action, navigate ownership and change approvals, verify that remediation happened, and show what risk remains.
      <\/p>\n","protected":false},"excerpt":{"rendered":"

      I have argued for a while that MDR has to move beyond alert triage and become a cyber risk reduction service. A recent conversation with an experienced MDR operator added another piece to that thesis. The future may not be one ever-expanding MDR bundle. We may be forcing three different jobs into one category: The […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[30],"tags":[85,84,86],"class_list":["post-1731","post","type-post","status-publish","format-standard","hentry","category-security-market","tag-data-layer","tag-mdr","tag-mssp"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t