Guest blog courtesy of Augmentt.
One of the less visible bottlenecks in growing an MSP is the concentration of Microsoft 365 administrative tasks at the senior technician level. Password resets, MFA changes, new user provisioning, and basic account management shouldn't require a senior engineer, but in many shops that's exactly who handles them, because giving junior techs full admin access feels like too much of a risk.
It's a real tension, and it's a security problem before it's a staffing problem. Junior technicians need enough access to do their jobs. Full admin rights to a client's Microsoft 365 tenant create exposure that has nothing to do with how careful or well trained that technician is, from an accidental misconfiguration to a much larger blast radius if that one account is ever compromised. Across a book of fifty client tenants, the fix isn't choosing between operational speed and security. It's building access control the same way MSPs build everything else they want to scale: once, consistently, across every tenant and every technician.
Why Over-Permissioned Access Is a Problem
The principle of least privilege, granting users only the access they need to perform their specific role, is foundational to security practice. It's well understood in theory. In MSP environments it's frequently violated in practice, because configuring granular access per technician per tenant is more work than most teams are willing to do by hand, one tenant at a time.
The result is that many MSPs operate with a small number of Global Admin accounts that multiple technicians use interchangeably, or with a tiered access model that exists on paper but not in the console. When a junior tech needs to reset an MFA token at 9pm, someone shares credentials or the client waits until morning.
Over-permissioned accounts carry compounded risk. A compromised technician account with Global Admin rights across fifty client tenants is a catastrophic breach across the entire book of business, not an inconvenience at one client. And beyond the immediate risk, broad access without a consistent audit trail makes it difficult to reconstruct what happened when something does go wrong, in any of those tenants.
What Effective RBAC Looks Like for MSPs
A practical RBAC model for an MSP technician team typically maps to the tiered support structure already in use. The model only works if the same access rules apply to every technician in every client tenant, with no golden tenant that gets configured carefully while the other forty-nine drift on their own.
Level 1 technicians handle routine requests: password resets, MFA token resets, account unlocks, basic group membership changes. These tasks need specific permissions, not broad administrative rights. An L1 tech should be able to reset MFA for a user in any client tenant without ever opening the Global Admin console.
Level 2 technicians handle more complex tasks: user provisioning and deprovisioning, policy adjustments, license management, and device compliance checks. Broader access than L1, but still scoped to specific capabilities rather than unrestricted admin rights.
Level 3 and senior engineers handle architecture-level changes, security baseline modifications, and anything that affects client configurations at scale. Full or near-full admin access is appropriate here, with strong MFA and audit logging in place.
Built once, this model applies to the next client the same way it applied to the last one. That is what lets technician capacity, not payroll, set the pace of growth.
Guided Workflows as a Safety Layer
RBAC alone limits the blast radius of a mistake or a compromise. Guided workflows take this further by making sure that even within their permitted scope, technicians follow the right process every time.
A guided MFA reset workflow, for example, walks the technician through the steps required: verifying the requester's identity, logging the reason for the reset, confirming the action, without requiring them to open a Microsoft admin portal directly. The technician completes the task correctly without needing deep product knowledge, and the action is logged and attributable back to that technician, in that tenant, at that time.
This matters most for MSPs with high technician turnover or teams where M365 expertise varies a lot from one hire to the next. The workflow enforces the same standard regardless of who is running it.
The Operational and Business Case
Properly implemented RBAC has a direct impact on technician capacity, not just risk. When L1 technicians can resolve the full scope of routine requests on their own, without escalating to a senior engineer for credential sharing or portal access, ticket resolution times drop and senior staff are freed for the work that actually needs their experience.
Augmentt
Secure Autopilot is built around this exact model. Instead of a shared Global Admin login, each member of the technician team is set up as a system user, and every feature in the console can be scoped to disabled, read-only, or manage access on a per-user basis. Company-level scoping then determines which client tenants that permission applies to, whether that's a single client or the whole book of business, so an L1 tech can be granted manage access to password resets and MFA across every tenant while staying locked out of Global Admin entirely.
Routine actions like resetting MFA or issuing a temporary access pass happen in one click from inside Augmentt, with no need to open the native Microsoft 365 admin portal at all. Every action is logged, and Augmentt's alerting flags things like password resets, role or group changes, and access granted outside of Privileged Identity Management as they happen, so there's a consistent record across every tenant instead of one that depends on which technician was on shift.
That same activity log is also what shows up in the client-facing report at the next QBR: proof of who touched what, when, and under what role. That is the kind of detail that turns access governance from a background IT task into something the client can see, and be billed for.
The goal isn't to restrict what junior technicians can do. It's to give them exactly what they need to do their jobs well, safely, and with a record to show for it. That's good security practice and good operational design, and once it's built, it scales to the next client the same way it worked for the last one.
