Security
Security & Data Ownership
This page answers the questions a technical evaluator asks before installing KEEP on a live network: what data stays on your own infrastructure, what KEEP as a vendor ever sees, and how to remove an evaluation deployment if you decide not to continue.
Data Ownership
What data remains local
The software KEEP installs at a client site keeps a local working cache of what it discovers — not a system of record. It discovers and polls devices on that network, then sends what it finds to your own Hub — the central server your organization runs. That local cache is fully re-derivable from a fresh scan; the authoritative copy always lives on your Hub. (Source: KEEP architecture documentation)
Your Hub's database is the system of record for everything KEEP discovers about your clients' networks — device inventories, incidents, scan results — and it runs on infrastructure you control, not on servers KEEP operates. (Source: KEEP architecture documentation)
If you manage more than one client site, what a Spoke discovers about that client's network — device inventories, incidents, scan results — is reported only to your own Hub, never to KEEP directly, and never to another organization's Hub. Separately, each Hub and each Spoke also keeps its own direct connection to KEEP's Control Plane for license and entitlement enforcement — a different channel, carrying none of that operational network data. See What reaches the Control Plane, below. (Source: KEEP architecture documentation)
Data Durability
Backup and disaster recovery responsibility
KEEP does not provide built-in backup or disaster recovery for the durable data store used by your KEEP deployment. As the deployment owner, you are responsible for protecting and backing up the infrastructure and storage that hold that durable data, the same way you would for any other system of record you operate. (Source: KEEP architecture documentation)
KEEP does not keep a separate copy of that durable customer data on its Control Plane, so it cannot restore data it never held a copy of. (Source: KEEP Control Plane architecture documentation)
Control Plane
What reaches the Control Plane
KEEP's Control Plane — the service that handles evaluation access, accounts, and licensing — is designed to receive only account, licensing, deployment-identity, and device-enforcement information. It does not receive the operational data your network monitoring produces: no device inventories, no incidents, no scan results. (Source: KEEP Control Plane architecture documentation)
The device-enforcement piece: each Hub and each Spoke periodically checks in with the Control Plane directly — not relayed through each other — confirming license/entitlement status and, once per boot, a network fingerprint (the gateway device's MAC address and the MAC addresses of neighboring devices on that segment) used only to detect a cloned or duplicated device. Nothing about what those neighboring devices are or do is included — just their MAC addresses. (Source: KEEP architecture documentation)
Where setting up a deployment requires network configuration details, those details are used only to prepare your installation package and are not retained afterward. (Source: KEEP Control Plane architecture documentation)
Trust
Authentication and trust boundaries
Every device that joins your network is explicitly authorized by your own administrator before it can connect — KEEP's Control Plane has no ability to authorize a device on your network by itself. (Source: KEEP architecture documentation)
Your team signs in one of three ways: through your own Active Directory or LDAP-speaking directory, through your organization's OIDC/SSO identity provider (Microsoft Entra ID, Google Workspace, Okta, JumpCloud, and similar), or through a KEEP-native local account. (Source: KEEP application security architecture)
Signing in through your directory or SSO provider establishes who someone is — it does not, by itself, grant them any authority inside KEEP. KEEP controls authorization separately: what a signed-in person can actually do is determined by the KEEP role(s) associated with their account, never by which sign-in method they used to get in. (Source: KEEP application security architecture)
For OIDC/SSO sign-ins specifically: the first time someone signs in with an email address KEEP doesn't already recognize, KEEP creates an inactive record and denies sign-in — authenticating with the identity provider does not activate the account. A Director or Senior Technician has to actively approve the person before that account can access anything. Your identity provider vouching for an email is never, by itself, enough to get in. (Source: KEEP application security architecture)
Multi-factor authentication applies to KEEP-native local accounts. Active Directory/LDAP and OIDC/SSO sign-ins are governed by your own identity provider's security policy, not KEEP's. (Source: KEEP application security architecture)
Authorization
Technician roles and permissions
Once someone is signed in, what they can actually do inside KEEP is controlled by the role or roles a Director or Senior Technician has assigned them — not by which sign-in method they used. A technician can hold more than one role at the same time; what they're able to do is the combination of everything every role they hold grants. There's no deny-list and no conflicting-role restriction in this version — assigning a role only ever adds access, never removes it. (Source: KEEP application security architecture)
Predefined roles
Technician, Senior Technician, and Director are the general access levels most organizations start with — each is defined as its own ordinary role, like any other, and each happens to include everything the level before it does, plus more. If your team was already using KEEP, existing technicians carried forward into whichever of these three matches what they already had, automatically — no one lost or gained anything in the transition.
Composable roles
Remote-Access Specialist, Onboarding Coordinator, Compliance Reviewer, and Security Administrator each grant one specific area of access and can be assigned in any combination, alongside a predefined role or on their own — for example, a technician who only ever handles new client onboarding doesn't need to also be made a Senior Technician just to get that one capability.
When your team signs in through Active Directory or an LDAP-speaking directory, KEEP can also map your existing directory groups directly to KEEP roles — belonging to more than one mapped group grants more than one KEEP role. That mapping is re-checked every time the person signs in: remove them from the directory group and KEEP revokes the role that group granted on their next login. A role a KEEP administrator assigned directly, rather than through a directory group, is never affected by that directory-driven check — the two coexist independently, and either can grant the same role without the other one deleting it. (Source: KEEP application security architecture)
Network Footprint
What touches your firewall, and what doesn't
Spoke connections — outbound only
A Spoke always initiates its own connection outward to reach your Hub, and separately initiates its own outward connection directly to KEEP's Control Plane for its device-enforcement heartbeat. There is nothing to open on a client site's firewall for either — outbound traffic is already permitted by default on virtually any network.
Hub enrollment — one scoped exception
If your Hub runs on-premises behind NAT and you're enrolling a Spoke at a different physical site, one specific port must be forwarded so that new Spoke can reach it and enroll using a single-use key issued only for it. The port itself isn't yet IP-restricted to that Spoke — that's a planned hardening step, not shipped today. Leaving that port open between onboardings, or closing and reopening it each time, is your call. Without it forwarded, the Spoke still works — it falls back to a direct connection instead of joining the mesh.
(Source: KEEP architecture documentation)
Device Trust
Signing keys, and replacing a Hub or Spoke
The onboarding artifact used to enroll a Spoke (see Hub enrollment, above) is cryptographically signed. KEEP can rotate its signing keys, and a compromised or retired signing key can be revoked. Once a signing key is revoked, onboarding artifacts signed by that key are rejected. (Source: KEEP application security architecture)
If a Hub or Spoke device fails, is retired, or is deliberately replaced, KEEP has an authorized replacement process for bringing a new device online in its place — this is not the same as any new machine being able to simply claim an existing device's identity. A replacement has to be explicitly authorized, and the predecessor device's own access — including its certificate, where one applies to that specific device — is retired as part of that same controlled transition, not left valid indefinitely. (Source: KEEP architecture documentation)
Browser-based remote sessions (see Capabilities) use an additional device-trust boundary on top of this: the relay transport itself is certificate-authenticated, in addition to KEEP's normal application authorization. (Source: KEEP application security architecture)
Evaluation Removal
Evaluation removal process
If you decide not to continue after evaluating KEEP, a complete removal procedure exists for the software and data on your own infrastructure, and it has been verified against a real evaluation installation. (Source: KEEP Evaluation Program documentation)
Unknown
Open Questions
Evaluation considerations
Unknown