Investigate AP6 Wi-Fi telemetry with Live Discover

Live Discover lets you interactively investigate Wi-Fi telemetry uploaded from AP6 Access Points to the Sophos Data Lake. The direct path is Threat Analysis Center > Live Discover > WiFi. Run a built-in query over a short period first; only move to custom SQL after that query returns data.

Check availability first: The general Live Discover documentation requires Sophos EDR, XDR, or MDR. The AP6 page doesn’t define an unambiguous AP6-specific entitlement combination. Don’t infer a specific AP6 license from this guide. Check whether WiFi, Data Lake > NSG WiFi, and nsg_wifi_data are available in your tenant, and resolve uncertainty with Sophos or your partner.

Quick workflow: open WiFi, select a built-in Data Lake query, set no more than 30 days, click Run Query, and only then use Designer Mode and Schema > NSG WiFi > nsg_wifi_data if needed.

What the query sees—and what it doesn’t

The AP6 management and telemetry path supplies records to Sophos Fusion (formerly Sophos Central) and the Data Lake. A Data Lake query reads those uploaded records. It doesn’t query a wireless client directly, and it doesn’t change an SSID, radio setting, or the forwarding of Wi-Fi user traffic.

nsg_wifi_data can include AP identity and firmware, client MAC and IP addresses, host and user names, connection status, site, wireless network name, band, RSSI, and log messages. This is operational metadata telemetry, not evidence that Live Discover captures the contents of Wi-Fi packets. Keep the management/telemetry path separate from the Wi-Fi data path when troubleshooting: a query that returns no results doesn’t prove a Wi-Fi outage, and working Wi-Fi doesn’t prove that telemetry reached the Data Lake.

Start safely with a built-in query

In Sophos Fusion, open Threat Analysis Center > Live Discover > WiFi.
Select a relevant built-in query. Designer Mode isn’t required for this.
Under Select a Time Period, begin with the past 24 hours or 7 days, for example. One query can cover no more than 30 days. Use separate, non-overlapping windows for a longer investigation.
Click Run Query, then compare the returned rows, time range, and expected AP6 or client.
Only after this baseline works, turn on Designer Mode. When editing or creating a query, select Data Lake as the Source and verify the tenant’s fields under Schema > NSG WiFi > nsg_wifi_data.

This sequence distinguishes a data or permission issue from custom SQL syntax and avoids unnecessarily broad queries.

Conservative custom queries

These examples use only fields in the documented AP6 schema. Also constrain the period with the UI time selector. Start with a small window and a LIMIT; use MAC addresses and other identifiers only for an authorized investigation.

Connection history for a known pilot client

SELECT timestamp, device_name, device_model, client_mac, client_ip,
       client_hostname, client_conn_status, wireless_network_name,
       wireless_band, wireless_rssi
FROM nsg_wifi_data
WHERE client_mac = '02:00:00:00:00:01'
ORDER BY timestamp DESC
LIMIT 200;

02:00:00:00:00:01 is a locally administered example only. Replace it with the MAC address currently used by the client. Private or randomized MAC addresses can change. Sophos doesn’t document fixed values for client_conn_status, so inspect the returned vocabulary before filtering on it.

Review radio observations

SELECT timestamp, device_name, client_mac, wireless_network_name,
       wireless_band, wireless_rssi, client_bandwidth
FROM nsg_wifi_data
WHERE wireless_rssi IS NOT NULL
ORDER BY timestamp DESC
LIMIT 200;

RSSI is a telemetry snapshot. Don’t use one value as sole proof of a radio issue; examine the trend, AP, band, and client movement together.

Inspect AP6 log telemetry

SELECT timestamp, device_name, log_severity, log_component,
       log_subtype, log_message
FROM nsg_wifi_data
WHERE log_message IS NOT NULL
ORDER BY timestamp DESC
LIMIT 200;

Don’t assume undocumented severity values. Inspect the returned vocabulary first, then add a narrower filter to a copy of the query.

Privacy and reliable evidence

MAC and IP addresses, host and user names, SSIDs, sites, and serial numbers may identify people or devices. Query only required fields over the shortest useful period, limit access to authorized roles, and handle exports under your deletion and incident procedures. Anonymize identifiers in tickets and screenshots unless correlation requires them.

Reliable evidence records the selected period, query version, expected AP6 or pilot client, and correlating fields such as timestamp, device_name, and client_mac. Reconcile timestamps with the Central tenant’s time zone and the endpoint event time. Here, timestamp is the collection or event time, while ingestion_timestamp is when the record entered the Data Lake. A much later ingestion value indicates delayed upload, not a correspondingly late event.

Troubleshoot and stop safely

WiFi or the schema is missing

Check the tenant, admin role, and product availability first. Don’t try to resolve the uncertain AP6 entitlement by changing the access point or SSID. Give Sophos or your partner a screenshot of the missing menu and non-sensitive tenant details.

A built-in query returns no rows

Compare the time period, expected AP6, and known client activity. Then check whether NSG WiFi > nsg_wifi_data exists under Schema. Because Data Lake queries read uploaded telemetry, check Wi-Fi reachability and AP6 management status separately. If data remains absent despite known activity, preserve the window, query name, AP6 identity, and time for Sophos Support.

Only the custom SQL fails

Return to the unchanged built-in query. If it works, copy field names from the schema, reduce the query to a few columns, and add filters one at a time. Don’t work around the problem with guessed tables, status values, or REST/API automation.

Stop or reverse

These queries are read-only, so there is no Wi-Fi configuration change to reverse. Stop safely by not launching another query and leaving Designer Mode. There is no separate switch described here for disabling AP6 telemetry. Don’t improvise by changing AP6, SSID, or uplink settings; if data supply must stop, confirm the documented tenant-specific route with Sophos. Remove any exported results separately under your privacy policy.