Multi-tenant EDR built for security partners
Managing endpoint detection across client environments means every client's data has to stay separate, every alert queue has to stay legible, and every console switch has to be fast. LightEDR's multi-tenant architecture is built around those constraints from the data model up - not bolted on with an enterprise add-on SKU.
Three things that break when one platform serves many clients
These show up the moment an MSSP tries to run more than a handful of clients on a platform that was designed single-tenant first.
Data isolation is an afterthought
Many EDR platforms add multi-tenancy as an enterprise-tier bolt-on: shared indices, client data separated only by a filter clause. One misconfigured query and Client A can see Client B's alerts.
Console-per-client is not workable
Logging into a separate console per client does not scale past a handful of accounts. Analysts need to move between tenants without re-authenticating or losing context on what they were investigating.
Trust and licensing get bundled together
Per-seat enterprise pricing is built for a single buyer, not a partner managing dozens of downstream clients at varying sizes. The commercial model needs to match how MSSPs actually bill.
Every client's data plane is isolated, enforced server-side
API keys are scoped to an explicit list of agent IDs. A key issued for Client A's environment can only ever return alerts, events, and hosts belonging to Client A's registered agents - regardless of what the calling system requests. This is enforced in the triage engine itself, not in a client-side filter that a misconfiguration can bypass.
There are no shared indices to leak across a filter boundary, because there is nothing to filter: the scope is checked before a query touches the data plane.
Switch tenants without switching consoles
Analysts operate from one console and move between client tenants without re-authenticating. Each tenant's alerts, events, and trust data are isolated, but the operational overhead of context-switching between them is not - that happens in one screen.
This matters most during an incident that spans a shift change or an analyst covering more than one client at once. Nobody is juggling browser tabs logged into different client instances.
Every client endpoint scored independently
Zero Trust continuous verification runs per endpoint, per tenant. A trust score dip on one client's fleet has no bearing on another client's baseline - each tenant's five-signal composite score is computed against its own historical behaviour.
That means a client with a genuinely noisy environment does not skew the alerting sensitivity you apply to a quieter one.
A commercial model built for managing other people's endpoints
Managing endpoints for third-party clients is a managed-service use case, which sits outside the standard per-agent license. It requires a separate commercial partner agreement covering per-client billing, support terms, and deployment model.
If you are evaluating LightEDR as an MSSP, contact partners@lightedr.com to discuss terms, or read the licensing FAQ first.
What partners managing multiple clients care about
See the multi-tenant console on a sandbox with several client tenants.
A 30-minute call with the people building it. We will walk through tenant isolation, the console switcher, and the partner licensing model, and answer questions specific to your client base.