Why detection arrives late: dwell time and containment
Rəşad Əliyev, Infrastructure & Security Engineer at viasoft
Dwell time is the window between infection and the detection of a threat, and it's built into the very logic of antivirus and EDR: to stop a threat, you first have to recognize it. In the major incident-response reports, this window is measured in days, not minutes. Containment (isolation-first) removes it: any unknown file is isolated immediately and cannot do harm until it's been assigned a verdict.
Why even a strong EDR is late, and how isolation-first changes the picture — we'll go through it in order, with honest caveats about the limits of both approaches. The main thought up front: the window is closed not by detecting faster, but because detecting-before-neutralizing is no longer required — the stranger is isolated by default.
A free review of your device protection → Contacts · Micro: estimate the cost → Project scope estimator
What dwell time is, and why it exists
Dwell time is the length of time an attacker or malicious code sits inside a system unnoticed. Every defense that works on detection logic has it: to stop a threat, you first have to recognize it — by signature, by behavior, by anomaly. Until the model flags the threat as malicious, the file counts as acceptable and runs.
For known threats, that works fast. The trouble is the new and the disguised. Across the industry's incident-response reports, the median dwell time has risen to 14 days (per Mandiant's M-Trends 2026), while the full breach lifecycle — from intrusion to identification and containment — averages 241 days at $4.44M per incident (per IBM's Cost of a Data Breach, 2025). These are two distinct figures from two distinct sources: the 14 days is the median time a threat sits unnoticed, the 241 days is the full lifecycle including response — we don't conflate them. And the attacks themselves have sped up sharply: by the same reports, the hand-off of access between groups shrank from eight hours in 2022 to 22 seconds. Either way the result is a structural gap: the defense is chasing, not staying ahead.
Why even a good EDR misses
Machine learning and behavioral analysis are a serious step forward from signatures, but they don't change the nature of detection itself: to stop, you first have to recognize. Four places where that breaks:
- Zero-day. A genuinely new sample that isn't in any database yet, and whose behavior doesn't resemble anything known, may not raise an alarm.
- Living-off-the-land attacks. The attacker doesn't bring in a new file — they use system tools that are already trusted, and to the detector it looks like routine work. By industry data, a growing share of attacks contain no malicious file at all.
- Evasion and disguise. There are well-practiced techniques built specifically to slip past the layer the EDR is watching (in-memory execution, hijacking trusted processes).
- The human factor. Even when an alarm does fire, someone has to see it and triage it in time — and in independent assessments there have been cases where the signal was there but no one acted on it.
EDR is needed — but you can't build your whole defense on detection alone: betting on a single detector leaves exactly those four gaps above. Independent defense guidance recognizes this too, recommending layered protection.
The other approach: containment (isolation-first)
Containment flips the logic. Instead of "allow until you recognize something bad," it's "isolate anything not proven good" (the Default Deny principle). Every process that launches lands in one of three buckets:
- known-good → runs freely;
- known-bad → blocked;
- unknown → automatically launched in an isolated container at the kernel level.
Inside the container, the program runs exactly as it would on a normal machine — the user notices nothing — but its access to the file system, the registry, and system calls is virtualized: it thinks it's changing the system, while in reality every change is routed into an isolated area and never touches the real machine. In parallel, a verdict is reached. A good file is released from the container; a bad one is deleted along with all of its "changes." The key thought: to protect, you don't need to prove a file is malicious. It's enough that it isn't proven safe. That's why even an unknown encryptor that lands on a machine ends up isolated and never reaches the real data — dwell time tends to zero by design. This is exactly how the Xcitium platform (the ZeroDwell technology) works, which we deploy in Azerbaijan as the exclusive distributor: the vendor is confident enough in the model to back it with a financial guarantee — 0% successful breaches when properly configured. How it's purchased and supported — on the Xcitium endpoint protection page.
An analogy: an ordinary antivirus is a guard with a stack of mugshots, checking everyone who comes in against known criminals; someone new or in disguise gets through. Containment is when any stranger is automatically placed in a glass room — an "aquarium": they walk around, "work," and are convinced they're inside the building, but the walls around them are virtual and they can never reach the valuables.
Isolation-first vs. detection-first (artifact)
Compare the two approaches on these points when you're choosing protection:
| Criterion | Isolation-first (containment) | Detection-first (EDR/antivirus) |
|---|---|---|
| Core logic | Unknown is isolated by default | Unknown is allowed until recognized as bad |
| New threat (zero-day) | Neutralized immediately — no verdict needed to protect | Depends on the quality of analysis; may slip through |
| Damage window (dwell time) | Tends to zero | Exists structurally (days, not minutes) |
| If the detector was wrong | The file was isolated anyway | The threat is running in the system |
| Load on the administrator | Isolated ≠ incident → fewer alarms | A stream of alerts; an analyst needed to triage |
| Weak spot | Trusted tools and scripts | Missing the new and the disguised |
Where containment doesn't save you
Isolation-first has the same kind of logic as detection, and it leaves its own gaps — which have to be named. Containment is excellent at covering unknown executables, but it's bypassed by the same living-off-the-land attacks — through tools and scripts that are already trusted — and by in-memory attacks, where there's no new file on disk at all. On top of that, rare or in-house software with no verdict runs inside the container at first, and that calls for rule tuning, or there's friction.
So the right answer isn't "containment instead of EDR," but layers: isolation on the devices covers unknown files and zeroes out dwell time for them, while monitoring on top (EDR + SOC) catches what operates through the trusted. Each layer covers the other's weak spot. Anyone selling a single technology as the answer to everything is being disingenuous.
A separate risk: the agent in the kernel
Power has a price. Endpoint protection runs at the operating-system kernel level — that's what gives it its power, but it also creates a systemic risk. A public example: in July 2024, a faulty automatic update from CrowdStrike brought down millions of Windows machines worldwide simultaneously. This was not an attack but a quality-control error — but the lesson is general: the deeper an agent sits in the system, the more serious the fallout when it fails. The practical conclusion for a business isn't "don't deploy protection" — it's to keep a tested backup and recovery plan as insurance against the failure of any single link. This applies to any kernel agent, including the solution we deploy — which is why we treat a tested backup as a mandatory layer, not an option, and we say so plainly.
What this means for a business without a security team
For an organization with no in-house analysts, the difference is fundamental. Detection-first generates a stream of alarms that someone has to triage — and triaging a single false positive eats minutes of skilled time you don't have. Isolation-first lifts a large part of that load: what landed in a container isn't an incident, and there are fewer alarms. Paired with SOC as a service, it answers the "but who's going to respond" question: most threats are neutralized automatically, and the rest is handled by an on-duty team. You don't need to hire your own security department to get enterprise-grade protection.
FAQ
- What is dwell time, in plain terms? It's the time a threat sits in a system unnoticed — from infection to detection. With detection-based defense it's greater than zero by nature; per industry reports, it's usually days.
- Why can an EDR miss a threat? Because it has to recognize it first. A genuinely new sample (zero-day), an attack via trusted system tools, or in-memory execution may not raise an alarm.
- What is containment (isolation-first)? An approach in which any file not proven safe is automatically launched in an isolated container and cannot harm the system until it's assigned a verdict. The damage window tends to zero as a result.
- Does containment replace antivirus and EDR? No — it's a layer on top. It covers unknown files but not attacks through trusted tools; so reliable protection is the combination of containment and monitoring.
- Is this suitable for a company with no security department? Yes, and it's especially suited to one: isolation neutralizes most threats without alarm triage, and response can be taken as a service. More on this — endpoint protection.
- Will it protect against an encryptor that isn't in any database yet? Yes — even an unknown encryptor launches in isolation and won't reach the real files. But you still need a tested backup as the last line of defense.
- If containment is so good, why isn't it in the Gartner Magic Quadrant? The Gartner categories are built around detection (AV/EDR/XDR); an approach that removes the very dependency on detection doesn't fit a ready-made category yet — one appears after the technology has proven itself. On this approach, the Xcitium platform delivers 0% breaches with a financial guarantee.