MSPs should treat onboarding as a governance exercise, not just a technical setup. Every user, including interns and apprentices, needs training on how the platform works, what policies apply, and where exceptions are not acceptable. This builds consistent execution across the team and reduces the chance that security controls are bypassed through informal practices or uneven knowledge.
Why onboarding on a shared platform is a governance control, not a login task
When MSPs put staff onto a shared access and management platform, the real risk is not the initial account creation, it is inconsistent use of a system that can reach many client environments. Onboarding should establish who may approve access, what actions are allowed, how exceptions are handled, and what evidence must exist when someone uses elevated capability.
This is where onboarding and access governance meet. Staff need to understand whether an action is permitted because of role, client approval, ticket context, or emergency process, and they need to know that informal workarounds are not a substitute for policy. Good onboarding reduces reliance on tribal knowledge and makes the platform behave the same way across teams and clients.
For MSPs, that discipline is the difference between controlled shared administration and a platform that becomes a shortcut for bypassing review. A shared tool can be secure in design and still be used unsafely if each new starter learns it differently or inherits habits from the previous team.
Done well, onboarding also reinforces separation of duties. The person who can provision access, the person who can approve access, and the person who can use access should not be treated as interchangeable just because the platform makes all three actions possible.
See also IAM and IGA Basics for the underlying access-governance model, including provisioning, entitlement control and access reviews, which are the natural foundation for MSP onboarding.
What staff must learn before they can be trusted on the platform
Onboarding should cover the operating rules of the platform, not just the interface. That includes how identities are provisioned, how role assignment works, what approval evidence is required, which actions are logged, and which steps are prohibited even when a request seems urgent or low risk.
New joiners also need practical context on shared access patterns. In an MSP environment, one mistake can affect multiple customers, so staff must understand client separation, change control, ticket hygiene, and the difference between routine administration and privileged intervention. If the platform supports temporary elevation, the conditions for using it should be explicit from day one.
Training should be role-specific. A first-line analyst, a platform administrator, and a delivery lead do not need the same depth, but they do need the same policy baseline. The key is that no one is allowed to infer policy from what they see others doing, especially in a high-pressure support environment.
See also Joiner-Mover-Leaver (JML) Guide for a practical view of onboarding as part of the broader identity lifecycle, where access is granted, changed and later removed under a consistent process.
See also Identity Security Programme Guide for how onboarding fits into governance, RACI, and operating model decisions across people, systems and delegated access.
How to make onboarding durable instead of ceremonial
MSPs should treat onboarding as an auditable control, not a one-time orientation. The practical test is whether a new starter can explain the policy, follow the process, and demonstrate safe use without being coached live by a colleague every time they face an exception.
A durable programme usually combines three things: documented training, confirmation of policy acknowledgment, and supervised first use of the platform. That sequence matters because it exposes misunderstandings early and gives managers a clear point at which to stop informal access. If someone cannot work within the approved process, the answer is to pause access, not to relax the process.
It also helps to connect onboarding with periodic reinforcement. Shared platforms drift when staff rely on memory, especially after role changes, incidents, or new client requirements. Refreshers, access reviews, and exception tracking keep the platform aligned with current practice instead of allowing custom habits to accumulate.
See also Privileged Access Management Guide for the control patterns that matter most when the shared platform grants elevated access, including just-in-time use, session control, and privileged review.
Risk and Threat Considerations
Shared access platforms concentrate operational power, so weak onboarding can quickly become a security exposure. If new staff are not trained on policy and exception handling, they are more likely to use informal approvals, shared credentials, or workarounds that weaken accountability across multiple client environments.
Failure mechanism: Inconsistent training creates inconsistent behaviour, and inconsistent behaviour turns a controlled platform into a source of privilege creep, unauthorized access, and weak audit evidence. In an MSP context, the same mistake can propagate across many tenants or customers.
Impact: The result can be unauthorized changes, poor traceability, difficult incident investigation, and broader client exposure if one user’s mistake or shortcut affects shared administration paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Onboarding shared platform users requires controlled credential handling and lifecycle discipline. |
| AC-6 — Least Privilege | MSP onboarding should limit staff to the minimum platform access needed for their role. | |
| PS-7 — External Personnel Security | Shared MSP environments often involve contractors, apprentices, and other non-standard staff categories. | |
| Recommendation — Define credential issuance, rotation, and revocation steps before granting platform access. Assign only the minimum access needed for each onboarding role and review exceptions. Apply onboarding checks and access conditions consistently to all external or contingent staff. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shared platform onboarding is fundamentally about governing who may access and act on systems. |
| A.5.16 — Identity management | New staff onboarding depends on creating and managing user identities correctly. | |
| A.6.3 — Information security awareness, education and training | The question centers on training staff to use the shared platform safely and consistently. | |
| Recommendation — Document access approval, role assignment, and exception handling for platform users. Tie onboarding to identity issuance, role assignment, and timely revocation. Train every new starter on platform rules, approved workflows, and prohibited shortcuts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Onboarding on a shared platform requires disciplined account setup and oversight. |
| CIS-6 — Access Control Management | MSPs must govern who can do what on a shared platform and under what conditions. | |
| Recommendation — Standardize account provisioning, privilege assignment, and removal for all platform users. Enforce role-based access and exception handling before granting platform use. | ||
Practitioner Guidance
What to prioritise: Build onboarding around policy comprehension and safe execution, not product walkthroughs. If a new starter can click through the platform but cannot explain approval rules, exception boundaries, and escalation paths, they are not ready for independent use.
What to verify: Confirm that each user has completed platform training, acknowledged the operating policy, and demonstrated the correct process for at least one routine task and one exception scenario. If the platform supports elevated actions, verify that the user understands when human approval is mandatory.
Common mistake: Treating experienced hires as already trained because they have used a similar platform elsewhere. In shared MSP environments, local policy, client segregation, and exception handling matter more than generic familiarity.
Practitioner takeaway: The onboarding goal is consistency, not convenience, if every user follows the same rule set from day one, the platform is far less likely to become a bypass around governance.
