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 is a setting you can turn off, because the evidence is only worth what the weakest of them is worth.
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.
That independence is what makes the record worth anything. Evidence assembled out of another tool's reporting inherits 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 attribute every report to the device that made it and the device can attribute every instruction to the service. Neither side acts on something it cannot attribute.
Plans come only from a fixed action registry
Remediations are not composed. Each one is an entry in a registry compiled into the agent binary at release, with its own parameters, its own preconditions and its own verification step. The policy layer selects an entry; it has no way to describe a new one.
So guardstate never writes a command that runs on your device, and never asks a model to write one. The set of things the agent can do to a device is fixed at the moment you install that build, and it is reviewable before you install it.
Every fix is verified on the device
After a change lands, the device is read again, and the result of that read is what goes into the record. A fix that reported success but did not take is a finding, not a tick.
That is the difference between a system that tracks intentions and one that tracks state. An assessor tests the device in front of them, so the record has to be built from the device too.
No forced reboots
A fix that needs a restart waits for the maintenance window you set, expressed in that site's own local time rather than in UTC. Nothing reboots a laptop in the middle of someone's afternoon.
Where a control cannot be met until the restart happens, the device stays visible as outstanding, with the window it is waiting for named on it. Nothing is quietly deferred.
Per-tenant isolation
Each tenant has its own store, its own keys and its own evidence. Nothing is pooled and nothing is shared between customers, including for analysis of our own.
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
An assessor can trust what they are shown. A record cannot be quietly improved between the day it was made and the day someone reads it, and the value the whole 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.
That is the mechanism. The rest is on the main page.
The loop it serves, the scope it covers, what it costs, and the example tenant you can walk through screen by screen.
Found a security problem in guardstate? Write to security@guardstate.co. The same address is published at /.well-known/security.txt.