Fleet Command lets a single customer see across their own branches. MSSP Multi-Tenancy lets a security provider see across many customers. Both ride the same engine: per-tenant appliance isolation, periodic summary publishing, scoped grouping, edition-flag activation. The difference is who logs in, where, and what they are allowed to see.
Customers run SIEMonster Edge across many branches and want one console. Security providers run SIEMonster Edge across many customers and want one console too. Same problem statement, different audience. So we built two surfaces on top of one engine.
A single organisation runs SIEMonster Edge across multiple sites: head office, datacentres, remote offices. The customer’s own SOC team logs into one dashboard, hosted on their primary appliance, and sees every branch.
A managed security services provider operates SIEMonster Edge for many independent customers. Their analysts log into a dedicated console and tick on or off any subset of those customers, with full hierarchy support for partner-MSSPs.
Both products sit on the same primitives: per-tenant appliance isolation, periodic summary publishing, scoped grouping, edition-flag activation. The difference is who logs in, where, and what they are allowed to see.
Acme runs SIEMonster Edge in three places. London is the primary appliance. Cape Town is a datacentre. Sydney is a remote site. Every branch detects locally, contains locally, then publishes a summary up to London on a schedule. The Head of Security in London opens one dashboard and sees the whole company.
Edge appliance · isolated · local detection · hosts the Fleet Command Dashboard
Edge appliance · isolated · local detection · publishes to London
Edge appliance · isolated · local detection · publishes to London
One dashboard. Three branches at a glance. “London is fine, Cape Town has a SCADA spike, Sydney’s compliance score dipped overnight.” No more flipping between three separate consoles to get the picture, no per-site logins, no stitch-it-together emails between branch SOC analysts.
Apex is an MSSP. They run SIEMonster Edge for twelve independent customers across finance,
health, retail, energy, ICS and maritime. Each customer has its own dedicated appliance and
its own data. Apex’s analysts log into mssp.edg3.io
and tick on or off any subset of those twelve.
One console. Tick three customers and the entire console re-scopes to those three. Tick all twelve and roll-up KPIs blend across the book. Acquire another MSSP next quarter and the same console scales to twenty without any new infrastructure. A senior analyst can delegate the financial-services customers to a junior, who sees a properly scoped view with the same tools.
The lake is one schema in three storage tiers. Tier 1 and Tier 2 sit on local NVMe inside each tenant’s appliance. Tier 3 sits in customer-owned object storage. All three carry the same Parquet schema. tenant_id is a column on every row. Multi-tenancy is enforced by the database, not by the UI.
Every row in the lake carries a tenant_id. A customer’s session sees only rows where the tenant_id matches their tenant. An MSSP analyst’s session sees rows for whichever tenants they have. There is no second copy of the data per tenant. There is no per-tenant database to spin up. The lake itself does the policing.
| tenant_id | event_time | host | rule_id | severity |
|---|---|---|---|---|
| tenant_a | 03:31:18 | art-dcsl14 | T1003.001 | critical |
| tenant_b | 03:31:42 | bcn-edr-09 | T1110.003 | medium |
| tenant_a | 03:32:05 | fin-jump-04 | T1059.001 | high |
| tenant_c | 03:32:14 | cob-fw-01 | T1071.001 | low |
| tenant_d | 03:32:51 | dlt-scada-7 | T0809 | high |
| tenant_a | 03:33:09 | art-dcsl14 | T1003.001 | critical |
| tenant_b | 03:33:20 | ehr-app-22 | T1110.003 | medium |
| tenant_e | 03:33:48 | ret-pos-12 | T1486 | critical |
WHERE tenant_id = 'b'WHERE tenant_id IN ('a','b','c','d','e')Customer A only ever sees rows where tenant_id = ‘a’. Apex’s MSSP analysts see the rows for whichever tenants they have. The lake itself enforces it. There is no second copy of the data per tenant. There is no per-tenant database to spin up. One lake, one schema, scoped at query time.
We did not build two products on top of two stacks. We built two surfaces on top of one engine. A bug fix in one improves the other. A new detection rule lights up in both. The cost of running both is barely more than the cost of running one.
| Building block | Fleet Command | MSSP Multi-Tenancy |
|---|---|---|
| Per-tenant dedicated appliance | Each branch runs its own Edge appliance. | Each customer runs its own Edge appliance. |
| Periodic summary publishing | Branches publish summaries every 5 min. | Customers publish summaries on the same cadence. |
| Logical tenant grouping (‘scope’) | A fleet = a customer’s set of branches. | A scope = an analyst’s set of customers. |
| Edition flag toggles per tenant | Fleet Command on or off per branch. | MSSP Console on or off per provider. |
| Forward-compatible identifiers | Records stamped with tenant_id and fleet_id. | Same records. tenant_id is all the MSSP needs. |
Fleet Command is a customer-funded view of the customer’s own estate. MSSP Multi-Tenancy is a provider-funded view of many customers’ estates. Same engine, different audience, console, scope, hierarchy and authentication.
| Dimension | Fleet Command | MSSP Multi-Tenancy |
|---|---|---|
| Primary audience | The customer’s own SOC team. | The provider’s analysts. |
| Console location | Embedded in the customer’s primary appliance. | Dedicated provider URL, e.g. mssp.edg3.io. |
| Scope model | Fixed. A fleet’s branches are its branches. | Dynamic per analyst session, tick on or off. |
| Hierarchy | Flat. One customer to many branches. | Recursive. MSSP-of-MSSPs supported natively. |
| Login & access control | Customer’s existing SOC login. | Provider login with per-customer ACLs. |
Scope is just a set of tenant_ids attached to an operator session. Add tenants, remove tenants, nest MSSPs under MSSPs. It is all the same primitive. One console. Any depth.
Nothing in the engine. Apex’s analysts see the union of {a..h}. MSSP-A’s analysts still see {a, b, c, d}. MSSP-B’s analysts still see {e, f, g, h}. Apex can also delegate sub-scopes back down. A junior analyst can be given the FinServ-only view without copying any data.