Reports

Blocked devices

What did we stop, and where? Block events grouped by device fingerprint over the chosen range: how many blocks, on how many endpoints, first and last seen. Sorted by block count, so the device causing the most policy activity is the first row.

Device inventory

What USB hardware exists in this fleet? The same fingerprint grouping across all actions. This is the allowlist-building report and the payoff for running discovery mode: instead of reconstructing an inventory from an event stream by eye, you get one row per distinct device with allow, block and audit counts, how many endpoints saw it, and whether it is built-in hardware, so soldered-in fingerprint readers and cameras stay separate from things people actually plugged in. Each row links to that device’s full history.

Device history

Tell me everything about this drive. Search everything your workspace has seen in the last 365 days by name, VID, PID or serial, or click any device name on the events page or in a report. You get a single-device page: identity header, totals, which device groups it belongs to and who added it when, every endpoint it has touched, and its complete event timeline.

Three investigations this is built for: a drive turns up somewhere it should not be and you need every endpoint it has touched; someone asks you to allow a device and you want its history before deciding; an assessor asks you to show a specific device was never used on a particular machine, within the retention window, which the page states.

Silent endpoints

Which agents have stopped reporting? Endpoints with zero events inside the quiet window. This is a safety report: an agent whose event path died looks identical to a machine nobody plugs anything into. It shows the last check-in time next to the last event time, because the row that matters most is the endpoint polling for policy on schedule while producing no events. That pattern can mean the event path is broken, and it gets a badge.

Endpoints enrolled more recently than the window are not listed. A machine enrolled yesterday cannot have been silent for a week, and listing it would be a claim the data does not support.

Tamper and pauses

Did anyone turn this off, when, and on whose machine? One row per endpoint and user with counts of tamper signals, protection-pause lifecycle events, and devices admitted while enforcement was suspended, over the chosen range.

This is the report that makes self-protection and pause protection defensible: a pause is acceptable in a security product precisely because it is time-boxed, permission-gated and fully logged, and this is where that log becomes reviewable. Tamper signals carry no logged-in user, because they are detected rather than requested, so they appear under "no user recorded" for their endpoint.

Full export

Everything the events page can show, as one CSV: explicit from and to range with presets, endpoint-group scope, action and source filters, and a row count computed with the same query the export runs, shown before the download starts. Retention is 365 days, so everything means the last year, and the file says so if it was capped for any reason.

Honesty rules all reports follow

• Every report is bounded and always states the true total alongside, such as "showing top 50 of 214", on screen and inside the CSV. A capped file carries an explicit marker row, so you never discover a cap by counting rows
• Reports cover at most the 365-day retention window and never imply completeness beyond what is stored
• CSV cells are hardened against spreadsheet formula injection, because device names come off the device itself and are attacker-chosen by construction

Compliance mapping

The reports back several NIST 800-171 controls directly: blocked devices for 3.8.7 and 3.14.7, and the report set plus exports for 3.3.3 audit review.