A managed service provider holds privileged access to every customer it serves, so its own access control is a contractual promise, not an internal matter. The economics matter too: a PAM product that needs a separate instance for every customer multiplies infrastructure, patching and licence cost with every new logo.
This article describes how a multi-tenant PAM deployment works for an MSP or MSSP, what to design carefully, and what to test before you commit.
The two problems an MSP has
- Trust. Each customer needs confidence that your engineers reach their systems only when they should, with a record they can audit, and that nobody can see another customer's data.
- Cost to serve. One deployment per customer means one thing to patch, monitor, back up and license per customer. The marginal cost of the hundredth customer should be small.
Multi-tenancy addresses both, provided the separation is real and the commercial controls are enforceable.
What "multi-tenant" has to mean
- One running deployment, many customer tenants. Creating a tenant is a provisioning call, not a new instance to stand up.
- Every request carries a tenant context. There should be no privileged session, API call or record without one, and a user must not be able to widen their scope by passing another tenant's identifier.
- Per-tenant data. Users, roles, policies, resources, vault entries, recordings and evidence belong to a tenant.
- A cross-tenant view for you. Your platform administrators need to see licence status, usage and health across the whole book of business, without breaching tenant boundaries.
- Customer admins keep control of their own users, roles and identity source.
Logical and physical separation
Multi-tenant systems usually separate tenants logically: records are stamped with a tenant identifier on write and filtered by it on read, driven by the authenticated tenant context. That is efficient and is how most SaaS works. Some customers, such as those in defence, government or heavily regulated finance, require physical separation: their own database or instance.
The right answer is to offer both with the same product: shared deployment by default, and a dedicated instance for the customers whose policy requires it. Be wary of any platform where the dedicated option is a different edition with fewer features.
Commercial control per customer
When customers share a deployment, the licence has to be enforced per tenant, or you end up policing contracts by spreadsheet.
- A signed entitlement per tenant, defining ceilings for users, devices and managed resources, which feature modules the customer bought, and a validity window.
- An explicit lifecycle: not yet valid, active, grace, read-only, blocked. Customers (and you) know what each state allows.
- Safe degradation. If a customer's subscription lapses in the middle of an incident, audit, evidence and emergency access should stay readable. A licence problem should reduce commercial scope, not break a security control.
- Upgrades that do not silently remove capabilities from an existing tenant.
Onboarding a new customer
A repeatable runbook is the difference between a profitable MSP service and a project each time:
- Create the tenant through the provisioning API or the platform console.
- Redeem the entitlement the customer purchased.
- Seed the baseline: roles and permissions should be created automatically, with the customer's first administrator set up on first login.
- Connect their identity source (directory, SAML or OIDC), so their people use their own credentials.
- Register their resources by discovery scoped to their environment, then map each asset to the tenant before access is granted.
- Apply the baseline policy you hold for every customer, then tighten per customer.
- Connect their ticketing, so privileged access follows their change process.
- Hand over evidence access: their auditor's view of their own recordings and reports.
Know which steps are automatic and which are configuration. Templates for policies, workflows and compliance are often configuration, so budget operational time for them.
Access for your own engineers and for vendors
- Staff authorised across tenants without reusing customer passwords: your people sign in as themselves.
- Time-boxed grants per customer and task, not standing access to every environment.
- Agentless, browser-based sessions through jump hosts, so traffic is isolated per customer and no contractor keeps a VPN forever.
- Credential injection, so engineers never see customer passwords.
- Approval and ticket checks before a privileged window opens.
- Per-customer recording and command trails.
Evidence is a product you can sell
Compliance reporting becomes a recurring deliverable when evidence is per tenant. Each customer should be able to take their own record of who accessed their systems, when and what they did to their own audit, without seeing anyone else's. Many MSPs turn this into a monthly report.
What to test before choosing a platform
- Create two tenants and try to reach one tenant's data from the other, through the UI and the API, including by guessing identifiers.
- Check the cross-tenant console: can your administrator see licence status and usage across tenants, and can a tenant user see only their own?
- Lapse a licence in a test tenant and see what stays available.
- Measure onboarding: how long from signed contract to first customer session, with how many manual steps?
- Ask for the physical-separation option and confirm it is the same product.
- Test delegated administration: customer admins manage their own users, but cannot see other tenants.
- Export a tenant's evidence and verify it independently.
- Check what happens to a tenant's data when a customer leaves.
How ZenXPAM supports this
ZenXPAM is multi-tenant by design. One deployment serves many customer tenants, partner-hosted, customer-hosted or sovereign, and creating a tenant is a provisioning call. On creation it seeds the tenant's permissions and twelve default roles, and a first administrator is walked through a setup wizard. Each tenant redeems a cryptographically signed subscription key that sets user, device and resource ceilings, enabled feature modules and a validity window, with an explicit lifecycle (not yet valid, active, grace, read-only, blocked) in which reads, audit, evidence and emergency access keep working. A cross-tenant console shows licence and subscription status, tenant scope is enforced in the shared data layer, and where a customer requires physical separation we deploy a dedicated instance of the same product. Your engineers and vendors reach customer systems through the browser with credentials injected and jump-host isolation, under approval and ticket checks, and each tenant gets its own recordings, command trails and exportable evidence. See the MSP and MSSP solution or become a partner.
FAQ
Is one deployment for many customers safe? It can be, when every request carries a tenant context, scope is enforced in the data layer, and you have a dedicated-instance option for customers who need physical separation. Test the separation yourself.
What happens if a customer stops paying? The entitlement lifecycle should move the tenant through grace and read-only states while keeping audit, evidence and emergency access readable.
Can customers keep their own identity provider? They should. Each tenant connects its own directory, SAML or OIDC source.
How do we price this to customers? Per-tenant entitlements (users, devices, resources, modules) give you units to price against.
Can we give customers evidence for their own audits? Yes, and it is worth packaging as a recurring report.