Triskele Labs Blog

State of Cyber 2026 - MDR

Written by Brad Morgan | Oct 12, 2026, 11:53:46 PM

Prepared by: Triskele Labs MDR Team | Published: 13 October, 2026 

This report presents statistics and analysis from Triskele Labs' Managed Detection and Response (MDR) service for the 2025-26 financial year. The figures are drawn directly from Triskele Labs' case management platform, covering every alert that reached analyst or SOAR triage across the active client base.

MANAGED DETECTION AND RESPONSE · STATE OF CYBER 2026

At a Glance

Alert volume fell this year even as the client base grew, because tuning work removed noise before it ever reached an analyst.

What changed this year:

  • Total alerts fell 15% to approximately 223,000, even as the client base continued to grow. Tuning removed noise before it reached an analyst, mostly Low and Medium severity. The Critical ticketing rate fell from 16% to roughly 10%, even as the High-severity share rose. The mix moved toward the serious end.
  • High-severity detection time more than halved, from 14.9 to 7.1 minutes. Total time to close High-severity alerts improved 38%.
  • SIEM platforms carried roughly three-quarters of all alerts, and the load within them rebalanced: Artemis, Microsoft Sentinel and Rapid7 InsightIDR now each contribute around a quarter, where a year earlier InsightIDR alone carried a third. Endpoint detection and response (EDR), other SIEM platforms such as Splunk, operational technology (OT), dark-web monitoring and client-reported phishing make up the balance.

Key Findings:

  • Roughly one Critical alert in ten was escalated to the client for confirmation in FY25-26; around two-thirds of the rest were confirmed benign by an analyst within two minutes.
  • Cases were concluded within each client's agreed SLA 99.8% of the time.
  • More than half of Critical alerts (52%) arrived outside business hours, and they were picked up in a mean of 6.2 minutes, against 4.7 minutes during the working day.
  • 88% of clients had at least one staff credential exposed on the dark web or in a data leak during the year.

What you'll learn in this article: why alert volume fell even as the client base grew, why the balance of detection sources shifted, why response times lengthened for High, Medium and Low alerts, and how Critical alerts were resolved so quickly.

Detection and response trends across the 2025-26 financial year

Overview

Triskele Labs' Security Operations Centre processed approximately 223,000 alerts in the 2025-26 financial year (FY25-26). This equated to 15% fewer alerts than the previous year, while the number of client environments under management continued to grow. Delivering fewer alerts across a larger estate is the purpose of detection engineering, and it is the headline result of this year's report.

Analysts triaged 84% of those alerts and automation handled the other 16% end to end. Automation's share fell from roughly a fifth because many of the sources it previously absorbed were tuned out at origin, or removed altogether where clients worked with the SOC to put preventive controls in place or made environmental changes, leaving analysts with the alerts that need a person.

Alert Density

Measured per client per month, alert volume fell 31% across all case types and 27% for analyst-triaged cases alone. The improvement compounded through the year: average monthly alert volume in the second half (January - June 2026) was 28% lower than in the first half, on a growing client base.

False Positives and Alert Quality

Building on last year's tuning uplift, the SOC adopted a new classification standard in the final quarter of FY24-25. On this basis, approximately 93% of alerts in FY25-26 were determined to be benign true positives or false positives, and roughly 6% were confirmed as true positives. These proportions are not comparable with last year's published figures.

Alert fidelity continued to improve through the year, with the false-positive rate falling by roughly two percentage points between the first and second halves.

Mean Time to Detect, Respond and Conclude

Both years are reported as outlier-filtered means for analyst-triaged alerts. Last year's published figures were calculated without outlier filtering; the FY24-25 column has been restated on the same basis as this year so the two years compare like for like.

Mean Time to Detect (MTTD)

MTTD measures the time from case creation to analyst assignment.

Severity FY24-25 FY25-26
Critical 4.3 min 5.4 min
High 14.9 min 7.1 min
Medium 29.4 min 18.3 min
Low 84.8 min 56.8 min

High-severity detection time more than halved; Medium and Low improved by a third. Critical detection time rose by just over a minute to 5.4 minutes. Critical cases were still concluded in a mean of 6.5 minutes, well inside the Critical response targets agreed with clients.

Mean Time to Respond (MTTR)

MTTR measures the time from analyst assignment to case resolution.

Severity FY24-25 FY25-26
Critical 1.4 min 1.1 min
High 1.8 min 3.2 min
Medium 1.8 min 3.3 min
Low 1.0 min 1.9 min

Response times for High, Medium and Low lengthened by one to two minutes, the expected consequence of a cleaner queue. As low-value alerts were tuned out, the cases reaching analysts were more substantive and took longer to work. Critical response improved. Critical alerts resolve fastest because the decision is binary: an analyst either confirms benign activity within a minute or two, or escalates immediately to the client to validate the activity and, where approved, takes the required response actions. The escalated cases carry the remaining time as client confirmation, not analyst deliberation. Roughly one Critical in ten was escalated in FY25-26. The Critical alerts that resolve as benign also concentrate in a small number of detection rules, which makes them the SOC's highest-value tuning candidates.

Total Dwell Time: Mean Time to Conclusion (MTTC)

MTTC represents full case dwell time from creation to close, calculated as MTTD + MTTR.

Severity FY24-25 FY25-26
Critical 5.7 min 6.5 min
High 16.7 min 10.3 min
Medium 31.2 min 21.6 min
Low 85.8 min 58.7 min

Overall, 99.8% of cases were concluded within the SLA agreed with each client.

Cases by Detection Source

Roughly three-quarters of alerts originated from SIEM platforms, with endpoint detection and response (EDR), other SIEM platforms such as Splunk, operational technology (OT), dark-web monitoring and client-reported phishing making up the balance. Within the SIEM estate, volume is now spread almost evenly across three platforms: Artemis, Microsoft Sentinel and Rapid7 InsightIDR each contributed roughly a quarter of all alerts. That balance is new: a year earlier InsightIDR alone carried a third of volume. Its alerts fell by roughly 40% as tuning effort concentrated where volume had been highest, Artemis fell by around 15%, and Sentinel's volume rose by almost half as more clients were onboarded to it. The convergence reflects detection engineering, not a change in the client estate.

Explainer: Detection source share for FY25-26, showing SIEM platforms carrying the large majority of alerts and volume now split almost evenly across Artemis, Microsoft Sentinel and Rapid7 InsightIDR, a genuine convergence from FY24-25, when InsightIDR alone carried roughly a third of all volume. Other comprises Splunk, operational technology (OT), dark-web monitoring and client-reported phishing.

Strategic Importance of SIEM

Modern cyber threats rarely remain confined to a single endpoint. Attackers increasingly exploit credentials, move laterally through networks, and target cloud and SaaS infrastructure. In this landscape, an endpoint-only view is insufficient. A well-tuned SIEM aggregates and correlates telemetry from across the environment, including identity providers, network devices, servers, cloud applications and security controls, giving analysts a unified perspective to detect cross-domain activity that would otherwise go unnoticed in isolated systems.

Complementary Role of EDR

EDR remains an essential part of that ecosystem, providing deep forensic insight and rapid containment capability at the device level. But its scope is inherently limited: without correlation against broader environmental data through the SIEM, incidents that span multiple vectors, such as lateral movement or privilege escalation, may evade detection. The two are complementary, not substitutes for one another.

Severity and Ticketing

Just under half of all alerts were classified Medium severity, a little under 30% Low, just over 20% High, and under 2% Critical. The High-severity share rose from roughly 16% the previous year; the mix moved toward the serious end as low-value volume was removed.

Around 3% of alerts were escalated to a formal ticket, down from just over 4% the previous year, with Critical alerts escalated at roughly one in ten. A falling ticketing rate alongside a rising High-severity share indicates that alerts reaching analysts are better qualified before escalation, not that fewer incidents are being reported.

Explainer: Severity mix for FY25-26. Just over three-quarters of alerts were prioritised by their originating tools as Low or Medium severity, operationally relevant but with minimal security impact on their own, while the High-severity share rose year on year as lower-value volume was tuned out or client controls were implemented or uplifted.

Top Case Categories

The alert categories generating the most analyst work in FY25-26 were overwhelmingly identity- and authentication-related: anomalous ingress from new or multiple countries, authentication from unexpected geographies, disabled-account logins and repeated failed logons. These were followed by endpoint persistence and privilege signals (new local accounts, elevated-token process creation, remote scheduled tasks, hosts-file modification) and lateral-movement indicators. The fifteen most common named categories together account for under 10% of all alerts; the long tail of client- and rule-specific detections makes up the rest.

 

Explainer: Top ten case categories for FY25-26, each shown as a share of the top ten. Third-party alerts are detections from endpoint and cloud security platforms such as EDR and AWS GuardDuty, received through the Rapid7 SIEM rather than directly into the SOC case management platform.

Strategic insight. Identity and authentication detections continue to dominate analyst work. The controls that matter most are the ones that make a stolen credential useless: phishing-resistant multi-factor authentication, conditional access tied to location and device, and alerting on sign-ins from disabled or dormant accounts. Four of the top ten (new local accounts, hosts-file changes, elevated-token processes and remote scheduled tasks) are persistence and privilege signals, later-stage attacker activity, so detecting them is the backstop rather than the front line. The largest single category is findings from EDR and cloud security platforms, which the SOC triages against the full environment rather than in isolation.

Alerts by Industry Vertical

Financial services remained the largest single sector at roughly a quarter of all alerts, followed by healthcare (15%), resources and industrial (13%) and not-for-profit (12%). Technology and managed service providers, and retail, each contributed around 9 - 10%; legal and professional services, education, transport, government and insurance together made up around 14%, with other sectors accounting for the rest.

 

Explainer: Case distribution by vertical for FY25-26, showing Financial Services, Healthcare and Resources & Industrial as the most heavily represented sectors under Triskele Labs' MDR monitoring.


Strategic insight.
Financial services, healthcare and resources together carry over half of all alerts. These are the sectors with the most regulatory exposure, including CPS 234, the SOCI Act and the Privacy Act, and the most to lose from a reportable incident. The high alert volume reflects the depth of monitoring those obligations demand, not weaker security, and organisations in these sectors should expect their monitoring footprint to grow rather than shrink.

Around the Clock: Out-of-Hours Detection and Response

Attackers do not keep office hours, and neither does the SOC. In FY25-26, 44% of all alerts and 52% of Critical alerts arrived outside business hours (weekdays, 8am to 6pm). Out-of-hours Critical alerts were picked up in a mean of 6.2 minutes, against 4.7 minutes during the working day, and concluded in 7.1 minutes against 6.1: the same standard of response at 2am as at 2pm.

When an out-of-hours alert needs more than first-line triage, it is escalated to an on-call senior analyst. In FY25-26, on-call analysts handled 293 escalations across around 80 client environments, more than a third of them at weekends, and the volume rose through the year: 178 in the second half against 115 in the first. Nearly 90% were confirmed as warranting escalation, and 63% led to a response action, such as isolating a device or containing a compromised account. A typical escalation was resolved in around 20 minutes. Common triggers included staff entering their credentials into phishing pages, sign-ins from unexpected countries, malware execution and changes to privileged groups.

Strategic insight. More than half of the alerts that matter most arrive when an in-house team would be offline. Round-the-clock coverage is not a premium extra; it is where the risk sits.

Dark Web and Credential Exposure

Credential exposure is close to universal. During FY25-26, 122 of the 138 client organisations the SOC monitored (88%) had at least one staff credential surface on the dark web or in a data leak, and for 117 (85%) the exposure included a password.

In March 2026 the SOC moved dark-web monitoring to a new platform. The previous platform raised thousands of matches a month, most of them an email address with no password attached. The new platform raises a few hundred a month, each tied to a usable credential or a specific exposure, so analysts and clients spend their time on findings that warrant action. It can also see exposures the previous service could not: stealer logs taken from infected devices, credentials captured by phishing kits, source code published to public repositories, and organisations named on ransomware leak sites.

Strategic insight. A password on the dark web is only useful to an attacker if it still works. Phishing-resistant multi-factor authentication, prompt password resets on notification and the removal of dormant accounts turn an exposure into a non-event.

Monitoring Only Works If It Can See

The single alert type with the most confirmed-impact cases in FY25-26 was not an attack technique. It was a log source or security agent that stopped reporting: 666 confirmed cases from 6,186 alerts. When telemetry stops, the detections that depend on it stop with it, and nothing alerts on an attack the SOC can no longer see.

These gaps commonly follow a change in the client's environment that the SOC was not told about: a firewall replaced, a server migrated, a cloud tenant reconfigured, an agent removed during a rebuild. When the SOC is notified before a change, analysts can confirm afterwards that monitoring and detections still apply. When it is not, the gap is found only once the data has stopped.

Strategic insight. Always include your SOC in change management. A short notice of planned changes lets the SOC validate coverage the same day, rather than discovering a blind spot after the fact. Automated breach and attack simulation can take this further, testing continuously that controls and detections still fire after a change.

Phishing Reported by Staff

Staff reporting works. One in six phishing emails reported by client staff in FY25-26 was confirmed as a real threat (17% of 2,250 reports), and several out-of-hours escalations began with a staff member who had already entered their credentials into a phishing page.

The best results come when the client's own IT or security team reviews staff reports before forwarding them. They hold context the SOC does not, such as expected senders, internal campaigns and simulated phishing exercises, and can rule out the obvious quickly. Forwarding every report straight to the SOC turns a useful signal into a queue. A report that has been sanity-checked gets the SOC's full analysis, from the email headers to the behaviour of its links and attachments, and a faster answer.

Response, Not Just Detection

Detection is only half of managed detection and response. When an investigation confirms a threat, the SOC doesn't just raise an alert and wait for a reply. It acts on the client's behalf, for example by isolating a compromised device or disabling an account. Between November 2025 and June 2026, the SOC took direct response action in 301 incidents across 49 client organisations, and the pace grew through the year: 151 in April - June, up from 90 in January - March.

Strategic insight. Agree response authority before you need it. When pre-approved actions are in place, the SOC can contain a threat in minutes, including at 2am, without waiting for someone to call back.

Seeing Across the Estate

A shared SOC sees what no single organisation can. Every client benefits from what the SOC learns across all of them, in three ways.

Threat intelligence that travels. When an investigation confirms a malicious file, address or domain at one client, that indicator informs triage everywhere else. In FY25-26, around 400 indicators from confirmed incidents also turned up at a second client, and 156 were part of confirmed incidents at two or more. An attack the SOC has already seen once is recognised faster the next time, wherever it lands.

Detections built for one, available to all. When an incident or new threat research shows a gap in detection, the SOC writes a rule to close it. Where the same technique could affect others, the rule is extended across the estate.

Tuning with broader context. A detection's behaviour across many environments shows what is normal and what is not in a way that no single environment can. Activity that is routine across dozens of organisations can be tuned out with confidence. Activity that appears in only one place, or suddenly in several at once, stands out for exactly that reason. This is how alert volumes fell this year while the alerts that matter still reached an analyst. In FY25-26 the SOC made more than 1,200 tuning changes across 373 detection rules, and 76 of those rules were tuned at two or more clients. A rule that misbehaves in several environments is fixed once, for everyone, rather than one client at a time.

Strategic insight. An in-house team sees one environment. A managed SOC sees patterns across many, and that context is part of the value of every alert it triages.

Detection Engineering Investment and Forward Outlook

The year's headline, fewer alerts on a larger estate, was not accidental. Risk-informed detection engineering, tuned client by client, removed noise before it reached an analyst; and where an alert source could not be tuned, the SOC worked with the relevant client to eliminate it at origin. Since the close of the financial year Triskele Labs has stood up a dedicated platform-engineering capability spanning Detection Engineering, Cyber Threat Intelligence, Threat Hunting and Breach & Attack Simulation, so that this year's improvement compounds rather than plateaus.

Glossary

Term Definition
EDR (Endpoint Detection and Response) A tool that monitors and responds to threats at the device level, providing visibility limited to the endpoint itself.
MDR (Managed Detection and Response) An outsourced cybersecurity service that combines technology and human expertise to detect, investigate and respond to threats across a client's environment.
MTTC (Mean Time to Conclusion) The full case dwell time from creation to close, calculated as MTTD plus MTTR (the sum of the two means).
MTTD (Mean Time to Detect) The time from a case being created to it being assigned to an analyst.
MTTR (Mean Time to Respond) The time from a case being assigned to an analyst to it being resolved.
SIEM (Security Information and Event Management) A platform that aggregates and correlates log and telemetry data from across an environment to support threat detection.
SLA (Service Level Agreement) An agreed threshold for how quickly cases of a given severity should be handled.
SOAR (Security Orchestration, Automation and Response) Technology that automates the triage and handling of alerts without requiring analyst involvement.
SOC (Security Operations Centre) The team and facility responsible for monitoring, detecting and responding to security alerts around the clock.