How it works
Outbound HTTPS only. No inbound ports, no remote control, no ability to change anything on the endpoint.
The probe reads and reports. There is no code in it that installs updates, changes settings, starts or stops services, or runs a command sent from the server.
The probe reads; the server decides
Once an hour the probe reads raw values from the machine and sends them. It makes no judgements: no thresholds, no end-of-life dates, no pass or fail. Our server decides what each number means.
That is deliberate. When a Cyber Essentials rule changes, or a version of Windows reaches end of life, we change one file on the server. Nothing has to be redeployed to machines we do not control.
It never updates itself
The probe never downloads or runs code from the server. A new version reaches your clients’ machines only when you deploy it, through your own RMM.
A probe that updated itself would make our portal a route into every machine it is installed on. So it doesn’t.
It does not say who it belongs to
Each probe sends only its own device identifier. Which MSP and which client a machine belongs to is looked up on our server, from our own records, so a probe cannot claim to belong to someone else.
Getting a machine reporting
- Get an enrolment code from the portal. It expires after 7 days, and generating a new one cancels the old one straight away. Treat it like a password.
- Install the probe with that code, by hand or through your RMM. On Windows it runs as a scheduled task under SYSTEM; on Linux, as a systemd timer.
- Approve the machine in the portal. It waits there until you do; approval is always a human step. A leaked enrolment code gets someone a machine waiting for approval, and nothing more.
Step-by-step installation, including the RMM command line, will be in the documentation. To be confirmed: link to the install guide once the documentation is written
Network
One outbound rule: HTTPS, TCP port 443, to our collector. No inbound rules and no listening ports; nothing ever connects to the probe. To be confirmed: link to the firewall requirements, which give the collector's hostname
The probe never contacts the portal. The portal is for people, in a browser, and does not need allowing on client machines.
The update check also uses the machine’s normal Windows Update path: Microsoft Update, or your WSUS server if the machine uses one. On a WSUS-managed machine the figure reflects what that WSUS server has approved, and the report records that it came from WSUS.
What it sends
The checks listed on the home page, plus the machine’s hostname, domain name, operating system version, the probe’s version and its device identifier.
It does not collect usernames, the names or contents of anyone’s files, lists of installed software, browsing or network activity, event logs, screen contents or hardware serial numbers. Nothing is read from user profiles. Administrator accounts are counted, never named.
If the network drops
A report that cannot be sent is queued on the machine and sent on a later run, so a network outage does not leave a gap in the record. The queue holds about eight days of hourly reports.
The limit
The machine belongs to your client, not to us. What the probe reports is the machine’s own account of itself. Anyone with administrator rights on it could make it report whatever they liked. Every agent-based tool shares that limit.
What this gives you is continuous monitoring and a dated record. It is evidence you can take to an assessment, not proof that a machine is secure, and using it does not mean you will pass.