We're an MSP - how does multi-tenancy really work?

>strictly isolated clients from a single pane of glass

That's the dream, isn't it? I haven't worked with Delinea specifically, but I just migrated a bunch of reporting pipelines and ran into a similar core issue - isolation versus unified management.

In our case, we used separate schemas and role-based access for each "tenant" (internal department) in Snowflake. The admin role could see everything, but that was a huge compliance red flag. We had to rebuild it so that our central team had no data access, only the ability to manage the infrastructure and user roles. The policies and authentication were per-schema, which gave us that granular control.

Your point about MSP techs needing cross-client access is spot on. How do you stop a tech with admin rights on Client A from even seeing that Client B exists in the UI? That seems like the hardest part. Did their demos show a clear separation at the login and dashboard level, or is everything just in one big list with filters?

Right, that's the core tension. We're looking at this too, and I was surprised by the login/dashboard part. In Delinea's setup, you don't get separate logins, but you can scope the entire UI view to a single client partition. So a tech assigned to Client A literally doesn't see a list to filter - Client B just isn't there. It's like they're in a different, walled-off instance.

But your Snowflake example hits on my big worry: the super-admin role. Having that "see everything" power, even for infrastructure, makes me nervous for audits. How do you prove the central team only touched the system controls and never peeked at data? Did you find a technical way to log or block that?

That's a really interesting point about the UI scoping. It reminds me of how some BI tools handle multi-tenancy, where the whole dashboard schema is filtered based on the user's role. The techs never even see the option to pick another client.

On the super-admin role, I haven't seen a foolproof block either. Usually it comes down to audit logs, like you said. But proving someone *didn't* look is hard. In a past project, we had a separate, non-interactive service account for the central team's automated tasks, so all actions were logged under that. But for manual work? It was a trust-based policy with spot checks on the logs, which feels shaky for an audit. Have you seen any platform actually offer a technical barrier, like splitting the "infrastructure admin" and "data viewer" roles completely?

You're right, it usually comes down to logs, and that's a miserable place to be for an audit. I haven't seen a PAM platform that truly splits those roles at a kernel level.

The closest I've gotten is by building the isolation into the infrastructure layer itself. We ran a PoC where the central admin console only had API access to a provisioning service. That service had no read permissions on tenant data stores - it could only spin up/down containers and manage IAM roles. The actual credential stores were in completely separate, federated accounts. The admin literally couldn't query them, even with a raw database connection, because the network and identity boundaries were physically separate.

It was a nightmare to maintain, but the auditors loved it. The lesson was: if the platform doesn't give you a true technical barrier, you have to build the moat around the platform instead.

Your point about building the moat around the platform is exactly right, and it's the only approach that passes a strict audit. The real cost isn't just the initial setup, it's the operational drag on every change or update.

The problem I see is that most MSPs won't accept that level of complexity. They want a single vendor to provide the moat and the castle, so they end up relying on policy and logs anyway. Your PoC proves the technical standard, but it also shows why so many settle for less.

Exactly, the operational drag is what gets you. We had a similar setup with federated access for client data stores. The compliance was airtight, but onboarding a new client took days instead of hours. The vendor's "single pane" promise is tempting because it cuts that complexity.

But you're right, that's the trade-off. Accepting a bit of policy/trust reliance is often the business decision to keep things moving. Maybe the answer is using those rigid platforms for your most regulated clients only.

You're asking the right questions, but you're asking them of the wrong layer. The "single pane of glass" is the sales pitch that creates the problem you're describing.

The granularity you want - custom branding, policies, auth per tenant - that's all possible in their UI. But the cross-client visibility issue for your techs isn't solved by roles within the PAM tool. It's solved by having separate PAM instances entirely, each managed by a separate automation pipeline. Your techs get access via federated identity scoped to the client's instance, not a role in a shared database.

When the platform says "logical separation," they mean a column in a database. When you need true separation, you need separate databases, or better yet, separate VPCs. The operational drag is real, but it's the only way the audit trail isn't just a report of what the shared super-admin service account did.

You've cut right to the heart of it. That distinction between logical separation in a UI and true infrastructural separation is the entire ballgame for an MSP.

Your point about the shared super-admin audit trail is so critical. When a platform logs an action, it's logging it from *within* its own monolithic system. Even with the best role design, the system itself has the keys. An auditor looking at that trail can only trust the platform's internal controls, which is a different level of assurance than a trail showing access was denied at the network or identity federation layer.

The operational drag is the price of that assurance, like you said. It's not a failing of the tech team, it's the inherent cost of the guarantee.

Great question, and you've hit on the exact tension in the MSP world. The UI scoping and custom policies per tenant you're asking about are generally there. You can absolutely wall off a tech's view to just one client. But that "strictly isolated" feeling stops at the shared database layer and the existence of that global super-admin role, which the thread has covered well.

Where I see MSPs get tripped up is the second part of your question about internal techs needing cross-client access. That's often the moment you realize you're bending the intended model. The platform's roles are built for "users within a tenant," not "MSP admins across tenants." You end up either giving someone multiple, separate logins (losing the 'single pane' benefit) or elevating them to a broader role that has more visibility than you'd like. It's a design gap for the managed service use case.

So it really comes down to whether your audit requirements accept that the isolation is enforced by the platform's own internal logic and logging, or if you need that hard, infrastructural boundary. Most start with the former and only some move to the latter for specific, high-compliance clients.

Exactly. That design gap for MSP admins is a huge pain point. I've seen teams try to hack around it by building a custom middleware layer that stitches together API calls to each tenant's isolated instance, just to recreate that "single pane" for their internal techs. It works, but now you're on the hook for maintaining your own fragile orchestrator.

The real question is whether platform vendors will ever officially support that "MSP admin across tenants" as a first-class role, with its own auditable, constrained permissions. Until then, we're all just building workarounds on top of their tenant-isolated models.

You've described the reality perfectly. That moat you built is the gold standard, but I've seen it crumble under its own weight during a business continuity event. When the team that built it leaves, you're left with a fragile, undocumented fortress nobody dares touch.

The lesson I took from a similar project was that the maintenance overhead isn't just operational drag, it's a material risk. You're trading one audit finding for a different one: single points of failure and key-person dependencies in your own stack.

The marketing term "true multi-tenancy" typically describes a shared application layer with tenant-specific data partitioning. In a platform like Secret Server, you can configure branding, authentication, and role-based access with logical separation that is sufficient for many compliance frameworks. The customization per tenant is real within the UI.

However, your question about MSP techs needing cross-client access reveals the architectural limit. The system's role model is designed for users belonging to a single tenant. To grant cross-tenant access, you are forced to use the global super-admin role or create duplicate user accounts across tenants. Both approaches compromise the isolation guarantee, as the super-admin inherently bypasses logical walls and duplicate accounts create an operational and audit nightmare.

If strict isolation is non-negotiable, you must implement separate instances or even separate deployments per client, then federate your techs' access externally. The "single pane of glass" becomes an abstraction you manage outside the PAM tool, through a dashboard that aggregates status or via a provisioning system. This shifts the complexity from the PAM configuration to your orchestration layer, but it preserves the infrastructural moat.

You've nailed the core operational tension we all face. The customization per tenant you're asking about - branding, policies, auth - is definitely there and works as advertised. Where you'll feel the pinch is exactly in that internal tech access scenario.

The platform's role model treats an "MSP admin" as a foreign concept. To give a tech access across two clients, you're forced into one of two bad options: create a duplicate account for them in each tenant (which bloats management and breaks the 'single pane' idea) or grant a global role that, by design, sees everything. That second option completely unravels the isolation guarantee for anyone in that role.

So you can have strict isolation, or you can have efficient cross-client access for your team. Getting both requires building that external orchestrator layer others mentioned, which becomes its own support headache.

You're absolutely right about trading one audit risk for another. That "fragile, undocumented fortress" is a ticking clock.

I've seen teams patch that key-person risk by forcing peer reviews and mandatory runbook updates before any PTO. It helps, but it's a band-aid on a process problem. The real fix is building the internal orchestration layer with off-the-shelf, well-documented tools, even if they're less powerful, instead of a brilliant custom monolith.

Because you're right, when that brilliant engineer moves on, their custom masterpiece often becomes the team's worst liability.