Why MDR and DFIR providers will converge on the same work

MDR and DFIR providers have traditionally entered an incident at different points. The MDR provider watched the environment and decided whether suspicious activity needed escalation. The DFIR firm entered when detection and response had failed and the attacker was already inside. This division is breaking down. MDR providers want to take investigations further before handing them off, and DFIR firms want recurring work between major incidents. Both are moving towards the same service: continuous investigation built on evidence collected from the affected systems. 

MDR buyers expect more than an alert

Forrester advises MDR buyers to test how detection, response and forensics work together, including whether forensic investigation requires a separate hand-off. Its report on the European MDR services market lists investigation among the capabilities buyers should evaluate alongside detection and response. The commercial implication is that a provider able to take an alert further resolves more of the customer’s problem before another team has to be involved.

Taking an alert further requires more than additional telemetry. Logs and alerts are essential to detection, but they are partial records of system activity. Memory-resident tooling, persistence mechanisms and activity conducted with legitimate credentials may leave little distinctive evidence in the monitoring stack. CrowdStrike’s 2026 Global Threat Report found that 82% of detections were malware-free, up from 51% in 2020. The evidence needed to resolve such a case often sits in memory, the process tree, the file system or another endpoint artefact. Detection tells the provider where to look for it, but the investigation has to establish what happened.

DFIR has the opposite growth problem

DFIR firms already have investigative depth. Their problem is that most of their work begins after something has gone badly wrong, which makes revenue episodic and hard to plan around.

But now the same capability used for digital forensics can be applied for good effect earlier. Scheduled compromise assessments, threat hunts, managed investigation, post-remediation validation and readiness work all draw on the skills and tooling a DFIR firm already has. Binalyze’s service-provider proposition is built around this. IR teams can pre-deploy the platform across retainer customers, collect scheduled baselines and enter an incident with evidence already in hand, and the same site positions threat hunting and other proactive services as recurring revenue.

That changes what the firm can deliver and sell. It stays involved between incidents, looks for compromise, tests the customer’s assumptions and turns what it learns into hunt and detection content for the next engagement. The customer buys continuity as well as expertise.

The two models meet in the investigation

An MDR provider has continuous sight of the environment. A DFIR firm has the depth. Imagine a service that combines the two runs as follows. An alert triggers an investigation. The provider frames the likely explanations and collects the evidence that would distinguish between them. Each explanation is then tested against affected systems. Where the evidence leaves a question open, the investigation collects more. The result is confirmed, refuted or inconclusive, with any evidence gap identified.

Neither of the two services typically offered today works this way. Escalation from an MDR service happens because the answer is not in alerts or logs, and forensic collection under an IR retainer usually only starts after a major incident has been declared. This change means moving forensics from a report produced after the event to live evidence that your SOC and IR analysts can also use while the incident is under way 

Win/Win through convergence

For an MDR provider, deeper investigation lets you resolve more cases without escalating to an IR team, which is how Binalyze positions AIR for the SOC. If you run a DFIR practice, the same capability gives you recurring work between breaches: threat hunting and compromise assessments inside retainers, or sold as separate managed services. The economics differ, but in either case you end up owning a larger part of the incident lifecycle than before. 

The IR boundary still matters – but it is becoming porous.

Convergence does not mean every investigation stays inside a managed service. Formal incident response carries legal, governance and decision-making requirements that differ from routine MDR work. Forrester warns about the MDR-to-IR transition: unclear escalation thresholds cost time and lose context. They also create problems around authority and legal protection.

The boundary therefore needs to be demarcated and formalized. A managed investigation can establish what happened and scope the affected systems while preserving the evidence. Once an incident crosses the agreed threshold into formal IR, who holds authority changes, and legal involvement and response governance change with it. When the same investigative foundation is used on both sides of that threshold, the evidence and context carry across and the customer does not have to start the case again with a new team.

Making forensic depth the default

Forensic investigation used to be expensive because it depended on specialist time and manual collection, and a service built that way cannot run as a routine managed offering. The alternative is tiered collection: lightweight acquisition for routine cases, deeper collection when the evidence warrants it, and full forensic work for incidents that require it. Binalyze AIR is designed around that model. Remote acquisition gives SOC analysts forensic depth without turning every alert into an IR engagement, and IR teams can automate collection and correlation and use the same platform for proactive services.

An MDR firm can add investigative depth with the SOC staff it already has, and a DFIR firm can sell scheduled hunting from the bench it already runs. Both gain the ability to detect a problem, investigate it against evidence and carry the context into response, and the provider that can do that owns more of the customer relationship.

Explore how Binalyze supports MSSPs and IR service providers. MSSPs and incident response providers expand investigative capacity without increasing operational complexity.

About guest author Oliver Rochford

Oliver has worked in cyber security as a penetration tester, consultant, researcher, and industry analyst for companies like Qualys, Tenable, Verizon and Securonix. He has been interviewed, cited, and quoted by the media, think tanks, and academic institutions, and has written for Securityweek, and CSO Online.

While at Gartner as an analyst, he co-authored the Security Information and Event Management (SIEM) Magic Quadrant and co-named the Security Orchestration, Automation, and Response (SOAR) market. He runs his own tech advisory firm, the Cyberfuturists, and publishes the Curious AI newsletter and aisocnews.com.

Follow Oliver on LinkedIn.

The Investigation Bottleneck Hiding Inside Your SOC

For a managed security service provider, winning another customer is usually only good news if the operation can absorb the work without reducing margins.

Monitoring scales comparatively well. Platforms centralise events, detections can be standardised and alert-handling processes can be distributed across shifts. Investigation is harder. The moment a customer asks what actually happened or whether it is safe to recover, the work inevitably becomes more bespoke and deeper, requiring scarce expertise, and thus more variable in effort and cost.

This is where many MSSPs encounter a growth ceiling. The constraint is not simply the number of alerts their platform can ingest and alert on. Increasingly, it is the number of defensible investigations the team can complete end to end without senior analyst time becoming a bottleneck.

Investigation work is non-linear

An alert may be handled in minutes when its context is complete, but sometimes, a genuine incident doesn’t behave so neatly.

Evidence may be spread across endpoints, cloud workloads and identity systems. One artefact, rather than resolving the issue, opens new questions that require additional data only available on another host. A hand-off from L1 to L2 or L3 often means the next analyst has to rebuild their own context. If the existing tools cannot establish root cause or scope, the team may need to deploy specialist collection tooling or even involve an outside forensic provider.

Each exception adds delay and eats more senior time. As customer volume grows, these exceptions compound.

Binalyze’s State of Cybersecurity Investigations 2026 shows how widespread the constraint has become. Ninety per cent of CISOs said skills gaps had hampered investigations, only 32% believed they had all the skills required to investigate fully in-house, and 71% were worried that skilled investigators were overworked and at risk of burnout.

For an MSSP, this is both a customer problem, and a delivery problem. Customers often turn to their MSSP to fill an investigation gap, but the provider’s most experienced investigators also become its hardest resource to scale. 

Adding analysts is not a complete scaling strategy

Hiring matters, of course, but it can never fully make an inconsistent workflow repeatable and scalable. 

If each investigation relies on an expert deciding what to collect, moving data between tools, reconstructing the timeline and having to reconstruct and explain their conclusion from scratch, investigation workloads rise almost in step with customer numbers. Senior responders remain bogged down in routine data acquisition and triage because the processes depend on the knowledge held in their heads.

This creates three commercial impacts:

• Delivery costs rise with case volume.
• Response quality varies according to who is available.
• The provider becomes cautious about promising deeper services to more customers.

The operational goal should be to separate repeatable investigative work from the work that requires human judgement from a senior expert.

Build a repeatable evidence layer

A scalable investigation always begins and ends  with fast access to the relevant evidence.

When remote collection, automated analysis, timeline construction and case management are part of the standard workflow, analysts do not need to assemble a temporary forensic process after each and every escalation. First responders can gather investigation-ready context, so the next analyst can continue in the same case, and Senior staff can spend their time on the cases that genuinely require judgement and on deciding how to respond. 

This necessitates more than just automating a checklist. It requires a closed investigation loop:

1. Start with the signal from the SIEM, EDR or XDR.
2. Frame the questions that determine whether the activity is benign or malicious.
3. Collect the relevant forensic artefacts from the affected systems.
4. Test the hypotheses against those artefacts.
5. Expand the collection only where the evidence leaves a material gap.
6. Conclude with a confirmed, refuted or explicitly inconclusive finding.

The loop has to be bound by evidence. Collection and analysis can run quickly and consistently, but people retain control of actions that could materially affect the customer. 

Capacity without compromise

For service providers, the gains materialize on several levels.

• More cases per team. Analysts spend less time deploying tools, gathering data manually and rebuilding context after hand-offs.
• More consistent service across customers. A common investigative workflow reduces the difference between the experience delivered by one shift, analyst or region and another.
• Better use of senior expertise. Experts review evidence and resolve ambiguity instead of serving as the collection engine for every case.
• Faster customer communication. Teams can report what is known, what has been ruled out and what remains unresolved without waiting for an improvised forensic process.
• A stronger basis for automation. Repeated investigations can be measured for time to first evidence, time to scoping confidence, escalation rate and consistency of verdicts.

Crucially, achieving these efficiencies does not require the MSSP to replace its entire detection stack. SIEM, EDR, XDR and SOAR still generate and orchestrate useful signals. But the investigation layer completes the workflow by giving analysts access to the endpoint and cloud evidence needed to turn those signals into answers.

Measure capacity by outcomes, not alert volume

Alert counts are easy to report, but ultimately say little about the work customers value most. A better operating view asks:

• How long does it take to acquire the first useful evidence after escalation?
• What proportion of cases reach scoping confidence without senior intervention?
• How often is work repeated after a hand-off?
• How many investigations end without a defensible root-cause assessment?
• How much expert time is spent on collection rather than judgement?

Improving those metrics is how you create real margin-friendly  capacity. This way, an MSSP can grow without allowing service quality, margins or analyst wellbeing to absorb the cost.

The MSSPs that stand out are never really those who process the greatest number of alerts. It is those who can turn more of those alerts into fast, consistent and defensible investigations.

Explore how Binalyze helps MSSPs and incident response providers expand investigative capacity without increasing operational complexity.

About guest author Oliver Rochford

Oliver has worked in cyber security as a penetration tester, consultant, researcher, and industry analyst for companies like Qualys, Tenable, Verizon and Securonix. He has been interviewed, cited, and quoted by the media, think tanks, and academic institutions, and has written for Securityweek, and CSO Online.

While at Gartner as an analyst, he co-authored the Security Information and Event Management (SIEM) Magic Quadrant and co-named the Security Orchestration, Automation, and Response (SOAR) market. He runs his own tech advisory firm, the Cyberfuturists, and publishes the Curious AI newsletter and aisocnews.com.

Follow Oliver on LinkedIn.