Sensor 1.7.0: install and verification, platform by platform

This article is the one place that explains why you see a security warning during sensor install and how to confirm you are actually installing a genuine Qorionix build, rather than repeating the step-by-step install commands — those live in the platform-specific articles this one cross-links to. Read this once before your first rollout; the step-by-step articles assume you already understand the warnings below.

Why the sensor's signing situation needs explaining at all

Sensor 1.6.0 completed a full rebrand from the product's earlier name to Qorionix — package names, install paths, service names, systemd units, the launchd label and the environment-variable prefix all changed — and closed a real signing gap that existed before it. None of the three platforms is signed the way a mainstream commercial installer usually is, and each platform's situation is different enough that it is worth being specific rather than saying "signed" or "unsigned" as if that settled it. None of this changed again in 1.7.0: the rebrand landed once, at 1.6.0, and stayed.

Windows: what "self-signed" means for you

Both the MSI and the standalone exe are signed with a certificate generated for this purpose — subject CN=Qorionix Sensor (self-signed) — rather than one issued by a public certificate authority. That means Windows genuinely cannot show the installer as coming from a trusted publisher: Get-AuthenticodeSignature on the file reports Status = UnknownError, with the reason "a certificate chain processed, but terminated in a root certificate which is not trusted." That is expected and correct for a self-signed chain — it is not evidence of tampering, and it will not change no matter how many times you re-download the same genuine file.

What it does mean is that Windows' own trust chain cannot do the verification work for you, the way it would for a certificate issued by a public CA. The generated install command does not rely on Windows trusting the certificate at all — it separately checks the file's SHA-256 against the published release manifest, and the signer's certificate thumbprint against the one the console has pinned. Both together catch substitution or tampering just as effectively as a trusted chain would, without needing Windows or SmartScreen to vouch for the publisher name.

Publisher-trusted signing (through a real certificate authority) is on hold while the company's legal entity changes — a code-signing certificate is issued to a specific registered company, and signing under the wrong one would be worse than the current self-signed state. Until that resolves, this is the verification model for Windows, and it carried forward unchanged from 1.6.0 into 1.7.0: the same certificate and the same thumbprint were reused for this release rather than reissued.

Linux: what the GPG signature actually proves

Each .deb and .rpm is accompanied by a detached, ASCII-armoured GPG signature — a <file>.asc published beside it — from a key held for exactly this purpose. Unlike the Windows certificate, this is not a chain-of-trust question at all: GPG verification either confirms the file matches what was signed by the key you have explicitly decided to trust, or it does not. There is no "untrusted root" state to reason about the way there is on Windows, which is why Linux install commands can verify the signature unconditionally and refuse to proceed on a mismatch, with no leniency built in.

The generated Linux install command already does this for you: it downloads the package, its .asc signature and the published public key, checks the SHA-256, imports the key, verifies the signature, and only then invokes the package manager — every step chained so that a bad signature stops the install rather than being logged and ignored. The same signing key was reused for 1.7.0's packages as for 1.6.0's.

macOS: raw binaries, no installer, and why

macOS is the platform where there is nothing to click through at all. Raw sensor binaries (amd64, arm64 and a universal build) are published, and they are unsigned — there is no .pkg installer today. That is not a missing download; it is a deliberate gate. Building a macOS installer needs Apple Developer ID Application and Developer ID Installer certificates plus notarisation credentials, none of which cover this release, and shipping an unsigned .pkg anyway would be refused by macOS's own Gatekeeper on any Mac that did not build it. Rather than publish a package that cannot be opened, none is offered — the only path on macOS today is running the raw binary directly. This is unchanged in 1.7.0.

If you are choosing what to trust on macOS, the honest answer is: nothing about the download itself vouches for its authenticity the way the Windows thumbprint pin or the Linux GPG signature does. Verify what you downloaded against the published SHA256SUMS.txt before running it, and treat the absence of a signed installer as the real coverage gap it is rather than a formality — see Installing the sensor on macOS for the full picture of what is and is not covered on this platform today.

1.7.0's published artefacts, for reference

These are the SHA-256 values published alongside the 1.7.0 release manifest at the time this article was updated. Always check the live SHA256SUMS.txt and manifest.json published with your own download rather than a value copied from a document — the table below is a snapshot of one release, and it will be wrong the moment a future release ships. It is here so you have a concrete example of what a correct verification looks like, not as a permanent source of truth.

The Windows signing thumbprint above is the same one published with 1.6.0 — the certificate was reused rather than reissued for this release, so if you pinned it previously there is nothing to update on that front. The hashes themselves are new; a 1.6.0 hash will correctly fail verification against a 1.7.0 download, and that is exactly the check working as intended, not a fault.

What 1.7.0 adds over 1.6.0: telemetry breadth

1.6.0 was a rebrand and a signing-model release; it did not change what the sensor collects. 1.7.0 does: it adds five new telemetry channels on top of the process and file events every earlier sensor already reported.

Every one of these is independently gated by policy and collection settings. A fleet that has not opted in to a channel pays no cost for it beyond a cheap bundle check every few minutes — nothing is collected, uploaded or stored for a channel a host's policy has not enabled. Upgrading a fleet to 1.7.0 does not, by itself, turn any of this on.

The full picture of what each channel reports, including every platform-specific gap — the Linux DNS channel needing systemd-resolved raised to debug logging yourself before it reports anything, the logon channel's brute-force detection being Windows-only in practice, USB history meaning "last known state," not live presence, and exactly which two platforms get FIM actor attribution — is in The endpoint telemetry page, the console view built to read all of it per host.

What changed with the Qorionix rebrand, so old guidance does not mislead you

If a script, an RMM template or a piece of internal documentation still references the old service name or the old environment-variable prefix, that is what needs updating — the sensor itself accepts the old prefix as a fallback this release, but the service and unit names have no fallback: a script looking for the old service name will simply find nothing running.

What to read next

1. Installing the sensor on Windows — the exact command, silent-install flags and where files land.
2. Installing the sensor on Linux — the exact commands for both package formats and both architectures.
3. Installing the sensor on macOS — what running the raw binary means for coverage on that platform.
4. The endpoint list and endpoint health — the check that actually confirms an install worked, on any platform.
5. The endpoint telemetry page — reading the seven telemetry tabs 1.7.0's new channels feed, and every platform gap in them.