Guest blog courtesy of Augmentt.
Most M365 security incidents don't begin with a sophisticated attack. They begin with a setting that quietly changed six months ago that nobody noticed. That's configuration drift, and for MSPs managing dozens or hundreds of tenants, it's one of the most persistent and underappreciated threats in their clients' environments.
Understanding what drift is, how it happens, and what it takes to stay ahead of it is foundational to delivering a credible M365 security practice.
What is configuration drift?
Configuration drift is the gradual divergence between a client's current Microsoft 365 environment and the security baseline you originally set. It's not a one-time event; it's a process. Each manual change, one-off exception, or missed update nudges the environment a little further from where it should be.
In a single-tenant environment managed by an internal IT team, drift is manageable. The team has intimate familiarity with the environment and typically reviews it regularly. For an MSP managing 50 or 100 tenants, the math changes completely. There are simply too many environments, too many settings, and too many potential change events for any team to track manually.
How drift happens in practice
Drift rarely happens because someone made a careless mistake. It happens because managing a live environment means making trade-offs constantly. A client calls in with an urgent request: a travelling executive needs an MFA exception. A technician disables a conditional access policy temporarily to troubleshoot an issue and forgets to re-enable it. A new app integration requires a permission change that nobody documents.
Over time, these small, individually reasonable changes compound. The environment your team hardened at onboarding no longer resembles what's running today. And because the changes were spread across months and dozens of service tickets, there's no single moment where the gap became obvious.
Common drift vectors in M365 environments include:
- Conditional access policies disabled for troubleshooting and not re-enabled
- MFA exceptions granted to individual users that persist indefinitely
- Legacy authentication protocols re-enabled for specific app compatibility
- Admin roles assigned temporarily and never revoked
- External sharing settings relaxed at a client's request without a review date
Why drift is a security risk, not just a housekeeping issue
Each item on the list above is, on its own, a potential breach vector. Conditional access policies are what prevent compromised credentials from being used to access client data. Legacy authentication bypasses MFA entirely. Persistent admin roles widen the blast radius if an account is compromised.
What makes drift particularly dangerous is that it's invisible without active monitoring. Unlike a failed login attempt or a phishing email, a configuration change doesn't trigger an alarm. It just sits there, quietly degrading your client's security posture until something goes wrong.
For MSPs, drift also creates liability. If a client suffers a breach that can be traced to a configuration that deviated from your agreed security standard, the question of who's responsible becomes uncomfortable quickly.
Detecting and remediating drift at scale
The only scalable response to configuration drift is automated monitoring. Manual audits — logging into each tenant, reviewing settings, comparing against a baseline — are impractical at any meaningful scale. By the time you've worked through 30 tenants, the first few have already had more changes.
Purpose-built MSP platforms like Augmentt continuously monitor all managed tenants against a defined security baseline. When a setting drifts, the platform flags it; and in many cases, can automatically remediate it without technician intervention. This turns drift management from a reactive, periodic audit into a continuous, automated process.
Effective drift detection should cover the full scope of an M365 environment: identity and access management settings, conditional access policies, Exchange Online configurations, SharePoint and Teams sharing policies, and Defender configurations. A gap in any of these areas is a gap in your client's security.
Building drift prevention into your service model
The best approach to configuration drift isn't just detecting it after the fact. It's making drift prevention a standard part of your service delivery. This means documenting your security baseline clearly, requiring a formal change management process for any deviation, and using automated tooling to enforce and monitor compliance continuously.
MSPs who treat configuration drift as a disciplined operational practice rather than an afterthought are better positioned to prevent incidents, demonstrate value to clients, and scale their teams without proportionally increasing risk. Augmentt's automated baseline enforcement and drift remediation capabilities are designed specifically to support this kind of practice at scale.
The bottom line: every M365 tenant drifts. The question is whether you find out before or after something breaks.
