What is a multi-tenant SOC for MSPs?

A multi-tenant SOC monitors several clients’ environments on one platform, with each client in a strictly separated space: its own data, alerts, rules and reports. For an MSP, it provides a consolidated view of all its clients, with rights that vary by team member. It is the architecture that makes a SOC for MSPs possible.

This article is part of our series on managed SOC. For the general principle, see SOC for MSP: what it is and how it works.

The principle

A “tenant” is an isolated space within a shared platform, like a tenant in a block of flats. In a multi-tenant SOC:

• each client is a tenant: its sources (EDR, Microsoft 365, firewalls) feed into its own space, and nowhere else;
• the MSP sees all its tenants from a single console;
• the SOC runs every tenant with the same analysts and tools.

Why it matters for an MSP

Without a multi-tenant platform, an MSP protecting 30 clients would juggle 30 consoles, 30 sets of alerts and 30 report formats. Multi-tenancy brings:

• an overview: which clients have open incidents, which are stable;
• per-client reports the MSP passes on to its clients;
• fast onboarding of each new client, with no new infrastructure;
• detection that benefits everyone: an attack technique seen at one client strengthens detection for the rest.

For the consumption model that goes with it, see What is SOC as a service?.

The two things to check first

1. Separation between clients

One client’s data must never be visible in another’s space. That covers collected events, alerts and reports, but also accounts: a team member should only see the clients they work on. Ask how separation is enforced and checked.

2. Console access security

A console that opens up every client of an MSP is a prime target: compromise it and you reach all clients at once. That is the supply chain pivot attack scenario: Article 21 of NIS2 lists supply chain security among the cybersecurity risk-management measures. Expected protections:

• mandatory multi-factor authentication;
• least-privilege rights for each team member;
• an audit trail of actions in the console.

We explore this risk in NIS2 Directive: obligations, risks and growth levers.

What the Cyna platform offers

The Cyna platform is built for MSPs:

• one console for all clients, all alerts and all service commitments;
• strict separation, with granular permissions per team member: each client, its own scope;
• monthly activity and vulnerability reports, exportable as CSV or PDF, white-labelled.

For the day-to-day split of roles, see Managed SOC and MSP: who does what?.

Questions to ask a provider

1. How is each client’s data separated, technically and in access rights?
2. Can different team members at the MSP have different rights?
3. Is multi-factor authentication mandatory for console access?
4. Are actions taken in the console logged?
5. Can reports be produced per client, branded as the MSP’s own?
6. How long does it take to add a new client?
7. What happens to a client’s data when it leaves the platform: export, retention period, deletion?

The last question is often forgotten. Clients change over time: some are acquired, others move to another provider. A clear answer on how a tenant is closed, which data can be exported and how long logs are kept afterwards avoids awkward discussions later, and helps the MSP answer its own clients’ questions on data handling. It is also a good moment to check who, at the MSP, is allowed to request the closure of a tenant.

Multi-tenant does not mean one-size-fits-all

Sharing a platform does not mean every client is monitored identically. A good multi-tenant SOC applies a common baseline, then adapts to each client: a client with staff abroad will not trigger the same sign-in alerts as one that only works from the UK; a client using a specific admin tool will have it whitelisted. That tuning is part of onboarding and continues over time.

Talk to an expert

Are you an MSP who wants to see the multi-client console in action? Get in touch for a demo, or visit our Partner programme page.

Frequently asked questions

Can my clients access the platform?

It depends on the platform and the MSP's choice. Where the MSP owns the client relationship, it usually shares reports with its client rather than opening the console to them.

Are detection rules the same for every client?

A common baseline applies to all, then per-client tuning reflects each context: tools used, working hours, countries of operation, legitimate exceptions.

Does an incident at one client benefit the others?

That is one benefit of the shared model: an attack technique seen at one client can be used to strengthen detection for the others, without that client's data being shared.