Giving every technician the admin password “because it's easier” works until the day it doesn't — a wrong deployment, a curious browse through the wrong client's inventory, or a staff exit with the master key in their pocket. Roles and scope take half an hour to set up and quietly remove all three problems.
Endpoint Central's user management gives an MSP two separate controls that are often confused. A role decides what a user may do — which modules, and whether they get read, write or full control. A scope decides where they may do it — all computers, or only specific remote offices and custom groups, which in MSP work means specific clients. This page shows how to combine both so each technician's console contains exactly their clients and nothing else.
At the top sits Administrator — full control of every module, every customer, every setting. Keep this for one or two named senior people. Below it, predefined and custom roles let you shape jobs: a Technician with write access can deploy and fix; a Guest-style read role suits someone who only checks status and pulls reports; module-shaped roles (patch work only, inventory only, remote control only) fit larger teams. Privileges come in three grades — read (look), write (act on existing items) and full control (create and change the rules themselves) — and the right grade differs per module.
Scope is not only about hiding data; some powers stay with full administrators by design. Scope-based technicians typically cannot create test groups for patch approval or change system health policies — global rules that affect everyone stay central. Plan around it: let seniors own the global patch policy and test groups, and let scoped technicians run deployments inside their clients. This split is a feature — it means a junior cannot accidentally change the rules for ten clients while fixing one.
A workable pattern for a small provider: owner/senior = Administrator (two people maximum, named, with strong passwords and two-factor login). Field technicians = Technician (write) scoped to their clients, with remote control rights for support. Accounts or client-relationship staff = read-only scoped widely, enough to answer “are we patched?” without touching anything. Trainees = read-only, one client, until they earn write access. Every role should answer one question: what breaks if this account is misused? If the answer is “everything”, the role is too big.
Access rots quietly. Once a month, open the user list and check four things: nobody who left still has a login; every scope still matches the clients that technician actually serves; administrator count has not crept upward; and no shared accounts exist — the moment two people share one login, your audit trail and your accountability both disappear. Five minutes a month is the entire cost of keeping the MSP console trustworthy.
See Endpoint Central MSP running live — customers, offices and agents on one screen, step by step.
▶️ Watch Full VideoYes. Scope can be set to a single customer's remote offices, so that technician's console shows only that client. Scope can also be narrowed to a custom group — for example only the servers, or only one branch of a large client.
Read means the user can view that module's data. Write means they can act — run deployments, scans and remote sessions on existing setups. Full control means they can also create and change the underlying configurations and policies. Give each module the lowest grade the job needs.
Test groups and system health policies are global controls, so the product reserves them for full administrators rather than scope-based technicians. Have an admin create the test group once; the technician can still run deployments against it inside their scope.