MDR is not going away, but the old model is. The old model was service-first: collect alerts, have analysts investigate them, escalate what matters, and report what happened. That still solves a real problem, but it is not where the market is going.

The future MDR has to become product-first, AI-native, and action-oriented. It cannot just sit on top of EDR alerts and add analyst labor. It has to become the SecOps control plane that connects detection, investigation, response, exposure reduction, and proof of outcome.

This is not just an “AI layer” on top of alerts. It requires a different architecture, a different relationship with the SIEM, and a different operating model for response.

The Service Business Has To Become A Product Company

Traditional MDR was built as a service business. The product was often the people: analysts, playbooks, escalations, customer calls, and reporting. That model can scale to a point, but it starts to break when the market expects software-speed investigation and response.

Next-gen MDR has to invert the model. The platform becomes the core product, and services become the trust, expertise, and exception-handling layer around it. The test is margin and labor leverage. If more customers create more exceptions, more tuning, and more analyst burden, the company is still a service business. If more customers create more reusable detections, known-good patterns, automation recipes, and response policies, the service is becoming a product. Analysts still matter, but they should supervise, improve, validate, and handle edge cases. They should not be the primary execution engine for every repetitive investigation.

That is a hard transition because many MDR providers are not software companies. They can script, tune, and operationalize, but building a real SecOps platform is a different muscle.

The Moat Is Not AI. It Is Encoded Operational Judgment.

The defensible part of next-gen MDR is not that it uses AI. Everyone will use AI. The defensible part is whether the provider has converted years of SOC judgment into productized decision systems: known-good behavior, investigation procedures, response playbooks, customer-specific rules of engagement, approval policies, and feedback loops that improve the platform over time.

The best MDR providers will not simply have analysts assisted by AI. They will have a compounding operating system where every resolved case can improve future triage, investigation, automation, and response across customers. The weak version is service history trapped in analyst memory and exception lists. The strong version is structured, versioned, measurable operational knowledge embedded into the platform.

And let’s not forget the context graph. The data structure that learns the customer environments. The intelligence layer that fuses together individual data points to deliver a high signal, low friction security outcome.

MDR And SIEM Become Symbiotic

It’s a mistake think (or build a company around) next-gen MDR replaces the SIEM.

The SIEM is there for a reason. It stores logs, supports compliance retention, enables historical search, runs detections, and gives the customer a system of record for security data. Many customers already have years of detection logic, parsers, dashboards, and workflows inside it.

But the SIEM should not be the only operating layer for MDR. If MDR depends entirely on the (customer’s) SIEM, it inherits the SIEM’s latency, schema problems, data opacity, cost model, and workflow limitations.

The future relationship is symbiotic. MDR should use the SIEM’s detection layer where it works, but also audit it, monitor it, and improve it. Are the right logs arriving? Are detections still firing correctly? Are parsers broken? Are detections duplicated, stale, or missing context? Which investigation outcomes should feed back into detection logic?

In that model, the SIEM becomes less of the SOC’s user interface and more of a data and detection layer inside a broader SecOps operating system. It’s also feasible to have the SIEM be the data backend for the AI SOC, but only if it’s under the uninhibited control of the MDR.

AI Changes The Architecture, Not Just The Interface

The visible change in the near future is that analysts and customers will interact with the system(s) through AI. They will ask questions, start investigations, summarize cases, generate response plans, even design their own dashboards, and check what changed.

But the harder shift is underneath. The backend has to be built so AI can interact with it safely and efficiently. That means the platform needs clean APIs, stable entity models, permission-aware access, auditable actions, reusable investigation workflows, and compact context that does not require dumping endless raw logs into a model. And last but not least, the backend has to be designed for AI workloads and in turn, for token efficiency and for the types of (probably very suboptimal) queries that the AIs will send down.

This is why an AI-native SecOps platform is not the same as a chatbot on top of a SIEM. The architecture has to support the way AI investigates, acts, remembers, and learns.

Detection Has To Move Into Automated Response

The current MDR model still assumes a human-centered response loop: a detection fires, an analyst investigates, and someone decides whether to isolate, disable, block, remove, patch, ticket, or escalate. That loop is too slow for many modern attacks.

The future MDR platform has to move toward detection-to-response automation, but not reckless automation. Customers will push back, and rightly so. They do not want an opaque AI system taking production-impacting actions on its own. The answer is to be precise about what “AI” means.

Not every workflow needs an LLM. Much of response should become deterministic rules, policy engines, and pre-approved playbooks. GenAI should be reserved for the places where it helps: summarization, investigation planning, evidence interpretation, query generation, and edge-case reasoning. For most alerts, the system should be predictable, auditable, and constrained.

The second answer is supervision. Some actions can be fully automated. Some should require analyst approval. Some should require customer approval. The platform has to know the difference between removing a malicious email, disabling a privileged identity, isolating a production server, and changing access policy for a sensitive application.

The third answer is guardrails. We are entering the era of validation loops for AI: agents and control layers that check what the system proposes, understand disruption risk, enforce policy boundaries, and monitor whether the action worked. Formal guardrail frameworks, policy-as-code, approval gates, rollback paths, evals, and audit trails become part of the SecOps architecture.

This is where risk becomes the control signal. A suspicious event on a low-value test asset should not trigger the same response as the same event on a privileged identity accessing sensitive data. Risk should influence not only the analyst queue, but also resource access flows: step-up authentication, zero trust enforcement, restricted data access, endpoint isolation, email removal, identity reset, or escalation to a human.

That is the important shift. Detection should not only create an investigation. It should drive protection and exposure reduction.

The Market Implication

Next-gen MDR, AI SOC, and the MSP/MSSP security platform may look like separate markets today. Architecturally, they are converging. The packaging changes by segment, but the platform direction is increasingly the same.

Enterprise buyers will usually want to retain ownership of security operations. They may use managed expertise, but they are more likely to buy an AI-native SecOps platform that compresses L1/L2 investigation, improves consistency, and accelerates response while their internal team keeps control of higher-risk decisions. There is an opportunity for AI SOC players to provide the new sec ops platform for these enterprises as the central command – AI first, SIEM symbiotic.

Mid-market buyers are the most interesting and the most difficult. They often have enough security maturity to know they need help, but not enough staff or process maturity to run a pure platform themselves. This is where productized MDR can become the managed SecOps control plane: part platform, part expert service, part automation layer. The provider has to help operate the loop, not just forward alerts. The lesson is not to bolt on every adjacent service. Exposure management, asset visibility, identity posture, vulnerability prioritization, and response orchestration all matter, but they have to reinforce the MDR operating loop. If the provider adds too much service scope without product leverage, it becomes broad, expensive, and hard to deliver. This is also where we need the vendors to educate the market. Mid-market companies need these capabilities whether they ask for them or not. If they are buying separate tools for exposure management, asset inventory, vulnerability management, identity posture, and reporting, it is reasonable to ask why the MDR provider should not help operate those workflows. The customer can still supervise decisions, set policy, and approve sensitive actions. But the MDR should increasingly coordinate the operating loop. Ideally MDR players will open up their platforms for end customers to co-deliver security results.

SMB buyers may never experience this as an AI SOC platform. They may experience it through an MSP or MSSP security platform that bundles endpoint, email, identity, compliance, patching, response, and reporting all within one simple, per user license. But underneath, the same direction applies: more product, more automation, more risk context, more proof.

The future MDR is not an AI layer on top of alerts. It is not a cheaper SOC. It is not a duplicate SIEM. And it is not a service desk with better automation. The future MDR is a productized SecOps control plane: symbiotic with the SIEM, directly integrated with the customer’s enforcement tools, risk-aware in how it prioritizes and responds, deterministic where safety matters, AI-native where reasoning helps, and measured by proof of risk reduction. The companies that win will be the ones that turn service experience into compounding product advantage. The companies that lose will still have analysts, alerts, dashboards, and AI summaries, but no real moat.

In a previous post about the adjacencies to the MDR market, I laid out a framework for how MDR needs to evolve beyond alert triage. The basic idea was that future MDR should not just be “EDR alerts plus analysts.” It should become the control plane for cybersecurity operations and cyber risk reduction.

This post goes one level deeper. If MDR is going to become that control plane, what capabilities actually need to sit closest to the operating loop? The strongest extensions are the ones that help MDR understand what exists, what is exposed, what telemetry is missing, what response should happen, and whether risk actually went down.

Asset And Control Coverage

This is the starting point. MDR cannot protect an environment it does not understand, so the provider needs to know:

• What exists?
• What is unmanaged?
• What lacks EDR coverage?
• What lacks vulnerability scanning?
• What logs are missing?
• Which assets are business-critical?
• Which controls are present, absent, or failing?

Asset context turns MDR from generic alert review into prioritized operations. An alert on a test machine is not the same as an alert on a domain controller, cloud control-plane asset, payment system, build server, or executive endpoint. An exposed vulnerability on an internet-facing revenue system is not the same as the same CVE on a low-value internal host.

The future MDR has to understand this context automatically in a dynamic envirionment.

Exposure And CTEM

This is probably the most important adjacency. Classic MDR waits for something to fire. Exposure management asks what can be attacked before the alert exists.

The future MDR should know:

• What is exploitable?
• What is internet-facing?
• What is business-critical?
• What is currently being targeted?
• What attack paths exist?
• What should be fixed first?
• Which exposures actually got closed?

This is what moves MDR from reactive monitoring to proactive risk reduction. The important distinction is that this cannot just be scanner reporting. Vulnerability management becomes an MDR extension only when it is tied to exploitability, asset criticality, identity paths, observed threat activity, and actual remediation workflow.

SIEM And Data Quality

MDR is only as good as the data it can use. That makes SIEM operations and data quality core to the future model, even if the MDR provider does not own the SIEM product.

The provider should know:

• Are the right logs ingested?
• Are important sources missing?
• Are fields normalized?
• Are detections using the right data?
• Is retention sufficient?
• Is query performance good enough for investigation?
• Is SIEM cost being optimized?

This becomes more important as AI changes the interface to the SOC. If AI becomes the primary user of security data, the SIEM UI may matter less, but the quality, structure, accessibility, and completeness of the data matter more.

Cloud And Identity Posture

Modern attack paths increasingly run through identity, SaaS, cloud entitlements, workload permissions, and configuration mistakes. That means cloud and identity posture are not optional context for serious MDR.

The future MDR should understand:

• Who can access what?
• Which identities are overprivileged?
• Which accounts are risky or stale?
• Which cloud paths create attack chains?
• Which workloads are exposed?
• Which posture issues make detection or containment harder?

Without this context, MDR sees too little. It may detect a suspicious event, but miss the path that made the event possible.

Response Orchestration

The MDR has to respond faster than human-speed response, but safely. The system should be able to:

• Isolate an endpoint
• Disable or step-up an identity
• Block an indicator
• Remove malicious artifacts
• Open and route tickets
• Trigger patching or remediation workflows
• Escalate to IR
• Prove that the action happened

The word “safely” matters. MDR automation cannot become a blind SOAR playbook that breaks production. The provider needs policy, approvals, rollback paths, asset criticality, business context, and evidence that the response improved the situation.

What The Future MDR Should Prove

The old MDR output was an investigated alert. The future MDR output should be a safer environment. That changes the questions the service should answer:

• What percentage of critical assets are covered by EDR, vulnerability scanning, identity telemetry, cloud telemetry, and relevant logs?
• Which high-risk exposures were removed this month?
• Which attack paths were closed?
• Which detections improved because missing telemetry was fixed?
• Which response actions were automated safely?
• Which risks were accepted by the business?
• Which risks were remediated?
• Did measurable exposure go down?

This is the reporting layer that matters. Not activity reporting. Not “we reviewed this many alerts.” Not a dashboard that proves the provider was busy.

The stronger MDR report says: here is what exists, here is what is exposed, here is what we saw, here is what we did, here is what changed, and here is the risk that remains.

The Market Implication

The MDR market will split between alert-centric providers and control-plane providers. Alert-centric MDR can still be useful. Many buyers still need 24/7 investigation, escalation, and containment. But that model will be pressured by platform vendors, automation, and buyer expectations for more context.

The more defensible MDR provider will move upstream and downstream at the same time. Upstream, it owns asset context, control coverage, telemetry quality, exposure prioritization, cloud posture, and identity posture. Downstream, it owns containment, remediation orchestration, incident response, validation, and outcome reporting.

That is the future MDR control plane. The category may keep the same name, but the job changes from outsourced alert handling to command central for cyber risk reduction.

I will follow up on this with another MDR post to explore some topics a bit more, such as:

• The product aspect of the MDR service business
• The MDR symbiotic relationship with SIEM
• AI changing the MDR platform architecture
• Detection having to move into automated response

Stay tuned …

MDR started as a practical answer to a very real problem: customers had too many security alerts, too few security operators, and no realistic way to staff a strong 24/7 security operations center (SOC). That problem still exists. Fast investigation and response are still table stakes. But the category has to move beyond “EDR alerts plus analysts.” The MDR of the future is not just a better alert triage desk. It is the control plane for cybersecurity operations and cyber risk reduction. The winning MDR will own the loop from what assets exist, to what is exposed, to what telemetry is missing, to what detection fired, to what response should happen, to whether risk actually went down.

The Adjacency Test

In the following post I am exploring how MDR will need to evolve into the future. What adjacent markets are of importance and how can MDR solutions expand their services to help secure organizations?

The adjacency test to understand whether a use-case or product or service should be added to the original MDR service is simple: Does this capability make MDR better at preventing, detecting, prioritizing, responding, or proving risk reduction? If yes, it is a natural MDR extension. If not, it may still be a good product, but it is probably not core MDR.

With that, I’ll be using the following scale to rate various adjacent capabilities:

The Five Buckets

The future MDR stack can be organized into roughly seven buckets of use-cases that each contain multiple products or services themselves as I will outline below.

This is the shape of the future MDR control plane. The center of gravity is not just alert handling. The center is the operating loop that connects visibility, exposure, detection, response, and proof of improvement.

The Capability Map

Here is how I would expand the capabilities within each of the buckets and score them for MDR importance.

Detection & Response Core

Visibility & Data Control

Exposure & Posture

Messaging, Identity & Human Risk

Recovery & Resilience

Enforcement Surfaces

Broader Portfolio

I will let this sit here as just categories for now and will outline in a future post what questions are underlying these categories to make the MDR service more effective and what this all means for the MDR market at large.

“AI lowers execution cost, not accountability. SMBs outsource accountability.”

It will affect SMB customers, the MSPs serving them, and the software vendors selling into the channel. Those are three different layers, and the impact on each one is different.

SMBs Still Do Not Want To Own the Problem

One concern is that AI makes knowledge cheaper and tooling easier, so SMBs may decide to manage more of their own IT.

I do not think that is the main outcome.

Most SMBs do not hire an MSP because they cannot access software or information. They hire an MSP because they do not want to own the problem. They want someone else to choose the tools, deploy them, keep them running, support users, stay current, and deal with issues when something breaks.

AI may make parts of IT easier. It does not remove the need for responsibility. That is why I think AI is unlikely to reduce the need for MSPs in any dramatic way.

MSPs Get More Leverage

Inside the MSP, the impact is more direct.

A lot of the work is repetitive: triage, ticket handling, investigation, internal knowledge lookup, and workflow coordination across too many systems. AI can improve all of that.

That does not mean the MSP becomes irrelevant. It means the MSP becomes more efficient.

A smaller team may be able to support more customers, resolve more issues, and operate with fewer manual steps. In security especially, where talent is scarce, that matters a lot. The near-term effect of AI on MSPs is not disintermediation. It is better leverage, better scale, and a different labor model.

MSP Software Vendors Face the Real Reset

The most interesting pressure may land on the MSP software vendors.

The issue is not whether they can add AI features. They all will. The real issue is whether they can get on the AI coding wagon fast enough and turn that into much faster product development.

AI-native development practices will increase the amount of software the market can produce. More gets built. Iteration cycles get shorter. Focused startups can come in faster. And incumbents lose some of the advantage that came from simply being large, embedded platforms.

That is where the moving-fast disadvantage shows up.

Big vendors carry legacy code, older architectures, complex customer requirements, and years of accumulated product sprawl. It is much harder for them to become truly AI-first development organizations than it is for a newer company starting fresh. There is a big difference between developers occasionally using AI and a company rebuilding product, engineering, testing, and delivery around AI-assisted speed.

If incumbents make that shift well, they will benefit enormously. If they do not, AI will not just improve their products. It will make newer competitors much more dangerous.

What Changes From Here

My current view is simple.

AI is probably a tailwind for MSP demand. It is clearly a lever for MSP efficiency. But it may be most disruptive to the software vendors serving the market, because it changes the speed of product development and lowers the barrier for new entrants.

MSPs are not going away. But the basis of competition is changing.

Everyone is suddenly looking at MSP and MSSP rollups. Investors, strategics, even VCs. The logic is obvious. Fragmented market, recurring revenue, sticky customer relationships. But the reality is that only a small subset of providers actually operate at a level worth scaling. The difference between an average MSSP and a good one comes down to a few fundamentals.

Start With Focus

Most MSPs never defined who they serve. They grew organically, took whatever customer showed up, and built a toolkit around individual fires rather than a repeatable model. A strong MSSP starts with clarity. Who is the ICP. What problem is being solved. What the operating model looks like for that segment. When this is missing, everything becomes random. Different tools. Different service quality. No leverage.

In practice, the most important segmentation is not the MSP itself, but who the MSP sells to. An MSP serving restaurants or spas has a fundamentally different security maturity, willingness to pay, and regulatory exposure than one serving regional banks, healthcare, or regulated SMBs. Treating them as one market leads to mispriced risk and churn.

Understand the Economics

Many MSPs think software licensing is their main cost. It is not. Labor dominates the model. At ConnectWise, our Service Leadership dataset showed that roughly 20 percent of MSPs were not profitable because they simply did not understand their own cost structure. The best ones hit around 20 to 25 percent EBITDA. They standardize. They price correctly. They run the business with discipline instead of firefighting.

The real margin killer is not the license costs. It is the technician minutes required to install, manage, respond, document, and bill every tool. Every additional product increases operational drag, even if the license is cheap.

Standardized Security Bundles Win

The MSSPs that scale do not let customers choose their own adventure. They define a required stack. If you want to be a customer, you adopt their bundle. This gives consistency, predictability, and actual security outcomes. A typical bundle includes:

• Patch and vulnerability management
• Endpoint protection
• Email security
• Security awareness
• Optional SIEM or MDR depending on the segment

Without standardization, you cannot maintain margins or guarantee service quality. You also make incident response dramatically harder because every environment looks different.

In reality, the bundle is usually sold at a fixed price like $50 to $100 per user per month. Any new security tool must fit inside that number. If it costs $2 to $3 per user, something else must be removed or margin gets cut. This is why getting into the bundle is harder than most vendors expect.

Service Quality Is the Product

SMBs want to be secure. They want minimal disruption. And when something goes wrong, they want a real human who knows what they are doing. Not tier 1 scripts. Not delays during an active incident. Good MSSPs prepare the customer during onboarding. They map critical systems, define escalation paths, understand what can be taken offline, and capture credentials and architecture details. They remove the guesswork from the moment the incident starts.

Billing Needs To Be Simple

One of the fastest ways to lose customers is confusing invoices. Customers want to understand what they pay for. Surprises create distrust. The MSSPs that retain well keep billing predictable, transparent, and boring.

Own the Response, Not Just the Alert

An MDR or MSSP that only notifies customers creates frustration. The provider must take the customer through remediation. For SMBs, response often means restoring operations, identifying the entry point, and closing the gap. If the MSSP cannot do this internally, it must have reliable partners.

How Rollups Actually Create Value

Rollups only work when there is a clear thesis. Some focus on platform unification and a single delivery model. Others focus on professionalizing the business with better hiring, benefits, pricing, and operational rigor. Both paths can work. But they require patience and real operating muscle.

The fastest way to build a defensible platform is often not direct MS(S)P sales but embedding into existing security vendors that already sit in the bundle. Winning a technology alliance with an EDR, MDR, or firewall provider puts you into hundreds of MSPs without forcing each of them to make a new buying decision

Cross border rollups in Europe introduce more complexity. Language and local relationships matter. Regulation varies. Centralizing delivery is possible, but customer interaction often stays local. A standardized platform can still work if the ICP is consistent across regions.

The Microsoft Factor

Many SMBs already own security features through M365. Ignoring this leads to bloated stacks and poor pricing. Smart MSSPs align their offering with what customers already have and fill the real gaps.

The Bottom Line

Building a strong MSSP is not mysterious. It requires a defined ICP, a standardized security bundle, disciplined delivery, true incident readiness, transparent billing, and the ability to take customers all the way to resolution. The providers that do these things consistently are the ones worth scaling. Investors often chase the rollup story, but the real value sits inside the boring operational fundamentals that most of the market never gets right.