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.comare 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
Each SenseOn endpoint agent is tied to the host it was installed on by an identity established at install time. When you clone a host (Citrix MCS / PVS, VMware Horizon, AWS AMI, Azure image, or any other golden-image workflow), every cloned host needs its own SenseOn identity — otherwise the clones will collide in Digital Estate > Devices and you may see hosts go missing.
The simplest reliable way to handle this is to leave SenseOn off the golden image and run the install command on first boot of each cloned instance.
Recommended pattern
- Do not install SenseOn on the golden image / template. Build the image with your normal application stack, but leave the SenseOn agent off.
- Configure your provisioning system to run the SenseOn install command on first boot. The install command is available in Settings > Universal Sensor. Each clone runs the installer once and registers as a distinct device.
- Seal or capture the image using your normal process.
This avoids any per-file deletion or identity reset on the template — the agent is freshly installed on each clone, so identities can't be inherited from the image.
Running the install command on first boot
The install command and installer key for your tenant are available from Settings > Universal Sensor. 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='<your-installer-key>'; iwr -useb https://<your-tenant>.senseon.io/install.ps1 | iex"</CommandLine>
<Description>Install 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:
- Log in to SenseOn.
- Navigate to Digital Estate > Devices.
- 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. If a host has not appeared within 30 minutes of being online, contact support@senseon.io with the affected hostname(s) and a brief description of your provisioning flow.
If you must pre-install on the golden image
If your environment cannot reach SenseOn's install-script URL on first boot — for example air-gapped subnets or strict egress policies that take effect before your first-boot script runs — pre-installing on the golden image is still possible, but requires more care. Contact support@senseon.io and we will walk you through the steps needed to reset the agent's identity at clone time.
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
- Stop the endpoint sensor service.
- Open
Startby clicking the Windows symbol on the bottom left corner or by pressing the Windows Key on your keyboard. - Search for
Services(orservices.msc) and click the top result to open the console. - Double-click the service called
senseon-seed. - Click the
Stopbutton. - Confirm the service is stopped by checking the list of services.
- Open
- Navigate to
C:\ProgramData\senseon-see\(to seeC:\ProgramDataand other hidden folders go to File Explorer → View and click onShow hidden files and folders) - Open or create a new file:
C:\ProgramData\senseon-see\proxy.json - Write the following line into the file and change the host and port fields accordingly:
{"proxy_host": "127.0.0.1", "proxy_port": 8118} - Save the file.
- Start the endpoint sensor service.
- Open
Startby clicking the Windows symbol on the bottom left corner or by pressing the Windows Key on your keyboard. - Search for
Services(orservices.msc) and click the top result to open the console. - Double-click the service called
senseon-seed. - Click the
Startbutton. - Confirm the service is stopped by checking the list of services.
- Open
Linux
- Stop the endpoint sensor service using the command
systemctl stop senseon-seed - Navigate to
/var/senseon-see - Open or create a new file:
/var/senseon-see/proxy.json - Write the following into the file and change the host and port fields accordingly:
{"proxy_host": "127.0.0.1", "proxy_port": 8118} - Save the file.
- Start the endpoint sensor service using the command
systemctl start senseon-seed
macOS
- Stop the endpoint sensor service using the command
systemctl stop senseon-seed. - Navigate to
/var/senseon-see - Open or create a new file:
/var/senseon-see/proxy.json - Write the following into the file and change the host and port fields accordingly:
{"proxy_host": "127.0.0.1", "proxy_port": 8118} - Save the file.
- Start the endpoint sensor service using the command
systemctl start senseon-seed.