The fastest way for an MSP to lose a client is to show them another client's data — or worse, push another client's software onto their machines. Separation in Endpoint Central MSP is not a setting you toggle at the end; it is an architecture you build from the first customer you add.
One console for all clients is the whole point of the MSP edition — and the whole risk. If the structure is loose, a patch job aimed at Client A can include Client B's machines, and a report can carry the wrong company's computer names. This page shows how the separation actually works in Endpoint Central MSP: customer containers, office-level scopes, technician restrictions and naming discipline, plus the audit habits that prove the walls hold.
Every client company gets its own Customer entry under Admin → Customers, and every computer they own lives inside that customer's remote offices. Never park two small clients inside one customer “to save time”. The customer is the boundary for reports, for most views and for your own thinking. Two clients in one container means every report needs manual filtering forever — and one day that filter will be forgotten on exactly the report a client reads closely.
Containers organise the data; scope controls the people. When you create a technician user, assign a role (read, write or full control per module) and limit the scope to the remote offices or custom groups that technician actually serves. A scoped technician browsing the console sees only their clients. This matters beyond confidentiality: it stops honest mistakes. A technician who cannot see Client B cannot accidentally select Client B's machines in a deployment window at 7 pm on a tiring day.
Use the client's own words in customer and office names — “Bright Future School — Main Campus”, not “BFS-01”. Reports carry these names, screenshots in tickets carry these names, and when a client calls about “the accounts office PCs”, your team should find that exact office in seconds. Consistent naming is also a safety feature: in a list of similar deployment targets, the clearly named one is the one nobody mis-clicks.
Software packages, patch approvals and configurations should be created and targeted per customer or per office, never as one giant “all computers” job across clients. Client A's licensed accounting package must not exist as an install option for Client B. Per-client targeting also protects patching: if a patch breaks something at one client, pausing that client's deployment does not freeze everyone else's security updates.
See Endpoint Central MSP running live — customers, offices and agents on one screen, step by step.
▶️ Watch Full VideoNot through normal console access. Clients do not log into your MSP console at all — they receive reports you generate per customer. Inside your team, technician scope decides which customers each staff member can see, so a technician serving two clients has no window into the rest.
Yes, but it is manual work: create the new customer and offices, move the agents' remote office, and rebuild that client's configurations and report schedules. It is far cheaper to create separate customers from day one, even for a five-PC client.
Generally no. The MSP model works because your team operates the console and clients consume reports and raise requests. If a large client genuinely needs live visibility, discuss it as a contract item and use a tightly scoped, read-only style role — never a shared admin login.