Bitdefender XDR Sensor Network Add-On

What is included in the Bitdefender XDR Sensor Network Add-On?

Network Sensor appliance – Virtual appliance that analyses traffic mirrored from a switch port.
Lateral movement detection – Flags attackers spreading between systems inside your network.
Exfiltration and scanning – Detects data leaving the network, port scans, brute force.
Unmanaged device visibility – Covers IoT and devices without an installed agent.
Active network scanning – Finds open ports, running applications and known CVEs.
Important – Add-on only, needs GravityZone Business Security Enterprise underneath.

What are the main benefits of the Bitdefender XDR Sensor Network Add-On?

The Bitdefender XDR Sensor Network Add-On is a licence extension for GravityZone XDR that feeds network traffic telemetry into the same correlation engine that already processes endpoint events. It runs as a virtual appliance and is configured and monitored centrally from the GravityZone Control Center, together with every other sensor.

Central console – Configured and monitored from the same GravityZone Control Center.
Correlated incidents – Network alerts join endpoint events in one attack timeline.
Blind spot coverage – Sees printers, cameras and legacy systems agents cannot reach.
Faster triage – Analysts see the network path instead of reconstructing it.
Guided integration – The sensor is connected through step-by-step console setup.
Multi-tenant management – Service providers configure all sensors from one console.

Best antivirus? Why Windows Defender alone is not enough
Why built-in protection leaves detection gaps that a layered security setup has to close.

Which company size is the Bitdefender XDR Sensor Network Add-On suitable for?

The deciding factor is not headcount but whether your switches can mirror traffic and whether someone actually reviews the resulting incidents. A company with a flat network, unmanaged switches and no one on call for alerts will pay for telemetry nobody reads.

Does the Bitdefender XDR Sensor Network Add-On meet the requirements of Swiss cybersecurity legislation?

The reporting obligation under the revised Information Security Act applies to operators of critical infrastructure, for example energy and water suppliers, transport companies and cantonal and municipal administrations, not to every Swiss company. Since 1 April 2025 these operators must report a cyberattack to the Federal Office for Cybersecurity (BACS) within 24 hours of discovery, which means the clock starts at detection and not at containment. The Network Sensor supports that deadline in one concrete way: it timestamps lateral movement, port scans and exfiltration attempts and feeds them into the GravityZone incident timeline, so the questions of when an attack started and which systems it reached can be answered inside the reporting window. It does not cover the rest of the obligation, because it does not decide whether an incident is reportable, does not produce a BACS notification, does not see traffic that is never mirrored to it, and does not replace an internal escalation process with named responsibilities. This text is a product description and not legal advice, so whether your organisation falls under the reporting obligation should be clarified with your own legal advisers.

Does the Bitdefender XDR Sensor Network Add-On meet the requirements of European cybersecurity legislation?

No product makes a company compliant with the NIS 2 Directive, because the directive addresses organisational risk management and management accountability rather than software features. NIS 2 requires entities in scope to implement measures covering risk analysis, incident handling, business continuity and crisis management, supply chain security, network and information system security, and procedures to test whether those measures actually work. The Network Sensor contributes to two of these areas: it detects attacks visible in network traffic, and it supplies the correlated evidence that incident handling needs to show how an intrusion moved through the environment. It contributes nothing to business continuity, backup and restore, supplier assessment, staff training or governance, and it provides no workflow for the notification duties the directive imposes. Entities in scope should treat it as one detection source inside a wider management system, not as a compliance measure in its own right.

Data loss is expensive: How backups help you avoid outages
How backup and restore planning covers the business continuity side that a detection sensor cannot.

Does the Bitdefender XDR Sensor Network Add-On help with security questionnaires from large customers?

Yes, but only for the network detection block of a questionnaire. It answers items such as whether internal traffic is monitored for lateral movement, whether data exfiltration is detected, whether devices without a security agent are visible, whether network detections are correlated with endpoint events, and whether an incident timeline can be produced on request. It answers none of the items on patch levels, disk encryption, backup and restore testing, multi-factor authentication, privileged access management, awareness training, penetration testing or supplier assessment, and it generates no evidence for them, so a questionnaire that fails on those points will still fail after this purchase. Where those gaps appear, extending the same GravityZone family with the matching modules, for example patch management or encryption management, is usually cheaper and faster to evidence than adding a second vendor, because the exports come from one console instead of two.

What is the difference between the XDR Network Sensor and the other XDR sensor add-ons?

The decisive difference is the data source: the Network Sensor is the only sensor that reads raw network traffic, which makes it the only one that sees devices with no agent and no cloud account behind them. The identity, cloud and productivity sensors read event logs from platforms you already operate, so they connect in minutes without touching the network, while the Network Sensor needs a virtual appliance and a mirrored switch port. Each sensor category is licensed as its own add-on next to the GravityZone base licence, so buying one does not include the others. All of them feed the same correlation engine, which is why sensors are usually added in the order of where the blind spot actually is.

Which limitations should you know before buying?

The sensor analyses only the traffic that is actually mirrored to it, so a switch without a configured mirror or SPAN port produces no detections at all, and traffic between two virtual machines on the same host stays invisible unless that traffic is mirrored as well. It is a detection and visibility component rather than an inline blocking device, because blocking network attacks on the machine itself remains the job of Network Attack Defense inside the endpoint agent. The add-on is licensed separately from GravityZone Business Security Enterprise, so a company running only endpoint protection cannot switch it on without the XDR base underneath. The most common follow-up cost is not the licence but the network side: adding a managed switch, a mirror port or a second appliance for a remote site so that the segments you care about are actually visible.

Frequently asked questions about the Bitdefender XDR Sensor Network Add-On

Where is the Network Sensor configured and monitored?

Sensors are managed on the Sensors Management page under Configuration in the GravityZone Control Center, where the integration status of each sensor is shown. GravityZone also sends integration status notifications by email, with the status in the subject line, so a sensor that has stopped delivering data can be spotted without opening the console.

Does the Network Sensor require an agent on the monitored devices?

No, and that is the point of it. The appliance reads mirrored traffic, so printers, cameras, building controllers and legacy machines that cannot run an endpoint agent still generate detections, while managed endpoints gain a second view of the same event that the correlation engine can match against their process activity.