Installing the sensor on macOS

There is still no macOS installer. Since 2026-09-20 we do publish raw, unsigned sensor binaries for macOS (Intel, Apple silicon and a universal build) alongside the Windows and Linux artefacts — that is new, and it means the software genuinely exists and runs. What has not changed is the packaged, signed .pkg a fleet can actually be deployed with: it is not built, and Gatekeeper refuses to open an unsigned package on any Mac that did not build it. Running the raw binary by hand is possible for a technically confident admin (see below); it is not a supported deployment path, has no LaunchDaemon wired up for you, and is not what most organisations should plan around. This article exists so you find that out in a few minutes rather than after an afternoon of trying.

What exactly is blocked, and what exists now

The macOS sensor code is written, builds for both Intel and Apple silicon, and a verified universal binary exists and is now published — download names qorionix-sensor-darwin-amd64, qorionix-sensor-darwin-arm64 and qorionix-sensor-darwin-universal, alongside the same manifest.json/SHA256SUMS.txt the other platforms publish. None of the three is signed or notarised. The installer package definition (Distribution.xml, the launchd plist, the welcome/conclusion text, the post-install script) also exists, fully rebranded to Qorionix, but the compiled .pkg itself is not built: producing one needs Apple's own pkgbuild/productbuild tools, which only run on macOS, and our current build pipeline runs on Windows. What is missing, in order: a Mac to build the .pkg on, and two Apple Developer ID certificates (Application and Installer) plus notarisation credentials to sign it.

Shipping a macOS package to other people's Macs takes two Apple certificates, not one. A Developer ID Application certificate signs the sensor binary itself, and a Developer ID Installer certificate signs the .pkg that wraps it. They are different certificates and neither can do the other's job — a package signed with only the Installer certificate wraps an unsigned binary, and Apple's notarisation service rejects exactly that. On top of both, notarisation credentials are needed so Apple's service can scan and stamp the result.

As of 3 September 2026 the signing pipeline itself is built and validated, and one of the three credentials is in place: the App Store Connect API key used for notarisation. The two certificates are not, and one further identifier is outstanding. Until they arrive the pipeline does not produce a package at all — it fails. That is deliberate: an unsigned macOS installer is not a degraded release, it is not a release, and a build that quietly emits one is how an unusable package reaches a customer.

When the release is built without those credentials, the pipeline writes a warning file beside the artefact rather than only logging a line, so that the warning cannot be lost on its way out of the build system. Its contents, verbatim:

This macOS package is NOT signed and NOT notarised.

Gatekeeper will refuse to open it on any Mac that did not build it. It is
suitable for internal testing only and must not be given to a customer.

Signing needs Apple "Developer ID Application" and "Developer ID Installer"
certificates plus notarisation credentials. See docs/BLOCKERS.md, section
"macOS code signing".

That warning file is about the .pkg specifically, and the .pkg is genuinely not built — pkgbuild/productbuild are Apple-only tools with no cross-platform substitute, and our current release pipeline runs on Windows. The raw binaries are a different case: they are a plain Go cross-compile, which does not need a Mac at all, so they are built and published from the same Windows pipeline that builds the Windows and Linux artefacts. That is the whole reason a binary exists today when a package does not.

If you want to run the raw binary yourself

This is not a supported deployment path — there is no installer, no launchd job wired up for you, and no documented fleet rollout — but it is honest to describe it, since the binary is real and downloadable. An admin comfortable with the terminal can download the architecture-appropriate binary, clear the quarantine flag macOS attaches to anything downloaded from the internet (xattr -d com.apple.quarantine <path>, or approve it once via System Settings → Privacy & Security after a blocked launch), make it executable, and run it with an enrolment token the same way the other platforms take one on the command line. It will need Full Disk Access granted manually (System Settings → Privacy & Security → Full Disk Access) to see file and process activity, and you are responsible for keeping it running (a launchd plist of your own, or simply leaving a terminal session open) since the packaged LaunchDaemon that would normally do this is exactly the part that is not built. This is realistically a one-machine-at-a-time, test-only path, not something to roll out to a fleet.

What this means for you

• Your Mac fleet, as a fleet, is not covered. There is no package your MDM can push, so realistically no organisation has telemetry from its Macs today — the raw binary above is a manual, one-machine exercise, not a rollout.
• No behavioural detections fire for a Mac that is not running the binary, and endpoint response actions (isolate, quarantine, kill process) do not apply to it — the same as any machine with no sensor.
• A Mac will not appear in your endpoint list unless someone has manually run the binary on it and enrolled it — an absent Mac is not a fault to report, it is this.
• Everything that is not the endpoint sensor still works normally for Mac users. A person using a Mac still signs in through your identity provider, still generates Microsoft 365 and Entra sign-in activity, and is still covered by your posture assessment, your identity policies and your log-based detections. It is the machine that is uncovered, not the person.

What to do about your Macs meanwhile

Three things, in order of how much they buy you.

1. Lean on the identity side, which does cover Mac users. Enforce multi-factor authentication, review admin accounts, and act on the sign-in findings in your posture report — the majority of incidents in organisations your size begin with an account rather than a device. What Qorionix does, and what it does not sets out where the other modules stop.
2. Keep Apple's own protections switched on and current. FileVault, automatic security updates, and the built-in malware protections are the baseline you are relying on for these machines. That is a real answer, not a consolation prize, but it is not equivalent to endpoint detection and you should count it as what it is.
3. Do the preparation now so the day it unblocks is a short day. Confirm you can deploy a package through your MDM, and decide who will approve the Full Disk Access profile — macOS 11 and later require Full Disk Access for the sensor to see the file and process activity that makes it worth installing, and pushing that grant through MDM is much less painful than talking each user through System Settings.

When this changes, and what to expect

The remaining work is credential provisioning rather than engineering, and it is now two specific items: the two Developer ID certificates described above, exported together with their passwords, and one identifier from our App Store Connect account. Both have to be done by the holder of our Apple Developer account personally — Apple restricts creating Developer ID certificates to the Account Holder, and there is no way to delegate it or automate it through their API. We are not going to put a date on it here, because a date in a knowledge-base article is a promise and this one depends on someone sitting at a particular Mac.

It is also worth knowing what the macOS sensor will and will not do when it does arrive, so it does not get oversold in the meantime. It reads the process table with ps on an interval rather than using Apple's Endpoint Security framework, which would need an Apple-granted entitlement we do not hold. That means the same limitation the other platforms have — a process that starts and exits between two samples is missed — and no real-time exec events. What the sensor collects has the per-platform detail.

In the meantime, deploy to Windows and Linux, where a real installer is shipped — the Windows MSI self-signed with a pinned thumbprint, the Linux packages GPG-signed — even though neither one is signed by a publicly trusted certificate authority yet either.