The Darktrace Threat Visualizer — What You See and How It's Deployed

① The Threat Visualizer — what analysts actually see and do

The Threat Visualizer is Darktrace's main investigation UI — a browser-based, real-time, often 3D graphical view of your whole network: every device, the connections between them, and where anomalies are happening right now. It is where analysts live, not a back-end component you forget about.

From the map you can click into any device and see its event log and its learned pattern of life: the peers it normally talks to, the ports, the volumes and the timing. Against that context an anomaly is obvious, not just a raw log line.

From the map down to the packet

When behaviour crosses a Darktrace model, the Visualizer surfaces a model breach. You can open it and drill down — from the high-level topology, to the device, to the specific connection, all the way to packet/connection-level detail — so you can prove exactly what happened instead of guessing.

② Deployment — a master appliance on a passive copy of traffic

Here is the deployment fact that surprises people: Darktrace is passive and out-of-band. The master appliance does not sit in the traffic path. Instead it ingests a copy of traffic from a switch SPAN/mirror port or a hardware network TAP.

Because it only ever sees a copy, it adds no inline latency and cannot drop or break production traffic — the deliberate contrast with an inline IPS or firewall that sits in the path and is a potential choke point and single point of failure.

One brain, three form factors

The master appliance comes as a physical appliance, a virtual appliance, or cloud-hosted — you choose the form factor to suit the environment, and the analytics and Threat Visualizer are identical across all three. The catch to remember: passive means it only sees what is fed to it, so a SPAN/TAP that misses a segment leaves that traffic invisible.

③ Scaling coverage — probes, cSensors, osSensors (and on-prem data)

One master can't physically tap every site, so coverage is extended. For a branch or remote location with no link back to a central SPAN port, a probe captures the local traffic and forwards it to the master — so one analytics core covers many sites.

Two sensor types fill the rest of the gaps. cSensors (cloud sensors) extend visibility into cloud and virtual environments where there is no physical SPAN port. osSensors (host/endpoint sensors) sit on individual hosts — servers and laptops — for device-level visibility, which is how you cover remote workers whose traffic never crosses your network.

Your data can stay on-prem

For privacy and compliance, the master and its learning can remain on-premises: the AI learns locally from your own environment rather than shipping raw traffic out. All of these feeds — SPAN/TAP, probes, cSensors, osSensors — drive the same Self-Learning AI and show up in the same Threat Visualizer.

④ Sizing, placement, integrations — and the pitfalls

You size a Darktrace deployment by throughput (bandwidth) and number of devices — not by guesswork. Then you place SPAN sources, TAPs, probes and sensors so you actually capture the traffic that matters: both the east-west (internal, host-to-host) traffic where lateral movement hides and the egress (outbound) traffic where C2 and exfiltration show up.

Downstream, the deployment feeds Cyber AI Analyst (automated investigation) and Autonomous Response (containment), and integrations export detections to SIEM/SOAR/EDR so it slots into your existing SOC.

The pitfalls that cause 'why didn't it alert?'

Three classics: a SPAN/TAP that captures the wrong segments (the big one — usually mirroring only the internet uplink and missing east-west, so lateral movement is invisible); under-sizing for the real throughput/device count; and not deploying os/cSensors so cloud and remote users are uncovered.