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.
