Keeping the sensor up to date

In practice the sensor does not update itself. Upgrading a machine means running the installer on it again, and this article is about doing that deliberately across a fleet instead of discovering the situation eighteen months from now.

What exists and what does not

Being specific matters here, because partly built is exactly the state that produces a confident answer from a salesperson and a support ticket from you.

• The server side is built and verified. The release catalogue, the signing and verification path, the per-tenant channel and pin, the rollout cohort and the rollback deadline all exist, and the update route is mounted and answers an authenticated sensor.
• The sensor side is built and inert. The agent has an update loop that polls every four hours, and it is genuinely capable of the whole job — verify the release signature, download, replace the binary, restart. But its first action is to check for the Ed25519 public keys that are supposed to be compiled into it, and no build script supplies them, so it returns before starting. That is fail-closed — a sensor with no keys cannot be talked into applying an unsigned update — and it means no sensor asks.
• There is a deliberate off switch too, for when the keys do arrive. The same guard also honours ZQ_DISABLE_AUTO_UPDATE=1 in the sensor's environment. So a deployment that wants upgrades to stay a manual, scheduled act will have a supported way to say so, rather than depending on the keys staying absent.
• No configuration turns it on. There is no console control and no flag that supplies the missing keys; that is a change to how the binary is built. The environment variable above only works in the other direction.

The practical position is therefore unchanged from when this article was first written, even though the reason for it is not: every sensor upgrade requires re-running an MSI, a .deb or a .pkg through your own deployment tooling.

Working out which version you are running

A sensor reports its version when it enrols, and that value is stored against the endpoint. You can see it in two places: the Endpoints list in the console, and the sensors dataset when threat hunting, which is the easier of the two if you want to count machines by version rather than read a list.

The current published release is 1.6.0, for both Windows and Linux — the 2026-09-20/21 release was the first to build, sign and publish both platforms from one source tree in one pass, closing a gap where the two had previously drifted apart to different version numbers. One value is worth recognising regardless of version: a sensor reporting 0.0.0-dev is running a binary that was built without a version stamp — a development build, not something from our release pipeline. If you see it on a production machine, someone has installed the wrong artefact.

Upgrading, per platform

In every case, fetch the newer artefact from the same published location you installed from, verify it against the SHA256SUMS.txt beside it, and install it over the top.

Windows

Install the new MSI over the old one, with the same silent flags you used originally. The installer carries a fixed upgrade code and a major-upgrade rule that removes the old service cleanly before the new files land, so you do not uninstall first. You do not need to pass an enrolment token again. Downgrades are refused, with A newer version of Qorionix XDR Sensor is already installed.

Linux

sudo apt-get install -y ./qorionix-sensor.deb or sudo dnf install -y ./qorionix-sensor.rpm with the newer file. The config file is marked as one the package manager must not replace, so the machine's credential survives, and the post-install step restarts the unit for you.

macOS

Not available. There is no distributable package to install in the first place — see Installing the sensor on macOS.

An upgrade does not require re-enrolment on any platform. The machine's credential lives in its config file, which both package formats preserve, and the host fingerprint the platform identifies the machine by is stable across a reinstall. Even if a re-enrolment does happen — because someone passed a token, or because the config was lost — the existing endpoint is updated in place rather than duplicated. You will not end up with two rows for one laptop.

Planning a fleet upgrade

The mechanics are ordinary software deployment. The part that catches people out is verification, because nothing in the product will tell you a machine was missed.

1. 1

   Count what you have before you change anything

   Group your endpoints by version and write the numbers down. If the total does not match the number of machines you believe are enrolled, resolve that first — an endpoint that is already stale will not take the upgrade and will quietly stay behind.

2. 2

   Fetch and verify the artefacts once, centrally

   Download the new MSI or packages, check them against SHA256SUMS.txt, and on Windows confirm the signature — right-click, Properties, Digital Signatures. Stage the verified copies in your own distribution point so every machine gets bytes you have already checked. The Linux packages are unsigned, which makes the hash check the only integrity control you have there.

3. 3

   Upgrade a pilot ring of five to ten machines

   Pick machines you can look at directly and that span your real variety — a laptop, a server, one of each distribution. Upgrade them, then confirm each one reports the new version in the endpoint list and has a recent last-seen time. Both, not one.

4. 4

   Leave the pilot alone for a working day

   You are watching for a machine that upgraded, checked in once, and then went quiet, which is the failure mode a five-minute test misses. The endpoint list is where that shows up.

5. 5

   Roll out in batches, not all at once

   Batch by site, department or maintenance window. Every machine restarts its sensor as part of the upgrade, so a whole-fleet upgrade means a whole-fleet blind spot at the same moment. Staggering keeps most of the estate reporting while the rest is restarting.

6. 6

   Chase the stragglers by version, not by memory

   After each batch, filter the endpoint list by version again. Whatever is still on the old number is your list: usually laptops that were off, machines on holiday leave, and one server everybody had forgotten was in scope.

The gap during an upgrade

While the service is stopped the machine reports nothing, and events from that window are lost rather than queued. There is a second, smaller effect worth knowing: after any restart, the first process snapshot and the first file scan are treated as a baseline and produce no events. That is deliberate — without it, every restart would report every already-running process as though it had just been launched, which is exactly the kind of noise that makes people stop reading alerts. The practical consequence is that a process which started during the upgrade window is visible in the next snapshot as something already running, not as an execution event.

An upgrade window of a minute or two per machine is not a meaningful risk. A fleet-wide simultaneous restart during the working day is a bigger one, which is the real argument for batching.

Sensor rollout rings do not change this yet

What you are not missing by staying on an older sensor

Worth saying, because the absence of auto-update sounds worse than it usually is in practice. The analysis half of the product lives on the platform, not on the endpoint: the behavioural rules, the attack-technique coverage, the process-tree reconstruction, the threat-intelligence feeds and the investigation logic all run server-side, against the telemetry your existing sensors already send. Those improve without anybody touching an endpoint.

What a sensor upgrade changes is the collection and response half — new event types, new fields, fixes to a platform collector, new response commands. Those are the changes worth planning a rollout for, and the release notes will say when one is in the box.

What to do next

1. The endpoint list and endpoint health — the view you will verify every rollout against.
2. Installing the sensor on Windows — the same command you will re-run, with the flags explained.
3. Installing the sensor on Linux — including what the package manager preserves across an upgrade.
4. How to get help — if a batch of machines will not take an upgrade, send us the version counts and the messages from the journal or event log.