A managed services provider is, from a security standpoint, a concentration of other people's risk. Its engineers hold privileged access into dozens of client environments simultaneously - servers, databases, network gear belonging to organisations that compete with each other, answer to different regulators, and each have the contractual right to ask exactly who touched their systems and what was done. One provider, many perimeters, and a laptop fleet whose stored credentials would interest any attacker who understands where the leverage is.
The MSP access problem in practice
Three structural risks define the model. First, cross-client bleed: an engineer context-switching between environments all day, with connection profiles and credentials for every client resident in local tools - one wrong window, or one compromised laptop, away from a multi-tenant incident. Second, staffing churn against client scope: engineers join, leave and rotate across accounts constantly, and every rotation should mean precise access changes in multiple client environments - which, handled manually, it rarely does. Third, evidentiary obligation: clients' auditors increasingly reach through to the provider, and "trust our engineers" is no longer an accepted answer to "show us the sessions".
Why per-client VPNs and credential sheets fail
The traditional MSP toolkit - a VPN profile per client, credential spreadsheets per account, and tribal knowledge about who works on what - fails each risk in turn. VPNs grant network presence rather than scoped sessions. Distributed credentials cannot be retrieved from a departing engineer's memory or a stolen laptop's disk. And nothing in the arrangement produces per-client evidence: when a client audit asks for last quarter's privileged activity on their systems, the provider assembles it from fragments, per client, forever.
The Tanflow approach: tenancy as an access-control structure
Tanflow's MSP solution positioning names the constructs directly: per-client connection groups, engineer-level access boundaries, and SLA-ready session reports. The mechanics come from the PAM platform applied to the multi-client shape:
- Per-client connection groups organise targets by client, so each client environment is a bounded set within the platform rather than an undifferentiated pool of hosts.
- Engineer-level boundaries come from PAM's roles and access control: each engineer's portal shows exactly the client groups their assignments entitle them to - and nothing else. Rotating an engineer between accounts is a role change executed once, effective everywhere.
- Credential custody moves from laptops to the vault: client credentials are encrypted, rotated and injected into sessions, so the engineer's device holds nothing, and a departure or a device theft compromises nothing.
- Uniform session discipline applies across every client's stack through the zero-agent gateway - SSH, RDP, Kubernetes and fifteen-plus database clients - with full recording and real-time command control on each session, and per-client policy strictness where client requirements differ.
- SLA-ready reporting falls out of the audit store: every session already carries its client group, engineer, timestamps, recording and command log, so per-client activity reports are filters, not projects.
The operating rhythm
- A new client environment is onboarded as a connection group; its credentials go into the vault on day one.
- Engineers are assigned by role; their portals update; no credentials are distributed.
- Daily work runs in recorded, policed browser sessions - context-switching between clients is switching portal entries, not juggling credential sets.
- Monthly, each client's report is generated from the store: sessions, engineers, durations, notable command events.
Enterprise scenario
Consider an IT services organisation whose banking client demands evidence of all privileged access to its environment, quarterly, with named engineers - a contract term, not a courtesy. On-platform, the quarterly deliverable is a filtered export: every session against that client's connection group, each attributed to a federated engineer identity, each replayable on request. The same week, an engineer rolls off that account to another; one role change removes the client group from their portal - and the client's next report shows the boundary held.
Security and audit implications
Structured tenancy converts the MSP's central risk - concentration - into its central control. Cross-client exposure narrows to explicit role assignments; the stolen-laptop scenario deflates because laptops hold nothing; and the provider's answer to client due-diligence questionnaires becomes a platform description with reports attached. For providers serving regulated sectors, the same session evidence feeds each client's own framework obligations - the mappings Tanflow publishes across RBI, ISO 27001, HIPAA and beyond apply per client, from one deployment.
Conclusion
An MSP cannot avoid holding many clients' keys; it can stop scattering them. With per-client connection groups, engineer-level boundaries, vaulted credentials and per-session evidence, Tanflow PAM turns the provider's access model into something no spreadsheet ever was: bounded by design, provable by report, and safe to show any client's auditor.