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:
Score
Meaning
5
Essential to future MDR
4
Very strong natural extension
3
Useful adjacency / segment-specific
2
Nice portfolio extension, not core MDR
1
Mostly unrelated / likely distraction
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
Area / Capability
Importance
Why It Matters For MDR
MDR / alert triage
5
Table stakes. MDR must investigate, validate, prioritize, and respond to alerts.
XDR operations
5
Correlates endpoint, identity, cloud, email, and network signals into investigations.
Enables removal of malicious emails and containment of active phishing campaigns.
Human / user risk scoring
3.5
User risk should influence prioritization, investigation depth, and response decisions.
Security awareness signals
2.5
Useful if tied to risk scoring and phishing outcomes; weak if only training content.
Collaboration security signals
3
Teams, Slack, Google Workspace, and M365 activity increasingly matter for identity and phishing investigations.
Recovery & Resilience
Incident response / DFIR
4
MDR often becomes first responder; IR capability improves containment, investigation, and recovery.
Malware analysis
3.5
Helps with advanced investigations, detection improvement, threat hunting, and IR.
Ransomware readiness
3.5
MDR value is higher when it can assess containment, recovery paths, and blast radius.
Backup posture visibility
2.5
Important for ransomware outcomes, but MDR usually needs visibility rather than owning backup.
Recovery coordination
3
Helps translate detection and containment into business restoration during major incidents.
Enforcement Surfaces
Endpoint isolation
4.5
One of the most important response actions in MDR.
Identity disablement / reset
4.5
Critical for account compromise, lateral movement, and cloud incidents. Ideally enabled as a dynamic, continuous, risk-based action.
Email removal / quarantine
4
Necessary for phishing and business email compromise response.
Firewall rule changes / blocking
3.5
Useful for containment and network-level response, especially in traditional environments.
SASE / ZTNA enforcement
3
Relevant for modern access control, but usually an enforcement integration rather than core MDR product.
SOAR / ticketing orchestration
4
Operationalizes response through customer workflows and approval gates.
NAC / network access control
2.5
Useful for unmanaged devices and segmentation, but segment-specific.
Broader Portfolio
Third-party risk management
2.5
Relevant to enterprise cyber risk, but only loosely tied to MDR unless connected to active threats/exposure.
Digital risk protection / dark web monitoring
3
Useful external context for credential leaks, brand risk, and executive threats.
Native endpoint protection
3
Powerful if vendor owns the stack, but independent MDR can remain tool-agnostic.
Native email security
2.5
Useful portfolio extension, but MDR mainly needs email visibility and response control.
Native firewall / network security
2.5
Helpful for suite vendors, but not required for MDR differentiation.
Unified endpoint management
2.5
Full UEM is IT operations; MDR mainly needs endpoint context and remediation hooks.
WiFi management
1.5
Too far from MDR except in branch, retail, campus, or healthcare-heavy environments.
WiFi security
2.5
More relevant than WiFi management because rogue devices and network access affect exposure.
Security awareness training
2
Helpful risk-reduction add-on, but weak MDR moat unless connected to user risk and phishing outcomes.
GRC / compliance reporting
2
Useful for board and audit reporting, but not central to detection and response quality.
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.
During my engagements with various Private Equity and Venture Capital outlets, I see a clear shift. The questions that is showing up more and more in due diligence is no longer, “What is your AI strategy?”
It is: “How far along are you in rebuilding the company around AI?”
That is a different question.
It applies to startups and incumbents alike. It applies to security companies, SaaS vendors, MSPs, and a lot of businesses outside those markets too. The point is no longer to add a few AI features, automate one workflow, or give employees access to a chatbot. The point is to rethink how the company actually operates.
AI Should Sit Under Every Corporate Function
The companies that will look strongest over the next few years are the ones treating AI as an operating system layer across the business.
That means product development, service delivery, sales and marketing, customer success, and finance and operations are all being reworked with AI in mind. Not as separate experiments, but as connected systems.
The important shift is not “where can we use AI?” It is “how should this function work if AI is built into the process from the start?”
That usually leads to a broader redesign. Workflows get compressed. Handoffs change. Data gets linked across teams. Software that used to just record tasks between humans starts becoming an orchestration layer between people and AI agents.
AI on Top Is Not Enough
Most companies are still treating AI like a feature layer. They add a copilot. They automate a few tasks. They run a few pilots in sales or support. Then they talk as if they have become an AI company. They have not.
If AI is going to matter as much as people claim, then it cannot live in isolated tools and side projects. It has to sit underneath the company as an operating layer. Product, service delivery, sales, marketing, customer success, finance, and operations all need to be rethought with AI built in from the start.
That is the real shift. Not AI as garnish. AI as infrastructure.
In practice, this means a company’s core operating logic can no longer live in forgotten decks, static docs, and tribal memory. Vision, mission, strategic priorities, ICP, and go-to-market motions need to be embedded into the AI layer itself so teams can interact with them in daily work (literally let them chat with these pieces of information via Slack!). The system should be able to explain the strategy, test whether execution matches it, and keep the company aligned as it changes. If that layer does not exist, most companies are still operating on fragments.
This Is Now a Capital Question
This is also why the conversation is changing in private equity and VC diligence.
We are not just looking for AI messaging anymore. We are looking for evidence that the operating model is changing. Is the company shipping faster? Is service delivery getting more leverage? Are teams linked better? Is software being used to orchestrate work between humans and AI agents rather than just record tasks? Is management actually rebuilding the business, or are they still presenting AI as an add-on?
Those questions now matter directly to competitiveness.
A company that keeps the old operating model and bolts AI on top will lose to one that rebuilds around it properly. The latter will move faster, learn faster, and eventually operate at a different level of efficiency.
The Companies That Wait Will Pay For It
I think this is becoming a funding imperative.
Before raising capital, before pursuing a sale, and before the board forces the discussion, management teams need to be doing the hard work of redesigning the company around AI.
Because the market is not going to wait for slow adopters to get comfortable. The companies that embrace AI as a true operating layer will look more scalable, more durable, and more investable. The ones that do not will increasingly look like they are running yesterday’s model in a market that has already moved on.
