Installation & operation

Device status and engine health

A device reports two independent things: an account status the backend accepts, and the health of the on-device engine. This page explains what active means, what happens when the engine cannot analyse, and the reduced Basic Protection mode.

~6 min read · Installation & operation

The status a device carries

Each enrolled device carries a status. Only some let the daemon operate:

StatusMeaning
enrolledEnrolled and allowed to run; the status a fresh enrollment is written with
activeThe earlier name for the same running state; still accepted
pausedPaused by an owner command; the daemon keeps checking in so it can be resumed
pendingNever enrolled: blocked
revokedAccess withdrawn: blocked
Status is the account-level state. It is separate from engine health below: a device can be active yet report that its engine cannot analyse.

Active means the engine is analysing

Alongside status, the device reports whether its engine is running as the device is entitled to run it, as a plain supported flag with a reason when it is not:

  • Supported: the engine is up and every change is scored normally.
  • Reason attached only on failure: when the engine cannot analyse, a short reason rides along; when it is healthy the reason is cleared.

When the engine cannot analyse: fail-closed

If the engine cannot do its job, the device does not wave changes through. It holds them. This is triggered by:

  • CPU below the baseline: the machine lacks the vector instructions the engine needs.
  • Engine unavailable: the start path produced an evaluator that can analyse nothing.
  • GPU guard: a device entitled to a GPU model finds no supported GPU.
Fail-closed: while the engine is unavailable, every watched change is held in its last clean state rather than accepted unevaluated. The device keeps running and keeps checking in, so the console sees the condition. See fail-closed by design.

Busy is not broken

A device that is staging a new model reports that separately, as a pending-update marker, and stays fully active while it does so. Pre-staging is not the same as an unavailable engine, and it is never reported as unsupported.

Basic Protection when a license lapses

A lapsed license is handled differently from an unavailable engine. If a license passes its grace window, the device drops to a reduced Basic Protection mode:

  • Model analysis pauses: the graded evaluation stops rather than holding every change.
  • Hard rules stay on: the meta-attack rule layer still runs and still reverts what it catches.
  • Self-healing: the next successful license check-in restores full protection automatically.
Basic Protection and the fail-closed engine hold are not the same: an unavailable engine holds changes, while a lapsed license reduces the graded analysis but keeps the hard rules enforcing.

What the console shows

For a cloud device the backend keeps the status, the engine flag and its reason (length-capped), a coarse liveness marker, and any pending-update state, so an operator can see whether a device is active, held or reduced without any file content leaving the machine.

The safe-by-default stance behind the hold: fail-closed. How the engine is delivered and updated: updates and lifecycle. Where a device first gets its status: installing PoisonZero.

Was this helpful?

Know exactly how each device is protecting itself.

Active, held or reduced, reported without content leaving the machine. Free for Linux, macOS and Windows.

Sign me up