May 5, 2026
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.
| Bucket | Included Areas | Importance |
|---|---|---|
| Detection & Response Core | MDR, XDR, alert triage, threat hunting, response automation | 5 |
| Visibility & Data Control | SIEM ops, telemetry quality, log coverage, asset inventory, agent coverage | 5 |
| Exposure & Posture | CTEM, vuln prioritization, patching, CSPM, SSPM, identity posture, attack paths | 5 |
| Messaging, Identity & Human Risk | Email security, phishing response, user risk, identity risk, awareness | 4 |
| Recovery & Resilience | IR, DFIR, ransomware readiness, backup visibility, recovery coordination | 3.5 |
| Enforcement Surfaces | Management of firewalls, SASE, ZTNA, endpoint isolation, email removal, identity responses | 3 |
| Broader Portfolio | SAT, GRC, WiFi management, TPRM, native endpoint / email / VM / firewall tools | 1.5-3 |
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. |
| Threat hunting | 4 | Moves MDR beyond reactive alert handling into proactive attacker discovery – customer specific. |
| Detection engineering | 4.5 | Determines whether MDR improves customer detections over time or only processes existing alerts. |
| Response automation | 4.5 | Enables faster containment and remediation without waiting for manual analyst execution. |
| Case management / investigation workflow | 4 | Provides evidence trail, collaboration, customer visibility, root cause analysis, and repeatable response process. |
Visibility & Data Control
| SIEM operations | 5 | MDR quality depends on log coverage, queryability, retention, parser quality, and SIEM tuning. |
| Telemetry quality monitoring | 5 | Detects missing logs, broken parsers, stale agents, dropped fields, and blind spots. |
| Asset inventory | 5 | MDR needs to know what the asset is, who owns it, and whether it is business-critical. |
| Agent / sensor coverage | 5 | Finds devices, users, workloads, or cloud resources that are not monitored. |
| Data pipeline / routing control | 4 | Helps control SIEM cost, prioritize useful telemetry, and route data to the right analytic layer. |
| Federated search / security data lake | 4 | Lets MDR query across tools and data stores without forcing all data into one SIEM. |
Exposure & Posture
| CTEM / exposure management | 5 | Turns MDR from reactive response into continuous risk reduction based on exploitable paths. |
| Vulnerability prioritization | 4.5 | Helps decide which vulnerabilities matter based on exploitability, asset criticality, and threat relevance. |
| Patch orchestration / verification | 4 | Closes the loop from finding risk to proving remediation happened. |
| CSPM / cloud posture / SSPM | 4 | Cloud incidents require context on misconfigurations, permissions, public exposure, and workload risk. |
| Identity posture / ITDR | 4.5 | Identity is a primary attack surface; MDR needs privilege, MFA, account, and behavior context. |
| Attack path analysis | 4.5 | Shows how attackers can chain exposures, identities, assets, and controls into real compromise paths. |
| Endpoint posture | 3.5 | Patch level, encryption, EDR state, configuration, and device health affect triage and response. |
Messaging, Identity & Human Risk
| Email security integration | 4 | Email is a major attack path; MDR must investigate and remediate mailbox threats. |
| Phishing investigation / response | 4 | Connects reported emails, clicked links, credential theft, endpoint activity, and account compromise. |
| Mailbox remediation | 3.5 | 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.
No comments yet.