AnonymousSign in
Start from a neutral baseline and add what matters to you. Criteria are labeled by source — the platform baseline is architecture-neutral; buyer-contributed criteria are shown separately.
This evaluation is stored in your browser only. We cannot see it, and it is not tied to any account. Save it to a link or create an account to keep it across devices — you can export it at any time either way.
Signing up adds sharing with your team, sending this as an RFP to vendors, and private document sharing. Nothing above is taken away, and nothing here is sent anywhere until you choose to.
Breadth of deception types matters because attackers who learn to spot one pattern (e.g., generic honeypot VMs) will avoid it — look for a genuinely varied technique portfolio, not just network-level decoy hosts.
Unconvincing decoys get ignored by real attackers and quickly get abandoned operationally; look for automated environment-matching, not a generic decoy template requiring heavy manual customization to be credible.
Deception technology's core value proposition is near-zero false positives (no legitimate reason to touch a decoy) — a vendor unable to state a real, low false-positive figure is undermining the category's main selling point.
Look for automated response integration, not just an alert requiring manual SOC triage — deception's value is high-confidence, fast-response detection of lateral movement already in progress.
No buyer-contributed criteria yet
Verified buyers can suggest criteria (anonymized before pooling).
Modern attack paths increasingly go through cloud/identity, not just the network — look for explicit cloud/identity deception coverage, not a product still framed around on-prem network segments only.
Look for evidence of red-team validation against the vendor's own decoys — sophisticated attackers actively fingerprint for known deception products, and an easily-detected decoy provides zero value.
Look for centralized, low-per-decoy-overhead management — a deception program that requires significant per-asset manual upkeep won't scale beyond a small pilot.
A real attacker interacting with a decoy is a rare, high-fidelity intelligence source — look for automated feedback of captured TTPs/IOCs into the broader security stack, not intelligence that stays siloed in the deception console.
Look for transparent, predictable scaling economics for a genuinely large deployment; per-decoy pricing that becomes expensive at real enterprise scale is worth probing directly.
Ask for clarity on this distinction — a triggered decoy is high-confidence evidence of a real compromise (legitimate users should never touch it), so the response should be commensurately serious, not just a routine alert.
This is a genuinely under-discussed but real consideration for deception technology — a mature vendor should have specific guidance rather than treating this as entirely the customer's own legal problem to solve unprompted.
Trend-over-time reporting is a distinct capability from individual incident alerts — confirm this exists as a maintained, exportable report.
Ask for a specific, named, pre-built playbook example rather than a generic 'SOAR-integrated' claim — deception-triggered events benefit from purpose-built automated response given their high-confidence nature.
Ask for an honest per-environment coverage breakdown; uneven deception coverage across environments is a common real gap a vendor should disclose rather than obscure.
OT-specific deception requires genuinely different technical content than generic IT decoys — a vendor should clarify whether real OT-aware deception exists or whether coverage is IT-only.
Customer-specific red-team validation is a stronger, more relevant test of decoy realism than vendor-internal-only testing against generic attacker behavior — ask for concrete support for this kind of exercise.