Fleet Command lets a single customer see across their own branches. MSSP Multi-Tenancy lets a security provider see across many customers. Both use tenant-scoped identities, bounded summary publishing and role-based views. The difference is who logs in, which tenants they are assigned and which actions they may take.
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 in their Edg3 cloud tenant, and sees every branch.
A managed security services provider operates SIEMonster Edge for many independent customers. Their analysts log into a dedicated console and work within their assigned customer scope.
Customer telemetry stays in its tenant. Bounded summaries and approval items are published to the partner surface with an explicit tenant identifier and analyst scope. Detailed access follows an authorised drill-down path rather than a shared raw-data lake.
This illustrative organisation runs SIEMonster Edge in three places. London is the primary site. Cape Town is a datacentre. Sydney is a remote site. Each supported branch detects locally, can isolate a qualifying ransomware verdict locally, then publishes a bounded summary up to London on a configured schedule. The Head of Security in London opens one dashboard and sees the configured fleet view.
Edge agents · isolated tenant · local detection · hosts the Fleet Command Dashboard
Edge agents · isolated tenant · local detection · publishes to London
Edge agents · isolated tenant · 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.
In this illustrative scenario, an MSSP runs SIEMonster Edge for twelve independent customers across finance,
health, retail, energy, ICS and maritime. Each customer has its own dedicated cloud instance and
its own data. Apex’s analysts log into mssp.edg3.io
and filters within the customer assignments authorised for their session.
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 reflects the customers assigned to the provider. A senior analyst can delegate a subset of customers to another authorised analyst without widening that analyst’s scope.
The MSSP surface does not merge every customer’s raw telemetry into one shared partner database. Each customer keeps its own tenant data path. The partner console receives bounded summaries, approval items and audit events carrying an explicit tenant_id.
Partner-side queue and summary records carry a tenant_id. The application intersects the analyst’s assignments with the requested tenant scope before returning records. The example below illustrates the scoped partner view; it is not a shared raw-event lake.
| 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 |
tenant_id = 'b'tenant_id IN ('a','b','c')Customer telemetry remains in its isolated tenant. The partner surface combines only the bounded records required for authorised cross-customer operations and applies analyst scope to every query and action.
Fleet and MSSP surfaces reuse the same tenant identity, summary and authorisation concepts while preserving the distinct customer and provider boundaries.
| Building block | Fleet Command | MSSP Multi-Tenancy |
|---|---|---|
| Per-tenant isolated instance | Each branch runs its own isolated Edge instance. | Each customer runs its own isolated Edge instance. |
| Periodic summary publishing | Branches publish bounded summaries on a configured cadence. | Customers publish bounded partner summaries on a configured 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. | Partner records retain tenant_id and partner-scope metadata. |
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 | In the customer’s primary Edg3 cloud tenant. | Dedicated provider URL, e.g. mssp.edg3.io. |
| Scope model | Fixed. A fleet’s branches are its branches. | Filtered within the analyst’s assigned tenant set. |
| Hierarchy | Flat. One customer to many branches. | Parent and delegated partner scopes where configured. |
| Login & access control | Customer’s existing SOC login. | Provider login with per-customer ACLs. |
An operator session receives an authorised set of tenant identifiers. Parent and delegated partner views can be configured during onboarding; the example below is illustrative and does not imply unlimited or automatic hierarchy.
The parent view may receive the authorised union of {a..h}. Delegated views remain bounded to their assigned sets. Any parent or sub-partner relationship must be configured and tested as part of the invitation-only onboarding process.