Skip to main content

That's a wrap! See all the announcements and debuts in our NerdioCon 2026 recap!

Nerdio Manager for MSP

Moving beyond Global Admin: a practical guide to least-privilege Microsoft 365 management

July 22, 2026 | 6 min read

A Conditional Access policy can remain in report-only mode for days without disrupting anyone. Once it's enforced, every assumption behind that policy is tested. An overlooked administrative account or a missing exclusion can quickly turn a routine configuration change into a tenant lockout. 

Microsoft's June 15 Conditional Access enforcement change didn't create that risk, but it did put Conditional Access back on many MSPs' radar. If your Conditional Access policies target "All resources" with app exclusions, it's worth reviewing which applications are excluded and whether those exclusions still make sense. 

Most MSPs adopted Global Admin because it made day-to-day administration easier. Engineers spent less time dealing with permission issues, and the same credentials worked for nearly every Microsoft 365 task. Over time, that convenience became standard practice across many environments. 

The problem is that Global Admin was built for tenant-wide administration, not routine operational work. A compromised account provides unrestricted access, while a Conditional Access policy applied too broadly can leave administrators locked out of the tenant they're trying to manage. 

Fortunately, most routine Microsoft 365 administration doesn't require Global Admin. Built-in roles already cover many common management tasks, making it practical to reserve Global Admin for the relatively small number of changes that truly require tenant-wide access. 

Most day-to-day administration doesn't require Global Admin 

Global Admin has a way of becoming the default. Once every engineer can complete nearly every Microsoft 365 task with the same account, permission requests disappear, and work moves faster. It's an easy system to maintain, especially when you're supporting multiple customer tenants. 

The tradeoff is that routine administrative work starts using the same level of access that's intended for tenant-wide changes. Microsoft 365 already provides built-in roles for many everyday tasks. User Administrators manage accounts and licenses. Helpdesk Administrators handle password resets, while Exchange, Teams, Intune, and SharePoint administrators can work within their own services without inheriting unrestricted access to the rest of the tenant. 

Global Admin still belongs in every Microsoft 365 environment. It just doesn't need to be involved in every administrative request. Most day-to-day work can be completed with role-specific permissions, leaving Global Admin accounts available for tenant-wide configuration and identity management. 

That shift also limits the impact of compromised credentials or configuration mistakes. If an account only has access to the services required for its role, the potential impact is much smaller than it would be with unrestricted tenant access. 

Common administrative task

Recommended Microsoft 365 role

Password resets and user management

User Administrator or Helpdesk Administrator

Exchange administration

Exchange Administrator

Microsoft Teams administration

Teams Administrator

Intune device management

Intune Administrator

SharePoint administration

SharePoint Administrator

Tenant-wide identity and security configuration

Global Administrator

Treat Conditional Access changes like any other production change 

Few Conditional Access policies are built all at once. Most evolve over time. A new control gets added during a security review, another policy expands to cover additional users, or an old exclusion finally gets cleaned up. Small changes have a way of accumulating, which is exactly why they deserve the same level of planning as any other production change. 

Report-only mode is the right place to start because it shows how a policy would behave without interrupting access. It's a chance to confirm assumptions before those assumptions become production settings. 

From there, the process should slow down—not speed up. Test the policy with a dedicated administrative account. Verify that a break-glass account remains outside the policy. Review the results, make adjustments if needed, and only then move the policy into enforcement. Those extra steps rarely add much time to the rollout, but they can prevent a recovery exercise that takes far longer. 

Recommended rollout sequence

Purpose

Configure the policy in report-only mode.

Review how the policy would affect users and administrators without blocking access. 

Validate with a dedicated test account. 

Confirm expected behavior before expanding the policy. 

Verify that a break-glass account remains accessible. 

Maintain a recovery path if administrators lose access. 

Enforce the policy. 

Apply the policy after testing is complete. 

Review sign-in activity and policy results. 

Confirm the policy behaves as expected after deployment. 

Managing Conditional Access across multiple tenants 

One Microsoft 365 tenant is relatively easy to keep organized. Fifty is another story. Every client has its own security requirements, approval process, and history of policy changes. Over time, those differences become harder to track... especially when multiple engineers are making updates across the same group of tenants. 

Conditional Access changes shouldn't rely on memory or whoever happens to be available that day. Before a policy is enforced, there should already be a record of what changed, why the change was made, how it was tested, and how to back it out if necessary. Those details take very little time to capture, but they're difficult to reconstruct once an outage is underway. 

That documentation becomes even more useful months later. An engineer reviewing a tenant should be able to see why a policy was created, whether any client-specific exceptions were approved, and when the last meaningful review took place. Without that context, every policy review starts from scratch. 

A repeatable review process doesn't eliminate every mistake, but it does make policy changes much easier to manage across dozens of Microsoft 365 tenants. Each policy change leaves behind useful context. The next engineer doesn't have to guess why a decision was made or retrace someone else's work. 

Learn more about Nerdio Manager

Reducing reliance on Global Admin and introducing a structured Conditional Access review process doesn't require rebuilding every Microsoft 365 tenant overnight. Starting with administrative accounts and policy testing can significantly reduce operational risk over time. 

If you're looking for additional guidance on securing Microsoft 365 environments at MSP scale, explore The MSP Guide to Microsoft 365 Security at Scale and learn how Nerdio Manager for MSP helps standardize administration across multiple tenants. 


Ready to get started?