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 …

One of the more interesting messages going into RSA was not just that AI is reshaping security. It was that the market is changing what it rewards. I had the pleasure of attending the Piper Sandler investment day on Monday at RSA, one of my favorite events where I get to catch up with many friends, meet new security leaders and get an update on the security market conditions.

The market for cyber security companies last year was easier: grow fast, expand inside the account, add modules, and let NRR do the talking. The new story looks different:

• ARR growth expectations have come down from 50% to 30%
• Gross margin expectations have moved up from 75% to 80%
• NRR expectations have come down from 120% to 115%
• GRR expectations have moved up from 88% to 92%
• Burn multiple expectations have tightened from 1.5x to <1.0x

That may sound like a generic software market shift. I do not think it is. I think it has very specific implications for AI SOC and SIEM. More about that later.

Capital markets changed first

The broader market backdrop matters. Security is still one of the more attractive areas in software, but it is being valued inside a much harder capital markets environment. The IPO window remains narrow. Liquidity for scaled assets is limited. Growth is decelerating across software. And AI is compressing valuations by making forward revenue less credible and product durability more important. That combination changes the conversation from upside to survivability.

Security is still attractive, but the bar is higher

That is why the security market now feels bifurcated. On one side, it still benefits from strong structural demand: geopolitical uncertainty, expanding attack surfaces, and AI itself creating new categories of spend. On the other side, investors are becoming much less willing to underwrite broad TAM stories, multi-year expansion narratives, or “we will grow into the model” margin profiles. Security remains attractive, but the bar is higher.

Private equity has a liquidity problem

Private equity is caught in that tension as well. Large assets are staying private longer because the public market is not offering a clean exit path. That creates pressure on hold periods, return profiles, and liquidity planning. More firms will need to create liquidity through secondaries, continuation vehicles, and other forms of fund-to-fund reshuffling rather than relying on traditional exits. That is not a theoretical issue. It shapes what kinds of assets still look financeable, what kinds of stories buyers will believe, and how aggressively firms can keep marking winners.

M&A gets more strategic from here

At the same time, strategic logic is getting stronger. Large-scale M&A should remain active because buyers still want growth, but they increasingly want growth that is accretive, platform-relevant, and commercially durable. The market is likely to reward scaled platforms, integrated environments, and assets that can either deepen data advantages or simplify the stack. It is likely to punish products that still depend on expensive customer education, loose positioning, or heroic expansion assumptions.

AI increases both risk and defensibility

AI only sharpens that divide. In security, AI is both a disruption risk and a source of defensibility. It creates fear around older architectures and weaker product moats, but it also increases the value of proprietary telemetry, embedded distribution, and control points across the enterprise. The winners are less likely to be those with the loudest AI messaging and more likely to be those with the strongest combination of data, workflow ownership, and commercial leverage.

Platformization is really about data gravity

That is also why platformization matters so much right now. This is not just a consolidation story. It is a data gravity story. The vendor that sees more telemetry, sits in more workflows, and becomes harder to dislodge can improve models faster, distribute new capabilities faster, and defend retention more effectively. In a market that now cares more about GRR, margins, and burn discipline, that matters a lot.

What this means for AI SOC and SIEM

This is where the implications for SIEM and AI SOC come into focus. The category is seeing real pressure from both sides: incumbent platforms facing pricing and architectural questions, and newer entrants offering better workflows, AI-native interfaces, and more agentic operating models. But the long-term winners may not be the vendors with the sharpest demo. They may be the ones that combine durable retention, meaningful use-cases, security outcomes, and enough platform surface area to remain central as the security stack becomes more automated and more agent-driven.

Source: Piper Sandler Keynote Deck