Resources

Threat intelligence, research, and everything you need to understand preemptive security.

All resources

Press Enter to search or Esc to close

Buyer Guide

Network Deception Vendors: How to Choose

A vendor-neutral set of evaluation criteria, with what each vendor documents publicly.

Last reviewed: October 2026. This guide is vendor-neutral by design: it lists the questions to ask any vendor and summarizes what each vendor documents publicly (sources accessed 2026-10-09). PacketViper is one of the options and is labeled as such. Where a fact is not in public material, this guide says “Not publicly documented”.

What “network deception” covers

Network deception means placing believable decoys, lures or credentials where an attacker will find them, so that any interaction is a high-confidence signal. Products differ in three ways that matter more than the decoy catalogue: where the decoys live, whether the system can act on a touch itself, and whether the product also changes the real network surface.

Three broad models appear in the market. Decoy-first detection places or projects decoys and sends alerts (and, through integrations, containment requests). Endpoint moving target defense changes what an attacker finds inside a host, such as process memory. Network AMTD with inline enforcement changes what an attacker can map on the network and enforces in the packet path. Many environments benefit from more than one.

Seven criteria to evaluate

1. Decoy realism

A decoy that fails a basic fingerprint check teaches the attacker to ignore it.

Ask how operating system, service banner and timing characteristics are kept consistent across a decoy.
Ask for a demonstration against the scanners and tools your red team already uses.
Ask what interaction depth is supported, from a listening port to a full emulated service.

2. Coverage

Deception only helps where an attacker will actually look.

Ask which segments, sites, cloud accounts and identity stores can be covered, and how coverage is deployed at scale.
Ask whether unused address and port space (dark space) is monitored, or only the decoys themselves.
Ask how coverage is maintained as the real network changes.

3. Agent versus agentless

Agents give host-level visibility; agentless approaches protect devices that cannot run software.

Ask exactly what is installed on production assets, and what happens on assets that cannot host software.
In OT, ask whether anything touches a PLC, RTU or HMI at all.
Ask what the agent adds to your attack surface and patching workload.

4. Inline response versus alert-only

The gap between a touch and a containment action is the window an attacker uses.

Ask whether the product can act on first contact itself or depends on a SIEM, SOAR or firewall integration to do so.
Ask what the failure mode is if an inline device fails (fail-open or fail-closed) and how that is tested.
Ask for a measured time from first contact to containment, and how it was measured.

5. OT support

OT environments tolerate little active scanning and no unexpected traffic.

Ask which industrial protocols are emulated or understood, and how they are documented.
Ask whether the product is passive or active in the OT network and what evidence supports that.
Ask whether it keeps working at a site that loses its link to central management.

6. Operational overhead

A deception program fails if nobody can run it.

Ask for the realistic time to first useful alert, and the weekly effort to keep it healthy.
Ask how decoys are refreshed and who owns that task.
Ask what the alert volume looks like in a network like yours.

7. Integration

Deception output is only useful if it reaches the tools your team already works in.

Ask which SIEM, SOAR, firewall, NAC and EDR integrations are native and which are custom work.
Ask whether integrations are one-way (send alerts) or two-way (receive context and push actions).
Ask what APIs exist for your own automation.

What each vendor documents publicly

The table summarizes public statements only, as of 2026-10-09. It is a starting point for questions, not a verdict. Each row links to a longer, fully sourced comparison.

VendorPrimary modelAgent or agentlessResponse at first contactOT protocols named publiclyDetail
Acalvio ShadowPlexProjected, autonomous deceptionAgentless (per Acalvio)Not inline; isolation through integrationsModbus, BACnet, EtherNet/IP, S7; DNP3 on a separate pageComparison
Fortinet FortiDeceptorDecoys, lures and honeytokensAgentless (per Fortinet)Built-in quarantine plus Security Fabric integrationsBACnet, CAN Bus, DNP3, ENIP, IEC104, Modbus, MOXA, PROFINET, S7COMM, ScadaBR, Triconex, Guardian AST, KamstrupComparison
SentinelOne Singularity HologramNetwork decoys; identity deception on the Singularity agentDecoys: hardware or virtual. Identity: agentAlerts; containment workflows between identity and endpoint.ICS-SCADA decoys named; protocols Not publicly documentedComparison
Thinkst CanaryCanary devices and CanarytokensNo endpoint agent describedAlertsModbus service; three SCADA personalitiesComparison
MorphisecEndpoint memory moving target defenseAgentHost-level preventionNot publicly documentedComparison
PacketViperNetwork AMTD with deception and inline enforcementAgentless network platform; optional endpoint AMTD AgentInline, in the packet pathModbus, DNP3, BACnet, S7COMMDeception and AMTD

Vendor statements in this table are drawn from the sources listed at the end of this page[1][2][3][4][5].

Choosing by situation

You want a quick, low-maintenance tripwire: a decoy-first product with alerts may be enough. Thinkst Canary is built around that model.
You are standardized on a vendor’s security stack: start with that vendor’s deception product (for example Fortinet or SentinelOne) and test it against the criteria above.
You need broad, detection-first coverage with nothing in the data path: a projected, agentless platform such as Acalvio ShadowPlex fits that requirement.
You are defending endpoints against memory-based attacks: endpoint moving target defense such as Morphisec addresses that layer.
You need inline response, OT coverage without agents, and a surface that keeps changing: that is the case PacketViper is built for.

How to run a fair proof of concept

Write the success criteria before the test: what must be detected, what must be contained, and in how long.
Use the same scanners, scripts and red-team scenarios against every candidate.
Record time from first contact to containment, and what a person had to do in between.
Test the failure modes: loss of management connectivity, a failed device, a mistaken block.
Ask each vendor to document what they did not test.

For the longer, sourced comparisons, see PacketViper vs Acalvio ShadowPlex, PacketViper vs Fortinet FortiDeceptor, PacketViper vs SentinelOne Singularity Hologram, PacketViper vs Thinkst Canary, PacketViper vs Morphisec. For the network versus endpoint question, see AMTD Vendors: Network vs Endpoint Moving Target Defense.

Sources

  1. Acalvio, ShadowPlex for OT/ICS Security solution brief (PDF, (c) 2024) Accessed 2026-10-09.
  2. Fortinet, FortiDeceptor data sheet (PDF, FDC-DAT-R23-20260713, dated July 13, 2026) Accessed 2026-10-09.
  3. SentinelOne, Singularity Hologram data sheet (PDF, code S1-DS_SINGULARITY_HOLOGRAM-05032022) Accessed 2026-10-09.
  4. Thinkst Canary, “Which personalities and services does my Canary support?” Accessed 2026-10-09.
  5. Morphisec, Automated Moving Target Defense Accessed 2026-10-09.
What is network deception technology?

It places believable decoys, lures or credentials on a network so that any interaction is a high-confidence signal of reconnaissance or intrusion. Products differ in where decoys live and whether the system can act on a touch itself.

Do I need inline enforcement for deception?

Not always. Detection-first products send alerts and rely on integrations for containment. Inline enforcement shortens the time between a touch and a containment action, and matters most where there is no analyst available at the moment of contact.

Should deception be agentless?

For devices that cannot run software, such as PLCs and RTUs, agentless is a requirement. For endpoints, agents can add host-level visibility. Many environments use both.

How do I compare deception vendors fairly?

Define success criteria first, run the same scenarios against each candidate, measure time from first contact to containment, and test failure modes such as loss of management connectivity.

Test inline AMTD against your own criteria

Request a proof of concept and measure time from first contact to containment in your environment.