Multi-Tenant SIEM: Single vs Multi-Tenant Architecture

Every cloud service and every managed security provider faces the same design choice: give each customer its own copy of the system, or run many customers on one shared system and keep them apart inside it. The first is simpler to reason about. The second is cheaper and easier to operate. For a security information and event management (SIEM) platform, which holds some of the most sensitive data a company has, the choice matters more than for most software.

This guide explains single-tenant and multi-tenant architecture in plain terms, compares them on isolation, noisy neighbors, compliance and cost, and shows what changes when the system is a SIEM. It ends with how UTMStack does it. We build UTMStack, so weigh our view accordingly.

The short answer: in a single-tenant architecture each customer gets dedicated infrastructure and its own instance of the software. In a multi-tenant architecture many customers, called tenants, share one instance and its infrastructure, and the software keeps each tenant’s data, users and settings separate. Single-tenant gives the strongest isolation and the easiest compliance story at a higher cost. Multi-tenant is cheaper and faster to operate, but only as safe as its tenant separation. A multi-tenant SIEM must separate data, users, detections, response actions and audit records per tenant, and many providers mix both models: small customers on a shared server, large or regulated ones on dedicated servers, all managed from one console.

What single-tenant and multi-tenant mean

A tenant is one customer, or one business unit, of a shared system. NIST’s definition of cloud computing (SP 800-145) lists resource pooling as an essential characteristic: the provider’s resources are pooled to serve multiple consumers using a multi-tenant model. Multi-tenancy is the normal way cloud services work.

The AWS Well-Architected SaaS Lens describes three patterns:

• Silo: each tenant gets dedicated resources, such as its own infrastructure stack or its own database. This is single-tenant.
• Pool: tenants share resources, such as compute, storage and messaging. This is the classic multi-tenant model.
• Bridge: a mix, where some parts of the system are dedicated and others shared.

AWS also notes that even a silo is still software-as-a-service (SaaS) only when all tenants are onboarded, managed and updated through one shared operation. Separate copies of a product, each run and managed differently, are a managed service model rather than SaaS.

Single-tenant vs multi-tenant: the trade-offs

Isolation

In a multi-tenant system, isolation is a property of the software, so ask where it is enforced. Good designs enforce it in layers:

• Identity: every user and API key belongs to exactly one tenant, and the tenant is decided by the system, not by a value the user can change.
• Data: every record carries its tenant, and the data layer refuses requests that do not name one.
• Actions: automated actions, notifications and integrations run only with the tenant’s own credentials and targets.
• Audit: each tenant has its own record of who did what.

A single-tenant design gets most of this for free, which is why regulated customers often ask for it.

Noisy neighbors

The SaaS Lens describes a noisy neighbor as a user who places enough load on shared resources to degrade other users’ experience, and notes that multi-tenant workloads can be unpredictable. The usual fixes are per-tenant limits and throttling, separate tiers for heavy tenants, and moving the largest tenants to dedicated resources.

Compliance

Regulations rarely forbid multi-tenancy, but contracts, auditors and data residency rules sometimes require that a customer’s data stays in one country or on dedicated infrastructure. Even when shared infrastructure is allowed, you will be asked to explain how tenants are separated and to produce each tenant’s own audit trail.

Why a SIEM is a special case

A SIEM collects logs from every server, laptop, firewall and cloud account, and those logs contain usernames, internal addresses, file names and sometimes personal data. Mixing two customers’ logs, even in a search result, is a serious incident. Multi-tenancy in a SIEM has to cover more than data storage:

• Detections: each customer needs its own tuning and exceptions without breaking the shared rule set.
• Response actions: an automated block or account lockout must only ever touch that customer’s systems.
• Alerts and notifications: each tenant must receive only its own alerts.
• Compliance evidence: reports for HIPAA, PCI DSS or CMMC must come from that customer’s logs alone.
• Load: log volume spikes during attacks, which is exactly when a noisy neighbor hurts most.
• Endings: when a contract ends, the provider must export or purge that customer completely.

How SIEMs approach multi-tenancy

There are four common approaches, each with real strengths:

1. A separate SIEM per customer. Strong isolation and simple compliance, but every instance needs its own upgrades, tuning and monitoring, and analysts switch between consoles.
2. A cloud SIEM with one workspace per customer, managed centrally. Microsoft Sentinel, for example, lets a managed security service provider (MSSP) use Azure Lighthouse to manage customers’ Sentinel resources from its own Azure tenant, while each customer’s data stays in its own workspace. It is powerful and deeply integrated with Microsoft, but every customer needs its own workspace and connectors, and Microsoft has announced that Sentinel moves fully to the Defender portal after March 31, 2027.
3. An open source stack with tenancy added on top. OpenSearch Dashboards, for example, offers tenants, but they are spaces for saved objects such as index patterns, visualizations and dashboards. Keeping customers’ log data apart is a separate job for roles and permissions, and response and reporting per tenant are your own engineering project.
4. Native tenants built into the SIEM. The product separates data, users, detections, response and audit records per tenant on shared infrastructure, and usually lets you add dedicated servers for customers who need them.

Our guide to the best SIEM for MSPs has a 12-point checklist for testing these claims in a demo.

How UTMStack does multi-tenancy

UTMStack’s core is open source under AGPL-3.0, and its free Community edition serves one organization. Native multi-tenancy, federation and single sign-on are part of the Enterprise edition.

Native tenants on one server. In the Enterprise edition, each tenant has its own settings, users, alerts, integrations, response flows, audit records and AI usage, all on one server. Under the hood:

• Each tenant has its own web address, and the server decides the tenant from it.
• Every log is tagged with its tenant on arrival, based on the API key or connector that sent it.
• The data layer refuses to read or write tenant records unless the request carries a tenant.
• Notifications are scoped, so each tenant receives only its own alerts.
• Each tenant can have its own limit on AI assistant requests, so one customer cannot use up the server’s share.

Operating many customers. Tenant cards show each customer’s users, data sources, open alerts and AI usage at a glance. You can broadcast a message to all tenants, give your support team no access, read access or full access to a tenant, and terminate and purge a tenant cleanly when a contract ends. Your own name and logos, including dark-mode versions, can replace UTMStack’s on the console customers see. Staff sign in through SAML or OpenID Connect single sign-on, with custom roles, and multi-factor sign-in is required for every user.

Federation across servers. Customers who need their own hardware, region or capacity can have a dedicated UTMStack server, connected with the others to one federation console with consolidated alerts and logs. You can use multi-tenancy, federation or both.

UTMStack Cloud is single-tenant. Each UTMStack Cloud customer gets a dedicated instance, not a shared one, hosted on OVHcloud in the United States, Canada, the United Kingdom, France or Poland.

Every tenant gets the same detection and response: more than 600 rules mapped to MITRE ATT&CK, checked as each log arrives, automated response flows through the agent, and compliance reports from each customer’s own logs. UTMStack is priced per device, never by log volume, so one tenant’s noisy firewall does not change your bill. See pricing or the multi-tenancy page for details.

Frequently asked questions

What is a multi-tenant SIEM? A SIEM that runs many customers or business units, called tenants, on one platform, with each tenant’s logs, users, settings, alerts and response actions kept separate, and a central console for the provider.

Is multi-tenant less secure than single-tenant? Not necessarily, but it puts more weight on the software. Single-tenant isolation comes from separate infrastructure; multi-tenant isolation comes from how carefully the product scopes every request, action and record to a tenant. Ask the vendor to show where that scoping is enforced.

Is there an open source multi-tenant SIEM? UTMStack’s core is open source under AGPL-3.0, but native multi-tenancy is part of its paid Enterprise edition. Open source stacks built on OpenSearch offer dashboard tenants, with data separation configured through roles and permissions.

What is the difference between multi-tenancy and federation? Multi-tenancy runs many customers on one server. Federation connects many separate servers to one console. Providers often use both.

When should a customer get a single-tenant SIEM? When regulation, a contract or data residency rules require dedicated infrastructure, or when the customer is large enough to be a noisy neighbor on a shared server.

What is a noisy neighbor? A tenant whose load slows down other tenants on shared resources. Per-tenant limits, separate tiers and dedicated servers for the largest tenants are the usual fixes.

Sources

• NIST SP 800-145: The NIST Definition of Cloud Computing
• AWS Well-Architected SaaS Lens: Silo, pool, and bridge models
• AWS Well-Architected SaaS Lens: Noisy neighbor
• Microsoft Learn: Manage multiple tenants in Microsoft Sentinel as a Managed Security Service Provider
• OpenSearch documentation: OpenSearch Dashboards multi-tenancy
• UTMStack multi-tenancy and documentation
• UTMStack Cloud