Help Center › MSP multi-tenancy

MSP multi-tenancy

Run every client from one console: the tenant tree, switching clients with no re-login, the cross-client risk board, white-label reports, and the isolation guarantees that keep one client's data out of another's.

1 · The tenant model

Watchword organizes clients as a tenant tree:

The MSP is the root of the tree (your billed operator account).
Each client is a fully isolated child tenant with its own roster, campaigns, assignments, training progress, org name, brand color, and authorized send domains.
Only one client is active at a time. The Training, Templates, Simulator, and Program tabs all operate on the active client.

The demo tree ships with an MSP root ("Northwind Managed Security") over three clients: Acme Co, Bayside Dental, and Fjord Logistics.

Single-org users aren't affected. If you only have one organization, you simply work in the one active client. The MSP tree machinery stays out of your way.

2 · The one-pane tenant tree

Open the MSP console tab (the first tab). The left panel is the Tenant tree:

The MSP root is shown at the top with the beacon mark.
Below it, each client appears as a button with its brand-colored dot, name, and people count.
The currently active client is highlighted, and a line beneath confirms: "The Training / Templates / Simulator / Program tabs now operate on this client only."

3 · Switch clients — no re-login

Because the whole tree is your operator context, you move between clients instantly:

In the MSP console, click a client in the tenant tree (or click Open on its row in the risk board).
Watchword swaps that client's roster, campaigns, assignments, and training progress into the active context and confirms with a toast ("Switched to … (isolated context)").
Every other tab now reflects that client. There is no sign-out and sign-in — switching is a single click.

Why no re-login is safe. When you're signed in, MSP-tier entitlements are scoped by Keystone to your verified session's tenant — your MSP root. You can switch among the clients in your subtree, but the platform won't let any session reach a tenant outside it. See Isolation guarantees and Entitlements.

4 · The cross-client risk board

The right panel of the MSP console is the Cross-client risk board — one row per client you're authorized to see, so you can triage your whole portfolio at a glance.

Portfolio totals

Above the table: Clients, People, High-risk, Overdue, and Campaigns summed across the portfolio. These are aggregates of aggregates — still no recipient-level data.

The per-client rows

Column	Meaning
Client	The client name with its brand dot.
People	Roster size.
Phish-prone	The client's org-wide phish-prone %, color-banded.
High-risk	How many people are in the High band.
Completion	Training completion %.
Overdue	Overdue assignments.
Open / Report	Open switches to that client; Report opens its white-label report.

Sorting the board

Use the dropdown to sort by phish-prone %, number of high-risk people, overdue training, or completion %. This is how you decide which client to work on first.

Aggregates only — by design. Each row is computed from that client's own data slice. No recipient row, event, or capture from one client is ever read while computing another client's numbers.

5 · White-label client reports white_label

Hand a client a report that's branded as theirs, not yours:

On the risk board, click Report on a client's row.
A report opens rendered in that client's own brand color, headed with the client's name and a "prepared by [your MSP]" line.
It summarizes People, Campaigns, Phish-prone %, Completion %, and High-risk count — and states plainly that it contains no data from any other client tenant.
Click Print / save PDF to deliver it.

White-label scoping uses each client's own brand, never the MSP's. The white_label entitlement governs branded exports at the cloud tier; see Entitlements.

6 · Isolation guarantees

Strict client isolation is a core promise. Here's exactly how Watchword enforces it:

Guarantee	How it's enforced
One client's data is never visible while another is active	Only the active client's slice is loaded into the working state; switching swaps it in and out.
Reading a client for the board never merges data	The board reads a defensive copy of only the requested client's own slice — never a merge, never the active client's working data.
You can't reach a tenant outside your MSP subtree	An authorization gate refuses any tenant that isn't your MSP root or one of its direct client children — it throws rather than returning data.
The cross-client board exposes no cross-tenant PII	It returns aggregates only (counts + risk bands). No recipient-level event or capture ever crosses a client boundary.
The cloud tier mirrors the same boundary	Each client syncs under its own scoped store key, and Keystone derives the tenant from the verified session server-side — a product can't assert another tenant.

These isolation properties are asserted by the project's verify suite. See Security & privacy for the full picture.

Deferred for MSPs: live multi-tenant send and PSA billing sync (ConnectWise / Autotask / Halo). The tenant model and entitlements are in place; the live per-client send rides the deferred send runner. See Sending safely.

← Risk scoring Next: Sending safely →