Skip to main content

Devices

The Devices page (Dashboard > Devices) is the fleet view of every enrolled browser in your organization: which browsers are protected, when each one last checked in, which user it belongs to, and which other browser extensions are installed alongside Surface Security.

In Surface Security, a device is an enrolled browser — a specific browser (Chrome, Edge, Firefox, or Safari) on a specific machine where the Surface extension has been installed and enrolled. One employee typically has more than one device: Chrome on their laptop and Edge on the same laptop count as two devices, both linked to the same user.

Screenshot

[SCREENSHOT PLACEHOLDER: Devices page with the status filter dropdown open, showing rows with hostname or browser-on-OS names, linked users, status chips, and Last Seen values]

How it works​

Enrollment. A device appears here the first time its extension enrolls. There are several enrollment paths — an SSO magic link, an MDM-pushed managed configuration, a manual enrollment token, or the optional native companion app — described in the Extension Deployment guide. Whichever path is used, the result is the same device record.

Heartbeats and Last Seen. Once enrolled, the extension sends a lightweight heartbeat roughly every minute while the browser is running. The heartbeat carries health information (browser and OS version, extension version, and the hostname if configured — see below) and drives the Last Seen timestamp. Last Seen is therefore a proxy for "the browser was open and protected", not for the machine merely being powered on.

Status. A device's status chip is derived from its last heartbeat:

StatusMeaning
activeSeen within the last 24 hours
staleLast seen between 1 and 7 days ago
offlineNot seen for more than 7 days (or never)
pendingEnrolled but not yet reporting
revokedAccess explicitly revoked by an administrator

Using the page​

The toolbar has a status dropdown (All Statuses, Active, Stale, Offline, Revoked, Pending) for filtering the fleet. Table columns:

  • Device — the OS hostname when reported, otherwise "<browser> on <OS>"; click through to the detail page.
  • User — the enrolled user, linking to their profile.
  • Status — the chip described above.
  • Last Seen — relative time of the last heartbeat.
  • Extension — the installed Surface extension version, useful for spotting outdated installs after a release.

Above the table, a certificate widget warns when device certificates are expiring within the next 14 days, listing the affected devices so you can plan renewal before those devices lose connectivity.

Device detail​

Clicking a device opens Device Details with:

  • Device Information — Device ID, Hostname (or "Not reported"), browser and version, operating system and version, extension version, and the device fingerprint.
  • Activity — registration date, Last Seen, and current status.
  • Registered User — the linked user, with a shortcut to their profile.
  • Other Devices for this User — the user's sibling devices (their other browsers), each with its own status and Last Seen.
  • Installed Extensions — every other browser extension detected in this browser, its version, whether it is Whitelisted or Unwhitelisted against your extension allowlist, and whether it is disabled. Rows click through to the Extension Monitoring section for fleet-wide context on that extension.

Header actions:

  • Silence Stale Alerts — stops future stale-device alerts for this specific device while keeping it fully monitored. Use it for known-intermittent devices such as a kiosk or a rarely-used loaner laptop.
  • Revoke Device — cuts the extension off from the server. A written reason (minimum 3 characters) is required and recorded in the audit log, for example "Employee offboarding - ticket HR-4123".
  • Remove — permanently deletes the device record. Historical event data is preserved.
Screenshot

[SCREENSHOT PLACEHOLDER: Device detail page showing the Device Information and Activity cards, the Registered User card, and the Installed Extensions list with one Unwhitelisted badge]

Hostname visibility​

Because the extension runs inside the browser sandbox, it cannot read the operating-system hostname on its own. If you want devices listed by their real machine names (for example LAPTOP-7F3K2) instead of "Chrome on Windows", push a deviceHostname value to the extension through your enterprise browser policy (the same managed-configuration mechanism used for enrollment settings — see Extension Deployment).

The extension includes that value on every heartbeat, and the device list and detail page display it. This works for all enrollment paths and survives machine renames, since the value is re-read from policy on each heartbeat.

One practical note per platform: the policy value must contain the resolved hostname for each machine. On Windows, deploy it via a mechanism that expands the computer name at deployment time (for example Group Policy Preferences or a deployment script) — a literal placeholder string will be sent as-is. On macOS and Linux, resolve the hostname per machine in your deployment script. If the value is absent, the device simply shows "Not reported"; nothing else is affected. Deployments that use the native companion app get the hostname automatically at enrollment.

Stale device alerts​

A device that stops checking in is a coverage gap: the user may have uninstalled the extension, switched browsers, or the machine may be lost. Surface Security raises escalating alerts for inactive devices:

  • 7 days without a heartbeat — low severity alert
  • 14 days — medium severity
  • 21 days — high severity

These appear alongside your other alerts (see Alerts) so they flow into your normal triage and any SIEM forwarding.

Two controls tune this behavior:

  • Per device — the Silence Stale Alerts button on the device detail page suppresses future stale alerts for that one device.
  • Tenant-wide — Settings > General > Disable Stale Device Alerts turns off inactivity alerts for the whole tenant. Devices are still tracked and their status chips still update; only the alerts are suppressed.

Worked example: offboarding an employee​

An employee's last day is Friday. To close out their browser coverage:

  1. Open their profile from Dashboard > Users and note their devices, or filter the Devices page by their name via the User column links.
  2. Open each device and click Revoke Device, entering the offboarding ticket reference as the reason. The extension on those browsers can no longer communicate with the server, and the action is audit-logged.
  3. If the hardware is returned and reimaged, later Remove the device records to keep the fleet list clean — historical events are retained.
  4. Finally, deactivate or delete the user on the Users page.

If instead an employee goes on a two-week leave, expect a stale alert at day 7 — either acknowledge it, or click Silence Stale Alerts on their device beforehand if the absence is planned.

Troubleshooting​

A device shows "Not reported" for Hostname. The deviceHostname managed-policy value is not set (or not resolved) for that machine. See Hostname visibility above. Self-installed extensions without any enterprise policy never report a hostname.

The same laptop appears twice. Each browser is its own device. Chrome and Edge on one machine are two rows — check "Other Devices for this User" on the detail page to see them grouped. A genuinely duplicated record (for example after a browser profile reset) can be cleaned up with Remove.

A device is "offline" but the user is clearly working. The user may be working in a browser without the extension, or in a new browser profile where the extension is not enrolled. Treat offline devices for active users as a coverage gap worth chasing.

Can a revoked device re-enroll? Revocation blocks the existing enrollment. A user can go through enrollment again (subject to your enrollment controls), which creates a fresh device record — revoke is for cutting off a specific installation, not for banning a person.