The HiveCatcher security model

Summary

HiveCatcher gives a technician access to the equipment at a site over a single outbound connection. Nothing on the site's network is exposed, nothing is opened on the firewall, and nothing has to be installed on the technician's machine. Access is scoped to one device per person, enforced in two places, and every administrative action is attributable. This paper explains each of those claims.

We build for service organizations and the people who keep critical equipment running, and for their customers who need that equipment serviced without a truck roll. That focus shapes every choice here: the smallest possible path in, closed when it is not in use, and simple enough that a technician under pressure can rely on it.

2. Why WireGuard

We chose WireGuard for one reason above all: it is the safest way to get a technician onto equipment, and the easiest for them to use. Those two goals usually pull in opposite directions. WireGuard is the rare case where the more secure option is also the simpler one.

• It is small enough to trust. The implementation is a few thousand lines, compared with the tens or hundreds of thousands in older VPN stacks. Less code means less to audit and less to go wrong, and it has been reviewed and formally analyzed by the security community.
• It has one modern cipher suite, with no downgrade. There are no legacy algorithms to negotiate down to and no configuration knobs that quietly weaken it, which is the usual way VPNs are broken in practice.
• It is silent to strangers. An unauthenticated packet gets no reply at all, so the endpoint does not confirm its existence to a scanner.
• It is easy. One config, one key pair, no certificate authority to run. That means fewer support calls and fewer mistakes at a site, which is itself a security property: a tool people find hard is a tool they work around.

3. Who we serve

HiveCatcher is built for service organizations and for customers who need to reach critical equipment to service it: mechanical and electrical contractors, controls and BAS shops, equipment OEMs, and the building owners who depend on them. Their common need is narrow and clear. Get a competent person to the machine, safely, without exposing the network and without waiting on a firewall change. We optimize for that, not for general corporate access.

4. Identity and enrolment

Each device has a stable hardware identity derived from the machine itself (SMBIOS UUID, with a documented fallback chain), so the same box keeps the same identity across reimaging. Enrolment pairs a device to an account without ever trusting a user-supplied secret as the source of truth: the cloud issues and stores a per-device credential in hashed form only.

Devices can be brought in two ways. A device can register itself and then be claimed, or a printed code can be claimed first and the device binds when it comes online. Either way, an unowned device is inert: it reports only what it must to be reachable, and it does nothing at the carrier until a paying account is attached.

5. Who can reach what

Access is expressed per device, not per network. A person is a member of an account or an organization, holds a role, and is granted access to specific devices. Two independent controls enforce it: the cloud only mints a tunnel for a device the caller is entitled to, and the isolation rules on the relay ensure a connected client can reach only that one device, never others and never the building network behind it.

Organizations can delegate: a Service Partner or an integrator manages devices on behalf of their customers with their own roles and billing, and explicit access grants follow a device when it is transferred, with a warning and an option to revoke. Administrative actions such as forcing a transfer, changing a code, or rotating keys are restricted to super administrators.

6. The browser terminal, and native access

The terminal is a separate service, bound to loopback, never exposed to the internet directly, and reached only through an authenticated reverse proxy. A session requires a short-lived, signed grant minted by the cloud for a specific user and device; the terminal verifies the grant and then opens a shell as a dedicated, unprivileged account. No client software is installed on the technician's machine, and grants expire quickly.

Sometimes a terminal is not enough. When a job needs native tools, a file transfer client, or direct access to other hosts on the site, the same session can use a standard WireGuard client on the technician's machine, with a config we hand out for that device. The client is the ordinary, audited one from the WireGuard project. Download it at wireguard.com/install. It is optional: the browser terminal covers most work with nothing to install.

7. Encryption

WireGuard uses a single, modern cryptographic suite with no negotiation and no options to weaken it:

• Curve25519 for the key exchange (ECDH). Each peer has a static key pair; keys are generated on the device and the private key never leaves it.
• ChaCha20 and Poly1305 for authenticated encryption (AEAD). Every packet is encrypted and authenticated, so tampering is detected. ChaCha20 is fast in software on small hardware, where AES-based options are not, which matters on the class of box we run on.
• BLAKE2s for hashing and HKDF for key derivation. Session keys are re-keyed automatically.
• No legacy ciphers. There is no fallback to older or weaker algorithms, which is the most common way a VPN is actually broken in the field.

Two further properties matter for us. WireGuard uses cryptokey routing: each peer is bound to the specific internal addresses it is allowed to use, so a key can reach only the addresses assigned to it, which is how our per-device isolation is enforced at the protocol level as well as at the firewall. And the tunnel is on demand, so the encrypted path does not exist at all until a session needs it and closes when it ends.

8. Keys and secrets

Secrets are stored hashed or in a root-only environment file, never in source control, and never logged. Cloud-generated SSH keys are installed on devices through a tagged, managed block that leaves operator-managed lines untouched. VPN peers and firewall isolation rules are owned by a reconciler rather than edited by hand, so the running configuration always matches the intended state.

9. Device integrity and updates

The agent is deliberately small and dependency-free, which keeps the audit surface and the supply chain narrow. Updates are content addressed and cryptographically signed, and the agent verifies the signature before it installs. A failed update reverts: privileged changes are staged and only kept once the device has come back healthy, so a bad release cannot strand a box in the field.

10. Payments and the carrier

Card data never reaches HiveCatcher. Payments are handled by Stripe; we hold a customer reference and subscription state only. The cellular provider's API is IP allowlisted and is called only from our cloud, never from a device at a site, so a compromised device cannot reach the carrier. A line is activated only on an explicit, paid action: a connectivity check or a heartbeat never turns on a line, so we never incur or pass on a charge for a line nobody is paying for.

11. Operations and data

HiveCatcher runs on hardened cloud infrastructure with encryption in transit, a dedicated database, and nightly backups. Telemetry is minimal and operational: identity, connectivity, health. We do not take copies of your systems, and we do not scan your OT network. Our privacy practices, including how we handle analytics consent, are set out in the Privacy Policy.

12. What we do not do

We think a security document is more credible when it states its limits. HiveCatcher is not a device discovery or inventory platform. It is not packet inspection or threat intelligence. It does not replace network segmentation, an EDR, or a governance program. It is the smallest possible path between a competent person and the equipment they are responsible for, with that path closed when it is not in use.

If you need the broader platform capabilities above, they are real and worth having; see how we compare for an honest read on which job each tool is for.