Interpret the Sophos Fusion NDR Dashboard correctly

The NDR Dashboard in Sophos Fusion answers three initial questions: Which devices can NDR see, how much data is associated with each protocol, and how many NDR Flow Detections were displayed during the selected period? It is a read-only activity overview for the fleet, not an inventory source or an investigation console.

The direct path is My Products > NDR. For an unbiased first view, remove old filters with Clear All, check the time range, and then read the three charts together. A single number is not enough to assess security or health.

What belongs on the dashboard—and what does not

The dashboard has precisely this purpose:

NDR Devices shows the number of managed and unmanaged devices.
NDR Protocols shows uploaded and downloaded data volumes in MB.
NDR Flow Detections shows the number of malicious behaviors detected.
The time range, display type, and device filters narrow this overview.

Other tasks begin outside this dashboard. Appliance Manager is responsible for the health and operation of the NDR appliance. The Detections view and Threat Analysis Center are used for specialist triage and response. The local Investigation Console is intended for detailed work with sensor data. The dashboard does not replace any of these workspaces, and changes in them are not covered by this guide.

Choose the appropriate time range

Four preset time ranges are available at the top of the dashboard: Last hour, 24 hours, 7 days, and 30 days. The default is 24 hours. Custom lets you select a date range in the calendar.

Choose the range based on the question:

Last hour is suitable for a current anomaly and a quick check following known activity.
24 hours is a sensible starting point for daily review.
7 days shows recurring daily patterns and differences between working days and quieter days more clearly.
30 days helps identify a broad operational baseline.
Custom limits the view to a known event or maintenance window.

A long period provides more context but can make a brief spike look less prominent. When something stands out, narrow the broad overview to 24 hours or Last hour. Conversely, an empty hour does not prove there was no activity during the preceding days.

For every handover, record the selected range, visible date boundaries, and filters used. This is the only way to ensure that the next person examines the same scope. Do not infer an undisplayed time zone or second-level boundary from the calendar selection.

Read the three charts together

NDR Devices: visibility, not a complete inventory

NDR Devices divides the devices shown in the selected scope into managed and unmanaged. The count is useful as a trend: an unexpected shift or a substantial decrease requires an explanation.

It does not, however, answer whether every expected device was monitored continuously. Even a plausible device count proves neither complete SPAN/TAP coverage nor the health of every endpoint. The approved asset or CMDB list remains authoritative for inventory reconciliation. Identify unknown devices by IP address, MAC address, and hostname before classifying them as unauthorized.

NDR Protocols: observed volume, not a utilization measurement

NDR Protocols shows the uploaded and downloaded data volume in MB for each protocol. This makes dominant protocols, directional differences, and changes over time visible. A backup, software rollout, or scheduled data transfer can explain a large but legitimate change.

The chart is not a substitute for interface counters or bandwidth measurement. High volume alone is not a detection; low volume is not proof of benign traffic. It shows what NDR processes within the selected scope and assigns to the chart. It cannot establish whether network mirroring is complete.

NDR Flow Detections: a triage signal, not a closed incident

NDR Flow Detections counts detections of malicious behavior. An increase prioritizes review, but by itself it says neither how many separate incidents exist nor whether a response has already occurred. Multiple detections can belong to the same investigation context; specialist assessment therefore takes place in the appropriate detection or case view.

Only this chart can also be displayed as a World map. The map adds geographic context to detections, but it does not provide reliable attribution of an attacker or proof of an internal device’s physical location. Compare the map, line, bar, and list views as needed to check counts and trends.

Switch the display type deliberately

At the top right, a report can be displayed as a Line graph, Bar chart, or List. World map is additionally available for NDR Flow Detections.

Line graph quickly reveals the trend and timing of a change.
Bar chart makes discrete values or categories easier to compare.
List is suitable when labels and displayed values matter more than the shape of a trend.
World map adds geographic context to Flow Detections.

Changing the display should only alter the view of the same selected time range and filter scope. If two views appear to tell different stories, check the time range and active filters again before interpreting either view in isolation.

Filter by device

Use Filters to narrow the charts by IP Address, MAC Address, or Hostname:

Open Filters.
Enter the known value in IP Address, MAC Address, or Hostname.
Select Apply.
Check the time range and all three charts again.
Use Clear All to return to the unfiltered control view.

For a reproducible search, start with a single identifier copied from a reliable source. This makes it clear which value narrowed the result. If the result is empty, do not immediately add several more conditions: first select Clear All, check the unfiltered view, and then test the IP address, MAC address, and hostname individually. Hostnames can change, IP addresses can be reassigned, and a device may have been active outside the selected period.

Sophos does not document general guarantees for wildcards, partial matches, or logical operators for these filters. Do not assume such search rules.

Validate the conclusion and data path

A reliable check separates dashboard visibility, the data path, and detection functionality:

Establish a control view: Select Clear All and set 24 hours. Check whether the fleet activity expected from known test traffic is visible in NDR Devices and/or NDR Protocols. Also check and document the NDR Flow Detections value, even when it is zero.
Use a known device: Choose a device that demonstrably generated network traffic during the period. Filter individually by its IP address, MAC address, or hostname from a reliable inventory source.
Cross-check the scope: Switch to the List or chart view. The time range and filters must remain unchanged.
Remove the filter: Use Clear All to verify that the fleet view returns. This distinguishes an empty filter match from a generally empty dashboard.
Compare expectations: Check the device count against inventory changes, protocol volume against planned transfers, and Flow Detections against the appropriate detection view.

This check demonstrates that expected activity can be found on the dashboard. It is not an end-to-end detection test. Even a green appliance status would only be a health indicator, not proof of complete mirroring coverage or functioning detections. A planned detection test requires an approved test procedure and must not be improvised.

Interpret empty or misleading views

All charts are empty

First select Clear All and extend a short period to 24 hours or 7 days. If the view remains empty, check whether NDR is configured for the tenant and whether the appliance is processing data. Appliance status, network mirroring, and the data path then belong with the responsible operations or network team. Repeatedly changing the chart type will not resolve the problem.

Flow Detections is zero

A value of zero for NDR Flow Detections can be legitimate when no malicious behavior was detected in the selected scope. If the expected devices or protocol volumes are visible at the same time, the dashboard is not empty; the zero value alone therefore does not indicate an appliance or data-path fault. However, it proves neither that the observed traffic was benign nor that detection functionality works end to end. If that specific function must be validated, an approved test and its evaluation belong in the appropriate detection view or Threat Analysis Center.

Only the device filter returns nothing

The value may not have been observed during the period, may have changed, or may not match the input. Check unfiltered data, extend the time range, and use a second known identifier on its own. An empty hostname filter does not prove that the device does not exist.

Device count falls while protocol volume remains plausible

This can indicate changed device classification, a filter, a different time range, or limited visibility. It is not sufficient reason to record devices as removed. Compare against inventory changes and the state of the data source.

Protocol volume rises while Flow Detections remain unchanged

More data volume is not automatically malicious. Check scheduled backups, updates, and data transfers. Conversely, the absence of additional Flow Detections does not mean all transferred content was safe; the dashboard only shows the existing NDR detections.

The World map appears empty or concentrated on one country

First view the same Flow Detections as a List or chart. The map is an alternative display, and its geographic context must not be treated as proof of origin. The count, affected devices, and detection details take priority for triage.

A 30-day trend appears quiet

Narrow the range to 24 hours, Last hour, or a suitable Custom window. A brief deviation may be inconspicuous in a long-range display. The broad period remains useful for the baseline but does not replace the detailed view of the event window.

Who owns the next step?

The next action depends on the open question, not the chart where it first appeared:

NDR operations owners: maintain the dashboard baseline, document time ranges and filters, and identify deviations in fleet activity.
Appliance and network owners: investigate missing or unexpectedly low data, appliance health, and SPAN/TAP and data paths. This work takes place in Appliance Manager and the network infrastructure, not on the dashboard.
Asset or endpoint owners: reconcile unknown or incorrectly assigned devices against inventory, DHCP/DNS, and device owners.
SOC/XDR analysts: assess Flow Detections in the appropriate detection or case view, correlate evidence, and decide on a response.
Investigation Console owners: perform detailed, locally authorized sensor-data analysis when required. The dashboard filter is not a substitute for this investigation.

A clean handover includes at least the tenant, observation time, selected range, active filters, affected charts, visible deviation, and checks already performed. Screenshots or exported notes must not contain unnecessary customer data. This gives the next owner the relevant context without conflating dashboard interpretation with triage, appliance operations, or local hunting.