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.