An alert with nothing left to judge
Every other detection source produces a probability an analyst has to assess. What a source costs to triage matters as much as what it finds.
Every detection source you buy carries two prices. One of them is on the quote. The other is paid in the minutes an analyst spends deciding whether an alert meant anything, and it is paid again for every alert the source produces. A comparison sheet holds the price and the detection rate. The queue lives with the rest. One class of source has an unusual second price, and that difference is worth a budget argument of its own.
What a minute of triage actually costs
The unit of cost in a security team is not the alert. It is the decision the alert forces. In the USENIX Security 2022 study of SOC practitioners by Alahmadi, Axon and Martinovic of the University of Oxford, a participant told the researchers that his team knows 99 percent of the alarms it generates are false positives, and that they still have to look at them. The second half of that sentence is the expensive half.
The Oxford authors, who surveyed twenty practitioners and interviewed twenty one, then take that number apart. Most of what analysts call a false positive, they report, is what one participant named a benign trigger, a true alarm raised by legitimate behaviour the organisation has decided to ignore. Nothing is broken, so nothing can be tuned away. It returns tomorrow at the same cost, and the study ties that work to alarm burnout and then to desensitisation.
The answer being sold to this today is an AI triage layer, an assistant that reads the queue and tells an analyst where to start. Take it seriously, because for a probabilistic source it lowers the cost of sorting. What it does not lower is the cost of being wrong, since a cheaper queue of probabilities is still a queue of probabilities.
A source that produces a fact rather than a probability
An endpoint agent scores a process tree against what processes normally do, a network sensor scores a flow against a baseline built from your own traffic, and a SIEM correlates the two into a probability wearing a severity label. An analyst converts that into a yes or a no using context the tool never had.
A decoy removes the step by construction. No account is entitled to it, no service depends on it, no backup job touches it, and nothing in production has a reason to resolve its name. Nothing legitimate touches it, so an interaction is not evidence about an intrusion. It is the intrusion, and what is left is investigation rather than validation.
That produces an odd result. A triage layer improves the sorting of events that need judgement, and a decoy event needs none, so there is nothing in it to improve. The source that gains least from automated triage is the one that already costs nothing to triage, which argues for running both rather than choosing between them.
Decoys do raise events that are not attackers, and those come from your own side, a scanner sweeping a range or a backup agent pushed across the estate. Each is a configuration fact with a permanent fix.
The trade you are actually making
A decoy reports only when an attacker touches it. Someone who arrives on a file server with a valid credential and takes what they came for may never touch one. Deception is a high precision and low recall source, and endpoint detection sits at the other end of the same trade. The question is not which finds more. It is which of your constraints is binding. If the queue closes fewer tickets than it opens, recall adds work to that constraint and precision adds capacity to it.
Recall is the part you can influence, since a decoy is reached only if the intruder's path crosses it. Automated reconnaissance widens that path, because a sweep that enumerates a subnet has no idea which hosts an employee would have no reason to open. Placement and upkeep are the questions to put to any vendor here.
- How does a decoy reach a segment nobody will re-image, and what does it leave on a production host
- What stops your own scanner, backup agent and discovery job from producing a hundred events on day one
- How does a decoy stay credible once the naming convention and patch level around it change
- What leaves the platform when a decoy is touched, and does the SIEM receive an event or a case
- Who acts on it at three in the morning, and what are they authorised to disconnect
Budget is the other half, and deception has a disadvantage there. NIST carries decoys in its control catalogue as SC-26, and NIST Special Publication 800-53B, which allocates controls to the low, moderate and high impact baselines, puts SC-26 in none of them. No audit will ask you for it, so it wins on the queue argument or not at all. Inside the category, Thinkst Canary sits at the small and hand placed end, while Attivo, now part of SentinelOne, and Acalvio generate decoys at scale.
Where the choice is narrower
In an operational technology network the ordinary detection routes are closed, and a public standard says so. NIST Special Publication 800-82r3, the Guide to Operational Technology Security, calls these systems resource constrained and states that there may not be computing resources available on OT components to retrofit them with current security capabilities. That closes the agent route. The same document tells OT owners to exercise extreme caution with active scanning, since active scans may cause device instability or interfere with the device process state.
In its section on deception technology, the same guide explains why this method survives the constraint. Because decoys do not actively interact with other network components, it says, deception technologies can support malicious activity monitoring and detection without jeopardising the controlled process. A decoy is a separate host on the segment. It adds no software to a PLC and no load to a controller, and if it falls over mid shift, nothing stops, because nothing depends on it. An agent that falls over on an HMI is an outage with a safety report behind it.
The same shape appears in point of sale estates and wherever no mirror port is coming.
What deception does not do
It prevents nothing. By the time a decoy reports, somebody is inside with a working credential or a working exploit, and the event describes a failure that has already happened. The honest claim is narrower. It shortens the distance between the intrusion and the moment somebody knows about it, and it does that without adding to the queue.
It is also not a product you install and leave. MITRE Engage, the adversary engagement framework published by MITRE, organises the work across three phases, Prepare, Operate and Understand, and states that deception is a process, not a fire-and-forget technology stack. What Engage puts in the preparation phase is the part no licence covers, the operational objective, the gating criteria for how far an intruder is allowed to go, and the threat model the decoys are built to be interesting to. Credibility decays as the estate around a decoy moves on, so budget the upkeep next to the licence.
The product behind this argument
In this portfolio that is GuardPot, which carries decoy systems, decoy accounts, decoy services, attacker behaviour analysis and intelligence output in one product rather than across a suite, and places them across network segments, cloud environments and endpoints with nothing installed on production machines. The published specification is short, and we have not added to it anything the vendor does not publish itself, so the way to settle the argument above is a pilot in one segment with a scan window inside it.