Your SIEM Detects in 51 Minutes. Attackers Are Gone in 6.

The fastest intrusion CrowdStrike measured last year went from a stranger's first foothold to active control of a host in 27 seconds. The average eCrime breakout time - the window between initial access and the first lateral move - is now 29 minutes. Hold those clocks next to the number that should worry anyone who owns a SIEM: across one large managed-detection provider's customer base, the average time for the platform to surface a detection is 51 minutes. In the fastest cases the attacker has landed, staged, and left with the data before the query meant to catch them has even run.

This is the detection gap, and in 2026 it is widening from both ends. If your program already measures mean-time-to-detect in single-digit minutes on the techniques that matter for your environment, treat this as a checklist and move on. It is written for the much larger group: the small security team, the one-person SOC, the IT lead who stood up Microsoft Sentinel or a Splunk instance, pointed every log source at it, and assumed coverage followed ingestion. Coverage does not follow ingestion. The distance between how fast attackers move and how fast a default SIEM notices is the most expensive blind spot most small teams do not know they carry, and closing it is mostly a question of where your detections live, not how much you spend feeding the index.

What the 2026 numbers actually say

Three reports published this year, each built on real incident data rather than survey opinion, point the same way. The attack side is compounding while the detection side improves by single digits.

• CrowdStrike's 2026 Global Threat Report put the average eCrime breakout time at 29 minutes, a 65% gain in attacker speed over 2024, with one observed intrusion reaching data exfiltration within four minutes of initial access. AI-assisted adversary activity rose 89% year over year. See the CrowdStrike findings summary.
• Palo Alto's Unit 42, drawing on more than 750 incident response engagements, described attacks as four times faster year over year. The quickest quartile of intrusions reached exfiltration in 72 minutes, down from 285 minutes a year earlier, and the share of cases that exfiltrated in under an hour climbed from 19% to 22%. The figures are in the 2026 Unit 42 Global Incident Response Report.
• ReliaQuest, recapping its EXPONENT 2026 conference, reported a fastest observed intrusion-to-exfiltration of six minutes against that 51-minute average SIEM detection time across its base. Its EXPONENT recap is blunt about what that mismatch means for the traditional model.

Put plainly: the median attack still takes its time, but the fast quartile - the ransomware crews and access brokers who automate the boring parts - now finishes inside the window your SIEM needs just to raise its hand. Median dwell time has fallen for years; what changed is that the bottom of the distribution collapsed. You no longer get to plan for the average attacker. You have to be able to catch the fast one.

Why a bigger SIEM bill does not buy the minutes back

The instinct when detections feel slow is to spend: ingest more sources, buy more retention, add the vendor's new analytics tier. That spending rarely touches the actual problem. CardinalOps analyzed more than 13,000 detection rules across production Splunk, Microsoft Sentinel, QRadar, and Google SecOps deployments for its 2026 report and found that enterprise SIEMs detect roughly 21% of the MITRE ATT&CK techniques adversaries use - missing 79% - while 13% of the rules already deployed are silently broken and never fire. The same study notes the log data needed to cover more than 90% of techniques is already flowing into those platforms. The telemetry is sitting in the index. The detection logic to turn it into an alert is the part nobody wrote. The full breakdown is in the CardinalOps 5th annual State of SIEM Detection Risk report.

So the gap is a coverage-and-speed problem wearing a budget costume. More ingestion widens the haystack you already cannot search fast enough. This is also where I would push back on the loudest pitch of the year. Every SIEM vendor now sells an "agentic SOC" that promises an AI analyst to investigate and respond on its own. The investigation and triage gains are real and worth having. But an autonomous agent pointed at a storage tier that re-indexes on a delay inherits that tier's latency; pointing a faster brain at a slow data path does not make the data path fast. ReliaQuest's own framing from EXPONENT was that 76% of detection use cases do not need to touch the SIEM at all. The speed problem is architectural, and you solve architecture by moving the detection, not by renting a smarter query against the same slow store.

Detect where the telemetry is born

The model worth copying splits detection across three layers by how close it sits to the event. At-source detection runs inside the tool that generates the telemetry - your EDR, your identity provider, your cloud control plane - and fires in real time. In-transit detection evaluates events as they move through the pipeline, before they ever land in storage; ReliaQuest cited transit-layer detections firing in under five seconds. Storage-based detection is the classic SIEM query, and it is the right home for correlation, threat hunting, and compliance retention - the work that tolerates minutes or hours.

For a small team, the practical translation is a reordering of trust. Your fastest, highest-signal detections belong at the source:

Where your front-line tripwires should actually live

• Endpoint: let the EDR block and alert on credential theft, LSASS access, and known offensive tooling in real time, rather than reconstructing it from event logs an hour later.
• Identity: turn on the native risk detections in Entra ID or Okta - impossible travel, anomalous token use, new-device sign-ins - so the alert fires at authentication, the moment most 2026 intrusions actually begin.
• Cloud: enable the platform-native detections (AWS GuardDuty, Microsoft Defender for Cloud) that watch the control plane and fire without waiting on a log export and a scheduled search.

Keep the SIEM. Just stop asking it to be the thing that catches a six-minute attack. Demote it from front-line sensor to correlation engine and system of record, and let the source-layer controls own the clock.

Detection engineering a two-person team can run

Detection engineering sounds like a discipline that needs a dedicated team. The version that fits a small shop is narrower and entirely doable. It is the practice of deciding what you must catch, writing the logic to catch it, and proving the logic works - on repeat.

The five-step loop

• Pick your real techniques. Do not chase all of MITRE ATT&CK. Choose the 10 to 15 techniques that match how attackers hit organizations like yours: phishing to token theft, remote-management-tool abuse, credential dumping, and archive-then-exfiltrate. Coverage of the few techniques in your real threat model beats a dashboard that claims thousands of rules.
• Write detections as code. Author rules in Sigma so they are portable across Splunk, Sentinel, and Elastic, live in a git repository, and get peer review like any other code. A rule in version control is a rule you can test, diff, and trust.
• Detect the exfiltration step. It is your last chance before the data is gone. Cloud-sync tools such as rclone and MEGAcmd routinely show up minutes before exfiltration; a single detection on their command-line patterns catches the fast quartile at the one stage they cannot skip.
• Test what you wrote. Fire each detection against a safe simulation - the open-source Atomic Red Team tests map directly to ATT&CK techniques. A rule you have never seen trigger is a guess about your coverage, not a fact.
• Measure and re-validate. Track which techniques you cover, and re-run the tests on a schedule. That 13% broken-rule rate is what happens when a log format changes and nobody notices the detection went dark.

Here is the kind of detection that earns its place - a Sigma rule for the exfiltration step, watching for rclone driving a cloud copy on Windows. It is short, portable, and aimed at a technique the speed data says you cannot afford to miss:

title: Potential Data Exfiltration via rclone Cloud Copy
id: 2f7c9e10-rh26-detection-gap
status: experimental
description: Flags rclone executing a cloud copy or sync, a common
  minutes-before-exfiltration step in fast 2026 intrusions.
logsource:
  category: process_creation
  product: windows
detection:
  selection_binary:
    - Image|endswith: '\rclone.exe'
    - OriginalFileName: 'rclone.exe'
  selection_transfer:
    CommandLine|contains:
      - ' copy '
      - ' sync '
      - ' --transfers '
      - ' --multi-thread-streams '
  condition: selection_binary and selection_transfer
fields:
  - CommandLine
  - ParentImage
  - User
falsepositives:
  - Sanctioned backup or migration jobs that legitimately use rclone
level: high
tags:
  - attack.exfiltration
  - attack.t1567.002

Renaming the binary defeats the first selection, which is why the rule also keys on the embedded OriginalFileName and on the cloud-transfer flags an attacker still has to pass. Convert it to your platform with the Sigma CLI, push it as close to the endpoint as your EDR allows, and you have spent an afternoon buying back minutes that no amount of extra log retention would have given you.

Pick five techniques and detect them at the source

You will not close the whole gap this quarter, and you do not need to. This week, pick five techniques from your real threat model - start with token theft at sign-in and rclone-style exfiltration if you are unsure - and write one detection for each, placed as near the telemetry source as your tools allow. Fire every one against a test before you trust it. Next week, pick five more. A small team that detects its top techniques in seconds is in a stronger position than an enterprise paying for a SIEM that misses four of every five and never noticed.

If you want a second set of eyes on what your SIEM actually covers - measured against the techniques being used against organizations your size, not against a vendor's rule count - that review is the work we do every week. We help small teams prioritize the detections that matter, push them to the source, and prove they fire. Better to find the dark detection now than during the six minutes that count.