Why we rebuilt EndpointGuard from the ground up

This is not a new product. The work goes back a long way. In this post we explain why we did not buy an off-the-shelf tool, what we started from, and which decisions we made on purpose.

Why we wrote our own instead of buying an inventory tool

Our company has been writing software for industrial and manufacturing sites since 2003. In more than ninety factories we kept running into the same situation: a large computer fleet, a small IT team, often a single person.

Those people were short of two things: a current list of what is actually in the fleet, and, when something goes wrong, a simple way to answer "what is the network doing right now?".

We looked at what was on the market. The big products are too heavy and too expensive for a small team; installing, configuring and learning them is a job in itself. The free ones are either unmaintained or ask you to set up a server first, which adds a new problem before it solves the old one.

We had three wishes. Installation should take five minutes. There should be no server to run. It should speak our customers' language, Turkish in our case, and the invoice should come from a local company rather than a marketplace abroad. We could not find anything that met all three, so we wrote it. We used it at our own customers' sites first, and only then opened it to others.

The starting point

For the second need we already had something: "Ping Reporter", an old ping tool with a single address box and a Ping button, which ran on one computer and kept its data only there.

When we decided to add the inventory side (an agent, a panel, remote actions), we had to choose: patch it on top of the old code, or build a common foundation and put everything on it. We chose the foundation. Having the agent, the panel and the new IP Pinger share the same identity, encryption, enrollment and sync layers was far more sensible than trying to keep three separate programs safe. The third-party parts of the old tool that we no longer wanted to maintain left the code base along the way.

Four decisions

1. Remote commands are signed by the server, and there is no free-text command. When you send a command from the panel (restart, disable USB, uninstall a program), the server signs it; if the agent cannot verify the signature, it does not run the command. The signature is one-sided: the private key lives only on the server and agents know only the verification key. If every machine held the same shared secret, one captured computer would be enough to issue commands to the whole fleet. On top of that, the panel only picks a command type and a target; neither the panel nor the server writes the command line to be run. The product does not turn into a ready-made remote-execution tool for an attacker to capture.

2. A command runs once. A "restart" that runs twice is worse than a restart that never runs. So a command is delivered once, the agent records that it has taken the command before it runs it, and if the service is cut off halfway, that command is never retried; you see it in the panel as "interrupted". You decide whether to try again; we did not want software making that call.

3. We decided up front what not to collect. The agent does not collect personal file names, browsing history, Wi-Fi passwords, password hashes or email content. A user name appears only in an account context, and only as an account name. Resellers and outside organisations cannot see inventory by default. Privacy law was one reason, but the simpler one is this: data you do not collect cannot leak.

4. There should be a free step, and installation should be easy. Free up to five devices. Installation is a single code-signed MSI package: it installs silently, can be deployed with Group Policy or Intune, and runs from Windows 7 SP1 onwards. A small business should not need a contract to try it.

What we chose not to do

The honest way to describe a product is to say what is missing.

• The agent runs on Windows only. Linux, macOS and Android come later.
• No automatic updates. When a new agent version is out, the panel only shows a badge. Updating is your decision.
• What cannot be collected is "unknown", not a guess. If a feature cannot be read on a machine, the panel does not say "secure" or "up to date"; it leaves the field empty. A screen that looks incomplete is better than one that shows a false "all clear".
• We do not check that your backups work. We treat that as a different job.

Where we are now

The agent, the panel and IP Pinger are running, and reports are available today: inventory, licenses and security posture as tables you can export to CSV, Excel or PDF. Next come network-device inventory, notifications and support tickets; we build them in order, without promising dates. Applications for the beta program are open; the first invitations go out with the next agent release. Details are on the Beta program page.

In short, we rebuilt EndpointGuard to show a small IT team the fleet exactly as it is, and to do that safely.