Core concepts
Five ideas explain most of the platform. Read this page once and the rest of the documentation will make sense.
They nest:
Deployment
Lumen Edge is delivered as a service, and a deployment is your organization's own instance of it. When your organization is onboarded, it gets a deployment; nobody else's data ever enters it.
A deployment holds:
- Your users — every account that can sign in to your organization
- Your tenants — one or more, described below
- Your configuration — branding, authentication settings, roles, policies
- Your data — assets, scans, findings, reports
Deployments are completely independent of one another. Two customers of Lumen Edge share no assets, no users, no configuration and no visibility into each other:
There is no path between those two boxes. You never have to reason about other organizations when you configure yours.
As a customer, "deployment" is simply your Lumen Edge. You do not create, choose or switch deployments — you work inside yours. The concept matters because everything below lives inside it.
Tenant
A tenant is an isolated customer or business unit inside your deployment. It is the boundary the product organizes work around: each tenant has its own asset inventory, its own sensors and integrations, its own scans, findings, reports and settings.
How many tenants you need depends entirely on who you are.
If you secure your own organization — one tenant
Most customers use Lumen Edge for themselves. In that case you have a single tenant, and it holds everything: all your assets, all your sensors, all your integrations. You will rarely think about tenants again.
Do not create a tenant per department, per site or per environment. Tenants are a hard wall, not a filter — splitting one organization across several of them means you lose the single, correlated view of your estate that Lumen Edge exists to give you. To slice one inventory by department, site or environment, use tags, custom fields and saved filters instead.
If you serve several independent organizations — one tenant each
Tenants exist for the case where the estates genuinely are separate:
- MSSPs and MDR providers — one tenant per client company
- Holding groups and conglomerates — one tenant per subsidiary that runs its own IT
- Post-acquisition estates — a tenant per acquired company while its network is still separate
| Who you are | Tenants | Why |
|---|---|---|
| A company securing itself | 1 | One estate, one correlated inventory |
| An MSSP with 12 clients | 12 | Client data must never mix |
| A group of 3 independent subsidiaries | 3 | Separate IT, separate teams, separate reporting |
| A company with 5 departments on shared IT | 1 | Use tags and custom fields, not tenants |
What isolation means
Isolation is enforced at the storage layer — each tenant's assets live in their
own search index — so no query, scan, report or export in one tenant can reach
another's data. Two tenants can each contain a host called dc-01 and they will
never be correlated, merged or counted together.
Users and tenant access
User accounts belong to the deployment, not to a tenant. Access to individual tenants is granted per user through roles, so one deployment can hold teams that see entirely different things:
Analyst A cannot see Client B's assets at all — not in search, not in reports, not in exports. A user with no role on a tenant does not see that tenant exist.
This is what makes the MSSP case work: one platform, one set of staff accounts, strictly separated customer data. See Tenants and users and Roles and permissions.
Asset
An asset is one real thing in your environment: a host, a server, a cloud instance, a network device or a user identity.
Assets are the point of the platform. Everything else — sensors, integrations, scans — exists to build and maintain an accurate inventory of them, because you cannot secure, patch, monitor or risk-assess something you do not know is there. The inventory answers "what do we actually have, where is it, who owns it, and what is running on it" — and only once that is answered does attack-surface work become meaningful.
The important subtlety is that an asset is not a record from a single source. CrowdStrike, Active Directory and an Azure inventory pull may each report the same laptop. Lumen Edge correlates those records into one asset with several contributing sources, so the inventory reflects reality rather than tool count.
Each asset carries:
| Layer | Origin |
|---|---|
| Core attributes | Hostname, addresses, OS, first/last seen — from discovery sources |
| Ownership | Resolved from directory or EDR owner integrations |
| Custom fields | Defined per tenant, set manually or by rule |
| Findings | Produced by scans |
When correlation gets it wrong, assets can be split or merged by hand from the asset detail view. See Assets.
Sensor
A sensor is a Lumen Edge collector you deploy inside your network. It is the component that does the actual work of gathering data for a tenant. Whatever the work is, it is expressed as an integration assigned to a sensor:
- API integrations — connections to systems you already operate: Active Directory, CrowdStrike, Microsoft Defender, Entra ID, Azure and others. The sensor reaches those APIs from inside your network and reports the results back.
- Active scanner — probes targets directly to enumerate hosts, open ports and services.
- Passive scanner — watches a network feed (a SPAN port, mirror or tap) and infers hosts from the traffic it sees. It sends no packets.
The first point is worth stressing: integrations do not run "somewhere in the cloud" separately from your sensors. A sensor is the agent on your side of the boundary, and API integrations are tasks it runs — which is why internal systems never have to be reachable from the internet for Lumen Edge to read them.
A sensor belongs to a tenant, reports its own health and check-in state, and can be enabled or disabled without losing the assets it has already discovered. See Sensors.
Integration
An integration is one configured connection to an external system that contributes data. A tenant will typically have many of them running side by side — several EDRs, a directory, one or more cloud subscriptions — because no single source knows about everything.
Integrations are typed, and the type determines both what it fetches and how it is configured. They serve different goals:
| Goal | What it contributes | Examples |
|---|---|---|
| Asset discovery | Machines, servers, cloud instances | CrowdStrike, Defender, Carbon Black, Azure VMs, Active Directory computers |
| Identity discovery | User accounts and identities | Entra ID, Active Directory users, LDAP, Atlassian |
| Enrichment | Extra context on assets you already have — ownership, criticality, location | CrowdStrike asset owner, Elastic asset owner |
| Other | Vulnerability data, network detections, custom queries against your own data | Nessus, Vectra NDR, Elastic aggregation queries |
An integration that discovers assets and an integration that only enriches them behave differently: a discovery source can create new assets in the inventory, an enrichment source only adds attributes to assets that already exist.
More integrations generally means a better inventory — each one covers a blind spot the others have, and correlation folds the overlap into single assets rather than duplicates. See Integrations for the full catalogue.
How they fit together
Sources feed correlation, correlation maintains the inventory, scans both read from and write back to it, and reports read the result — all of it inside one tenant, inside your deployment.