What is included in Bitdefender XDR Sensor for MDR (Add-On) Network?

Network sensor appliance – A virtual appliance that inspects a mirrored copy of traffic.
Lateral movement detection – Identifies attackers moving from one internal system to another.
Data exfiltration detection – Spots transfers of data to destinations outside your organisation.
Scanning and brute force – Detects port scanning and network-originated brute force attempts.
Network vulnerability scanner – Finds open ports, running services and known CVE findings.
Important – It runs passively on a traffic copy and blocks nothing.

What are the main benefits of Bitdefender XDR Sensor for MDR (Add-On) Network?

Bitdefender XDR Sensor for MDR (Add-On) Network is a licence that adds the GravityZone XDR Network Sensor to an existing Bitdefender MDR subscription, so the analysts running the service also see network traffic and not only endpoint activity. It is deployed as a virtual appliance and managed centrally in the GravityZone Control Center under Configuration and Sensors Management, where it also carries the technical name Network Sensor Virtual Appliance, or NSVA.

Visibility beyond agents – Covers printers, IoT and any device without an agent.
Richer incident context – Network events enrich the extended incidents your analysts already receive.
Faster attack scoping – Shows which other systems an attacker touched inside the network.
No endpoint impact – Runs on its own virtual machine, not on protected endpoints.
Multiple hypervisors – Prebuilt images exist for vSphere, Hyper-V, Proxmox and OVHcloud.
Multi-subnet monitoring – One appliance can watch several subnets without overlapping address ranges.

Best antivirus? Why Windows Defender alone is not enough
Explains where built-in operating system protection stops and why additional detection layers are added on top of it.

Which company size is Bitdefender XDR Sensor for MDR (Add-On) Network suitable for?

Company size matters less here than two other things: whether you already run Bitdefender MDR, and whether your switches can deliver a mirrored copy of traffic. Note that the Swiss reporting obligation follows sector rather than headcount, which is why that row reads the same across all three columns.

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

The reporting obligation in the revised Information Security Act applies to operators of critical infrastructure, which includes energy and water suppliers, healthcare providers, transport operators and larger cantonal and communal administrations, and it does not apply to a company simply because it has reached a certain headcount. Affected organisations must report a cyberattack to the Federal Office for Cybersecurity (BACS) within 24 hours of discovery, which means the practical problem is not the report form but noticing the attack in time and being able to describe its scope. The network sensor helps directly with that second part, because lateral movement and outbound transfers to unusual destinations are exactly the evidence you need in order to say which systems were affected and whether data left the network. It does not cover the reporting process itself, it produces no report template for BACS, and it cannot tell you whether your organisation falls under the obligation. This description is general information about product scope and is not legal advice, so verify your own reporting duties with a qualified adviser.

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

No product creates NIS 2 compliance, because the directive addresses the organisation and its processes rather than any single tool. NIS 2 requires categories of measure such as risk analysis and security policies, incident handling, business continuity and crisis management, supply chain security, vulnerability handling and disclosure, and procedures to assess whether the measures actually work. This sensor supports incident handling by supplying network evidence for detection and investigation, and it supports vulnerability handling in a limited way through its scan for open ports, running services and known CVEs. It contributes nothing to business continuity, backup and restore, supply chain security, staff training, cryptography or access control, and it does not on its own demonstrate that your measures are effective, so the remaining categories have to be covered by other products and by documented internal processes.

Does Bitdefender XDR Sensor for MDR (Add-On) Network help with security questionnaires from large customers?

Partly, and in a narrow band of the questionnaire. It gives you a defensible answer to the items asking whether network traffic is monitored for intrusion, whether lateral movement and unusual outbound transfers are detected, whether unmanaged devices on the network are visible, and whether monitoring runs continuously rather than on a schedule. Because it is licensed to the MDR service, it also strengthens the answer to items asking who watches the alerts outside office hours. It answers nothing about encryption of laptops and removable media, patch status of workstations and servers, multi-factor authentication, backup and restore testing, mailbox and phishing protection, data classification, or access reviews and offboarding. Those items are the ones that usually cause a follow-up purchase, and the cheaper route to closing them is normally to move up within the same GravityZone family, because full disk encryption, patch management and mobile coverage are all sold as parts of that platform and are managed from the console you already use, whereas mixing a second vendor adds another agent, another console and a second set of exclusions to maintain.

Which limitations should you know before buying?

The most consequential limitation is that the appliance runs in TAP mode on a copied stream of traffic, so it observes and reports but never blocks a connection, and any actual containment still comes from the endpoint agents or from the analysts running the MDR service. It explicitly does not support SCADA or other OT protocols, which rules it out as an industrial network monitor, and Wi-Fi network adapters are not supported for the monitoring interface. Your switching hardware must be able to deliver SPAN, RSPAN or mirrored traffic, a single appliance can only monitor subnets whose IP ranges do not overlap, and Bitdefender recommends one appliance per subnet for best results, so a segmented network can mean several appliances rather than one. The vulnerability scanner reports its CVE findings in GravityZone only for managed endpoints, so unmanaged devices are visible as traffic sources but not as scanned assets. Note also that this SKU is the variant licensed for the MDR service and requires an active MDR subscription; the same sensor is sold separately for self-managed GravityZone XDR, and Bitdefender's own MDR terms state that service delivery may be limited in some geographic regions, which is worth confirming for your location before you order.

Data loss is expensive: How backups help you avoid outages
Covers why detection alone does not restore operations and how backup planning limits the cost of an incident.

Frequently asked questions about Bitdefender XDR Sensor for MDR (Add-On) Network

Does this sensor replace a firewall or an intrusion prevention system?

No. It sits outside the traffic path and reads a mirrored copy, so it has no ability to drop or reject a connection. It is a detection and investigation source that runs alongside your firewall, not a substitute for it.

Do I need one appliance for every subnet?

Not strictly. One appliance can monitor several subnets through a single mirroring session, provided their IP address ranges do not overlap. Bitdefender still recommends one appliance per subnet for optimal results, so budget accordingly if your network is heavily segmented.

Where do the network detections appear?

The sensor pre-filters events and sends metadata and detections to the GravityZone Security Analytics engine, where they enrich the extended incidents you already see. You can isolate them in the console under Incidents and Search using the query other.sensor_name:network.