Skip to content

Endpoint Requirements

This page lists what an endpoint needs in order to run the SenseOn Universal Sensor: supported operating systems, hardware resource expectations, network connectivity, and special considerations for cloned hosts and proxied environments.

Use it to confirm that a target estate is compatible before rolling out SenseOn, to size hosts appropriately, and to share with network and security teams who need to allow-list traffic or sign off on the agent.

💡 Scope of this page: These requirements apply to hosts where you intend to deploy the SenseOn Universal Sensor agent. For hosts that cannot run the agent (network appliances, IoT devices, OT equipment, third-party SaaS systems, or hosts running unsupported operating systems), you can still bring telemetry into SenseOn by using Log Ingestion or by deploying a Network Probe. The three collection methods are complementary and can be used together within a single tenant.

💡 Looking for how it actually works? For an architectural overview of what the agent does on a host, how telemetry flows to the platform, and what controls protect that data, see How the Universal Sensor Works.

Operating Systems

  • Windows 8.1 and later desktop versions (64 bit and ARM)
  • Windows Server 2012 R2 and later server versions (64 bit and ARM)
  • Ubuntu Linux 18.04+ (64 bit)
  • CentOS/RedHat 7+ (64 bit)
  • M-Series Based macOS Catalina (10.15) or higher

Supported Linux Distributions

SenseOn ships packages for the distributions listed below. Architecture is x86_64 only on Linux (no aarch64 / ARM).

Distribution Officially supported versions Package format
Ubuntu 18.04 LTS, 20.04 LTS, 22.04 LTS, 24.04 LTS .deb
Debian Releases corresponding to the supported Ubuntu kernels .deb
Red Hat Enterprise Linux 7, 8, 9 .rpm
CentOS 7, 8 (Stream) .rpm
Rocky Linux 8, 9 .rpm
AlmaLinux 8, 9 .rpm
Amazon Linux 2 .rpm

Linux Kernel Requirements

The Universal Sensor uses eBPF for in-kernel telemetry on Linux. The kernel feature floor is:

  • Linux kernel 5.2 or later for full functionality. This is the minimum version that supports BPF CO-RE (Compile Once, Run Everywhere), which the sensor uses for portable eBPF programs across distributions.
  • Older kernels (4.x): the sensor still installs and collects process telemetry, but network telemetry collected via eBPF kprobes is unavailable.

In practice this means:

  • Ubuntu 20.04 LTS (kernel 5.4) and newer give full functionality.
  • Ubuntu 18.04 LTS (kernel 4.15 by default) gives process telemetry only unless the host has been upgraded to a Hardware Enablement (HWE) kernel of 5.2 or later.
  • RHEL / CentOS 8+ ship with kernel 4.18 in mainline but include backported eBPF support; RHEL / CentOS 9 ships with kernel 5.14.

🐧 Non-supported systems: Other Linux distributions or kernels older than 5.2 may be functional, but are not officially supported. Network telemetry requires the kernel features listed above; if those are not available, process telemetry will still be collected and the host will still appear in Digital Estate > Devices.

Operating System Feature Differences

We aim for feature parity across all our platforms whenever possible. However, due to technical constraints and the complexity of building features for different environments, simultaneous releases may not always be feasible. The table below explains the state of features across each platform.

Feature Windows macOS Linux
Network Detection and Response (NDR) Yes Yes Yes
Endpoint Detection and Response (EDR) Yes Yes Yes
Endpoint Protection (EPP) Yes Yes No
Active Response Yes Yes (Apple silicon only) Yes
Reflex Yes No No

CPU/RAM

We recommend at least 2GB of RAM for systems running SenseOn, however minimum requirements are also listed below:

Operating System Recommended RAM Minimum RAM
Windows 4GB 512mb (Server Core), 2GB (Desktop)
macOS 4GB 2GB
Ubuntu 24+ 2GB 1GB
Debian 2GB 256mb

Impact on CPU/RAM

The performance of the endpoint agent will change depending on which modules are loaded.

  • On Windows with NDR and EDR features enabled but Endpoint Protection disabled:

    • Average CPU: <0.6% (depending on device type and hardware)
    • Average memory use: ~ 90 MB

  • On Windows with NDR, EDR, and Endpoint Protection features all enabled:

    • Average CPU: <1% (depending on device type and hardware)
    • Average memory use: ~ 300 MB

High CPU utilisation: For particularly busy Servers with EPP enabled (such as file servers, or those with a large number of reads/writes), CPU utilisation can be as much as 20%, depending on workload.

💡 Turning features on or off: Product features can be turned on or off by creating a segment and changing the configuration applied to that segment.

Network Requirements

Bandwidth

28 kilobits per second (~300 MiB in 24 hours), depending on device activity and workload.

💡 Data Latency: Data is ingested into the platform in real-time. There may be a delay of no greater than tens of seconds while data is analyzed before it is presented in the user interface. This delay will not affect the instant execution of automatic actions by the EPP.

Connectivity Requirements

Endpoint sensors using the cloud-hosted analysis platform will communicate to the following domains.

💡 Specific domains: Specific domain names can be provided for your tenant if required. These can be provided by contacting support.

Domain Name Purpose
*.snson.net Endpoint agent telemetry and active response sessions. Each SenseOn deployment will call back using a random subdomain, contact support for details of your unique subdomain if required.
avmirror.snson.net Antivirus updates used by EPP. Included in wildcard above.
*.s3.amazonaws.com Uploads/Downloads during active response and crash dumps. Each Active Response session will use a unique bucket. This is not required if Active Response is not used.
seev4.s3.amazonaws.com Endpoint agent updates. Included in wildcard above

💡 IP addresses: The IP address used for endpoint agent callbacks will remain static unless the tenant's region is changed. The IP addresses at *.s3.amazonaws.com are dynamic and can only be filtered using domain names.

TLS Interception

Endpoint sensors will use Mutual TLS 1.2+ to communicate with the analysis platform. If TLS interception is used, a bypass will need to be put in place for *.snson.net.

Golden Images

The SenseOn endpoint agent generates a unique identifier (precise.uuid) on each host. This identifier is what ensures each device appears as a distinct entry in the Digital Estate > Devices view.

If you deploy SenseOn through a golden image, master template, or any other cloning workflow (including Citrix MCS/PVS, VMware Horizon, AWS AMI, or Azure image), every cloned host needs its own precise.uuid. Otherwise, multiple cloned hosts can share an identity in SenseOn and one or more devices may not appear in the Devices view.

Preparing a Golden Image

Before sealing or capturing your image, perform the following steps so that each cloned host generates its own identifier on first boot:

  1. Stop the SenseOn Seed Service on the template host. See the Proxy Configuration section below for the steps to stop the service on each platform.
  2. Delete the precise.uuid file:
    • Windows: C:\Program Files\senseon-see\precise.uuid
    • Debian / CentOS / RHEL / Ubuntu: /etc/senseon-see/precise.uuid
    • macOS (run as root): /var/senseon-see/precise.uuid
  3. Do not start the service again on the template host. Leave the service stopped so the file is not regenerated before the image is sealed.
  4. Configure your provisioning system to re-run the SenseOn installer when a new instance is built from this image (see the next section). This is the most reliable way to ensure each cloned host gets a fresh precise.uuid and registers as a distinct device.
  5. Seal or capture the image using your normal process (sysprep on Windows, your hypervisor's snapshot tool, etc.).

Re-Running the Installer on Each Cloned Instance

The recommended pattern is to keep the SenseOn agent installed in the golden image (so cloned hosts boot quickly) but re-run the SenseOn install command as a first-boot step on every cloned instance. The installer is idempotent — running it again on an already-installed host triggers a clean registration with a fresh precise.uuid and adds the host to the Digital Estate > Devices view.

The install command and installer key for your tenant are available from Settings > Universal Sensor in the SenseOn platform. Substitute your own values for <your-tenant> and <your-installer-key> in the examples below.

Use whichever first-boot mechanism your provisioning platform already supports. Examples:

Windows (Citrix MCS / PVS, VMware Horizon, generic)

Configure a startup script, scheduled task, or Group Policy startup item that runs the SenseOn install command in an elevated PowerShell session:

$env:SENSEON_INSTALLER_KEY="<your-installer-key>"; `
  iwr -useb https://<your-tenant>.senseon.io/install.ps1 | iex

For Citrix-provisioned machines, place the script in the Citrix machine catalogue's startup-script hooks or invoke it through your standard Group Policy startup-script configuration.

Windows (sysprep)

If you use sysprep, add the install command to the FirstLogonCommands (or SynchronousCommand for unattended setup) section of your unattend.xml:

<FirstLogonCommands>
  <SynchronousCommand wcm:action="add">
    <Order>1</Order>
    <CommandLine>powershell.exe -ExecutionPolicy Bypass -Command "$env:SENSEON_INSTALLER_KEY='&lt;your-installer-key&gt;'; iwr -useb https://&lt;your-tenant&gt;.senseon.io/install.ps1 | iex"</CommandLine>
    <Description>Register SenseOn agent on first boot</Description>
  </SynchronousCommand>
</FirstLogonCommands>

AWS EC2 (AMI-based instances)

Add the install command to the instance user data so it runs on first boot:

#!/bin/bash
curl -fsSL https://<your-tenant>.senseon.io/install.sh \
  | SENSEON_INSTALLER_KEY="<your-installer-key>" bash

See Deploying the SenseOn Universal Sensor on AWS EC2 for full details, including Auto Scaling launch templates.

Azure VM

Use a Custom Script Extension or cloud-init user data on the VM to run the same curl ... | bash command shown above.

Linux (cloud-init / systemd)

Add a one-shot systemd service that runs the install at first boot and then disables itself:

[Unit]
Description=SenseOn first-boot install
ConditionPathExists=!/etc/senseon-see/.first-boot-done

[Service]
Type=oneshot
Environment="SENSEON_INSTALLER_KEY=<your-installer-key>"
ExecStart=/bin/bash -c "curl -fsSL https://<your-tenant>.senseon.io/install.sh | bash"
ExecStartPost=/usr/bin/touch /etc/senseon-see/.first-boot-done

[Install]
WantedBy=multi-user.target

macOS (Jamf Pro / Kandji / generic MDM)

Use your MDM's policy mechanism to run the macOS install command on each newly enrolled device. See Deployment via Jamf Pro and Deployment with Kandji for tool-specific instructions.

Verifying a Cloned Host Has Registered

After provisioning a cloned host:

  1. Log in to SenseOn.
  2. Navigate to Digital Estate > Devices.
  3. Confirm the new host appears in the list with its expected hostname and a recent Last Seen timestamp.

This check is particularly important in VDI environments such as Citrix XenApp / XenDesktop, where many short-lived hosts are provisioned from the same image.

Citrix and VDI Deployments on Sensor v7

⚠ Re-running the installer is required on Sensor v7 Citrix deployments. A small number of Citrix XenApp hosts have been observed not registering correctly when relying on the SenseOn Seed Service to regenerate precise.uuid automatically. Configure a first-boot installer step (as described above) so that the agent re-registers cleanly on each cloned instance.

If a cloned host does not appear in Digital Estate > Devices within 30 minutes of being online, contact support@senseon.io with the affected hostname(s) and a brief description of your provisioning flow.

Proxy Configuration

The endpoint sensor supports TLS pass-through HTTPS proxy, which can be enabled by deploying a JSON file in the specified path. Configuration details are provided below.

Windows

  1. Stop the endpoint sensor service.
    1. Open Start by clicking the Windows symbol on the bottom left corner or by pressing the Windows Key on your keyboard.
    2. Search for Services (or services.msc) and click the top result to open the console.
    3. Double-click the service called senseon-seed.
    4. Click the Stop button.
    5. Confirm the service is stopped by checking the list of services.
  2. Navigate to C:\ProgramData\senseon-see\ (to see C:\ProgramData and other hidden folders go to File Explorer → View and click on Show hidden files and folders)
  3. Open or create a new file: C:\ProgramData\senseon-see\proxy.json
  4. Write the following line into the file and change the host and port fields accordingly: 
    {"proxy_host": "127.0.0.1", "proxy_port": 8118}
  5. Save the file.
  6. Start the endpoint sensor service.
    1. Open Start by clicking the Windows symbol on the bottom left corner or by pressing the Windows Key on your keyboard.
    2. Search for Services (or services.msc) and click the top result to open the console.
    3. Double-click the service called senseon-seed.
    4. Click the Start button.
    5. Confirm the service is stopped by checking the list of services.

Linux

  1. Stop the endpoint sensor service using the command systemctl stop senseon-seed
  2. Navigate to /var/senseon-see
  3. Open or create a new file: /var/senseon-see/proxy.json
  4. Write the following into the file and change the host and port fields accordingly: 
    {"proxy_host": "127.0.0.1", "proxy_port": 8118}
  5. Save the file.
  6. Start the endpoint sensor service using the command systemctl start senseon-seed

macOS

  1. Stop the endpoint sensor service using the command systemctl stop senseon-seed.
  2. Navigate to /var/senseon-see
  3. Open or create a new file: /var/senseon-see/proxy.json
  4. Write the following into the file and change the host and port fields accordingly: 
    {"proxy_host": "127.0.0.1", "proxy_port": 8118}
  5. Save the file.
  6. Start the endpoint sensor service using the command systemctl start senseon-seed.