Choose, install and validate Sophos Linux Sensor

Sophos Linux Sensor (SLS) collects Linux runtime events and processes them with detection content to generate alerts or configured responses. It can integrate with existing logging and alerting infrastructure. SLS is a separate sensor: it is neither Sophos Protection for Linux (SPL), its XDR Sensor, nor an SPL runtime detection policy.

For an initial pilot, verify the platform and entitlement, select the appropriate installation method and deploy both sensor and content. Then follow a test alert to the actual intended recipient. A running service alone is insufficient. This guide describes the direct systemd host deployment; container and Kubernetes installations use a different deployment method.

Confirm licensing and operating model first

The Sophos instructions checked on 27 October 2026 list Sophos XDR Powered by Secureworks (Server), Sophos MDR (Server) or Sophos MDR Plus (Server) as qualifying products for SLS access. Evaluation licences do not qualify. An arbitrary endpoint licence or the mere existence of a Linux server is not evidence of entitlement.

SLS is licensed per device. However, according to Sophos, its instances appear neither in the Fusion server list nor in the Devices view or its licence count. Maintain a separate inventory of installed sensors. Sophos Fusion (formerly Sophos Central) can receive SLS detection details and alerts, but does not manage the sensor. A missing SLS server entry therefore does not indicate failed SPL registration.

For a conventional managed server agent with the required SPL components, use Sophos Protection for Linux. Assess SLS separately for immutable images or specialised container platforms; mentioning such a use case does not approve every distribution or kernel/runtime combination.

Prepare the platform and pilot

At the review date, the current SLS release notes require at least 2 GB free disk space, 2 GB free memory, and x86_64 or ARM64. ARM64 requires kernel 5.3 or later. The specific distribution, its current minor release and running kernel must also match the tested platform list. Another distribution’s minimum kernel is not universal approval. Legacy platforms have separate support conditions.

Before the pilot, record the host’s role, distribution, architecture, kernel, existing protection software, workload profile and intended alert recipient. Direct host installation requires root/package management permissions, a suitable systemd setup and the Linux debug subsystem required by SLS to be available or approved. Do not weaken a hardened system pre-emptively just to let an installation script proceed.

Sophos provides a dedicated Helm method for Kubernetes; Docker, CRI-O and containerd also have specific instructions. Registry access, host visibility, permissions, the content image and runtime must be checked. Do not paste a package command from this host example unchanged into a sensor container.

Obtain the registry token in the correct tenant

SLS uses a separate Package Registry API Token beginning with SLS-. It is not the same as the short-lived OAuth access token or an API identity’s client secret.

The current SLS procedure requires a Super Admin in the customer’s Fusion Admin dashboard, rather than a Partner or Enterprise dashboard. Under Global Settings > Administration > API Credentials Management > Add Credential, create the required identity with Service Principal Super Admin. The responsible owner must approve this extensive vendor requirement beforehand; do not adopt it as the default role for arbitrary API projects. Store the client ID and the client secret, which is shown only once, securely.

Use the API credentials and OAuth process to obtain the bearer token and identify the unique customer tenant ID through whoami/v1. For this process, idType must confirm the customer tenant. A partner identifier is unsuitable. Then create an access token by sending a POST to /accounts/v1/access-tokens on the global Sophos API host, with bearer authentication, X-Tenant-ID and this JSON body:

{
  "label": "SLS Pilot",
  "type": "sophosLinuxSensor"
}

label is a freely chosen administrative name; type is the fixed API value. Use the response’s token field for registry access, rather than the object ID. Choose an optional expiresAt according to the access plan; Sophos states that a date beyond the server licence expiry is reduced to that expiry. A sample with a distant date does not establish permanent entitlement.

Check the HTTP client’s status and response content. Tokens and secrets must not enter shell history, proxy diagnostics, tickets or screenshots. Resolve tenant, entitlement or token errors first; do not change protection settings or permissions tenant-wide speculatively.

Install on a direct host through package management

For this procedure, first provision SLS registry access through approved package management. Sophos documents packages.sophos.com/sophos-linux-sensor/release/ and the sophos-linux-sensor-archive-keyring.gpg key. Obtain it through the authenticated vendor path and store it at /etc/sophos-linux-sensor.gpg. Before use, verify its provenance and current fingerprint through the approved trust chain. gpg --list-packets only shows a readable key packet; that alone does not prove trusted provenance.

Supported Debian-based hosts

Add the source to a suitable .list file under /etc/apt/sources.list.d/:

deb [signed-by=/etc/sophos-linux-sensor.gpg] https://packages.sophos.com/sophos-linux-sensor/release/ stable main

Store the associated registry token in an access-restricted .conf file under /etc/apt/auth.conf.d/:

machine packages.sophos.com login <SLS-REGISTRY-TOKEN>

Replace the placeholder with the registry token actually received. Only the necessary privileged package management processes should be able to read the file; do not also put the token in the repository URL. After checking signature trust, the source and file permissions, run the following during the approved change window:

sudo apt-get update
sudo apt-get install sophoslinuxsensor-systemd sophoslinuxcontent

Supported RPM-based hosts

The RPM method uses a separate .repo file under /etc/yum.repos.d/. The section and display names below are freely chosen examples; the URL, signature check and key path match the documented registry method:

[sls]
name=Sophos Linux Sensor
baseurl=https://<SLS-REGISTRY-TOKEN>@packages.sophos.com/sophos-linux-sensor/release/
gpgcheck=1
enabled=1
gpgkey=file:///etc/sophos-linux-sensor.gpg

Replace the placeholder with the received registry token. Restrict access to the file containing it. Its URL must not be exposed in diagnostic logs, tickets or screenshots. Do not replace existing distribution repositories or disable signature checks. The display name does not approve a particular distribution or version.

With the source configured correctly, Sophos specifies these packages:

sudo yum install sophoslinuxsensor-systemd sophoslinuxcontent

Use only the package method appropriate to the actually supported distribution. Both sensor and content are required. A Zero policies configured message means detection acceptance has failed even if the process is running. Old version numbers in vendor sample output are not current installation requirements.

Configure the tenant and alert output

Set customer_id in /etc/sophos/runtimedetections.yaml to the previously verified tenant ID. Update existing YAML settings selectively rather than overwriting the whole file with a sample. Check the purpose and data authorisation of telemetry transmission and alert destinations before starting. Sophos documents alert output to stdout by default; this does not automatically connect every desired recipient.

For a controlled initial check, record the actual destination: local journal, an existing logging system or the explicitly configured Sophos recipient. Configure credentials, destination and format for that output. Registering a token is not proof of working alert forwarding.

For the direct systemd host method, then start and check:

sudo systemctl start sophoslinuxsensor
sudo systemctl status sophoslinuxsensor
sudo journalctl -u sophoslinuxsensor

For startup failures, first check the platform, packages, effective YAML configuration and permissions identified in the journal. The vendor installation instructions describe the necessary Linux capabilities; do not substitute blanket privileged container access or an unchecked setcap on arbitrary files.

Validate detection through to the recipient

With default content installed and the sensor running, generate the documented test alert on an approved pilot. Check syntax against the installed version first: one passage in the installation guide shows -test-alert, while the dedicated testing guide uses --test-alert. Use the following command only if the installed version supports this spelling:

sophoslinuxsensor --test-alert

This deliberately generates an event. Coordinate it with the receiving team rather than running an unannounced production test. Expect Alert Tester at the configured destination. Host, time and recipient must match; successful command execution or a local log entry alone does not confirm remote delivery.

If this syntax is unsupported or the expected alert does not arrive, do not substitute real malicious code or an uncontrolled attack.

Acceptance records at least the sensor/content versions, effective rules, successful startup, test alert and actual receipt. This test confirms that path, not every detection, workload situation or entitlement to an MDR investigation. Compare further pilot load and application operation with the baseline.

Rules, updates and operational issues

The default content package is at /var/lib/sophos/content/runtimedetections-content.yaml and is overwritten during updates. Put customisations in the designated /etc/sophos/runtimedetections-rules.yaml, rather than directly in the vendor file. According to the detection documentation, Sophos supports unmodified default content; clarify separate assistance for modified or custom rules.

Core and Enhanced detections differ in depth and workload impact. More content is not automatically better for every server workload without a pilot. Update sensor and content through the appropriate package or container rollout, then revalidate; a one-off installation check does not replace update operations.

If alerts are missing, investigate content, loaded rules, the event, output and forwarding separately. Collect SLS support data safely explains deeper logs and diagnostic packages, including the separate Helm, Docker and host methods. Prepare a planned removal using the recorded baseline, remaining protection requirements and the applicable vendor uninstallation procedure. Do not delete services or credentials belonging to other hosts.