What runs on your devices, and what cannot.
guardstate reaches your estate with an agent of its own. These are the limits that agent runs inside, and how the record it leaves behind is kept.
Six limits, and why each one is there.
None of these can be switched off. The evidence is only as good as the weakest of them.
Its own agent
guardstate reaches your devices with an agent of its own. It does not ride on your MDM, your RMM or your deployment tool to get there, and it never sends either of them an instruction. Turn guardstate off tomorrow and everything you already run is exactly where you left it.
This matters for the evidence. Evidence pieced together from another tool's reports has that tool's blind spots, most obviously the devices it never enrolled. The agent reports what it finds on the device itself.
Nothing runs that was not signed
Every agent build is signed at release, and the agent verifies the signature of anything it is asked to execute before it executes it. An unsigned or altered payload is refused, and the refusal is written to the record like any other event.
Messages travel signed in both directions. The agent holds a device-bound key, so the service can tell which device sent each report, and the device can tell that each instruction came from the service. Neither side acts on a message it cannot trace.
Plans come only from a fixed action registry
Fixes are never written on the fly. Each one is an entry in a list built into the agent at release, with its own settings, its own preconditions and its own check afterwards. guardstate can pick an entry from that list, but it cannot add a new one.
So guardstate never writes a command that runs on your device, and never asks an AI model to write one. What the agent can do to a device is fixed when you install that version, and you can review it before you do.
Every fix is verified on the device
After a change, the device is checked again, and that result is what goes into the record. If a fix reported success but didn't take, it shows as a problem, not a tick.
An assessor tests the actual device, so the record is built from the actual device too.
No forced reboots
A fix that needs a restart waits for the maintenance window you set. Nobody's laptop restarts in the middle of their afternoon.
Until the restart happens, the device shows as outstanding, with the window it is waiting for.
Per-tenant isolation
Each tenant has its own store, its own keys and its own evidence. Nothing is pooled or shared between customers, not even for our own analysis.
Sign-in is SSO through Entra or Google Workspace, or a passkey. There is no password for anyone to phish, reuse or leave behind, and no administrative account spans two tenants.
How the evidence is kept.
Every finding, every fix and every verification is written as an entry: what was read, on which device, at what moment, and what changed.
Each entry is hashed onto the entry before it, so the entries form one chain in your tenant's own store, and you hold the head of it.
Each entry is signed on the device before it leaves, so the signature covers what the device actually observed rather than what arrived at the other end.
An edited line changes its own hash. A missing line breaks the link to the next one. Either way the chain stops matching the head you hold, and the break shows exactly where it is.
What this is for
So an assessor can trust what they are shown. Nobody can change a record after it was made without it showing, and the value the chain is checked against is held by you, not by guardstate.
What this is not
A scheme requirement. Cyber Essentials does not ask anyone for a hash chain, and holding one earns nothing at assessment. guardstate keeps one because evidence that can be edited afterwards is not evidence.
How long it is kept.
Thirteen months by default: a certification year, plus the renewal that follows it. Longer terms are selectable per tenant, for the customers whose own contracts ask for them.
You can export the chain and its head at any time, in full. The export is what you keep if you stop paying us, and it verifies on its own.
The rest is on the main page.
How it works, what it covers, what it costs, and a walkthrough of an example tenant.
Found a security problem in guardstate? Write to security@guardstate.co. The same address is published at /.well-known/security.txt.