How It Works

How KEEP Works

This page explains the architecture behind KEEP: how a deployment is structured, how an evaluation gets set up, how data moves between the parts of the system, and who is responsible for authorizing what. For the specific claims about data ownership and backups, see Security & Data Ownership.

Hub/Spoke architecture

A KEEP deployment has two shapes. In a Solo deployment, a single Hub monitors one network directly. In an MSP deployment, one Hub serves as the central server for the organization, and one Spoke is deployed at each client site it monitors. (Source: KEEP architecture documentation)

A Hub can run in the cloud or on the organization's own premises. A cloud-hosted Hub communicates with its Spokes over standard HTTPS. An on-premises Hub — one running behind its own firewall with no public address — uses a private, self-hosted mesh network for that same connectivity instead. (Source: KEEP architecture documentation)

A Spoke's job is read-only discovery and monitoring of the devices on the network it's deployed to. It does not make configuration changes to the devices it watches. (Source: KEEP architecture documentation)

When a Spoke is deployed to a new site, its first scan is treated as unverified evidence rather than an accepted baseline, until a qualified team member reviews and approves it. (Source: KEEP architecture documentation)

Merlin, KEEP's single AI identity, reasons about the state this architecture produces — it doesn't change how any of it works. See Merlin for what it is and how it's governed. (Source: Merlin architecture documentation)

Evaluation flow

An evaluation deployment is prepared and issued directly to the person evaluating it — this is not a self-service signup form. (Source: KEEP Evaluation Program documentation)

Installing an evaluation activates it and confirms the deployment before anything else happens. A KEEP deployment does not begin normal operation until this confirmation step succeeds. (Source: KEEP Evaluation Program documentation)

Once active, you set up sign-in for your own team, including multi-factor authentication. For how sign-in and authentication work, see Security & Data Ownership. For what happens when you decide to stop evaluating, see that same page's evaluation removal section.

Data flow

A Spoke discovers and polls the devices on the network it's deployed to, then sends what it finds to your own Hub. Separately, your Hub exchanges only account, licensing, and deployment-identity information with KEEP's Control Plane — the service that handles evaluation access and licensing. (Source: KEEP Control Plane architecture documentation)

These are two separate channels. Nothing your Spokes discover about a client's network passes through the second one. For the detailed account of exactly what stays local and what reaches the Control Plane, see Security & Data Ownership.

Trust boundaries

Adding a device to a network involves two decisions, and both belong to your own organization, not to KEEP. Someone from your organization has to be able to reach and configure the device on your network in the first place, and someone from your organization has to explicitly authorize that specific device to join. (Source: KEEP architecture documentation)

KEEP's Control Plane cannot authorize a device on your network by itself — it issues licenses and deployment identities, not network access. (Source: KEEP Control Plane architecture documentation) For how account-level authentication works, see Security & Data Ownership.

Continue to Security & Data Ownership

For the specific claims about what stays local, what reaches the Control Plane, authentication, backups, and evaluation removal, see Security & Data Ownership.