Vasil is a nine-time Microsoft MVP and expert with over a decade of experience in Microsoft cloud, lifecycle management, migration, adoption, and automation.
Configuration drift consists of unexpected changes to your security baseline in Microsoft 365. And configuration drift is going to happen – no matter what you do. It creeps up almost invisibly, and by the time you identify which configs have drifted, something has probably already gone wrong. But you can proactively detect and prevent Microsoft 365 configuration drift, and the latest blog post will show you how.
Configuration drift in Microsoft 365 is the silent erosion of your security, compliance, and governance posture, as settings unintentionally deviate from defined baselines, often without detection. Even minor drifts dramatically increase cyber risk, threaten business continuity, and can expose sensitive data or disrupt operations. Manual management is impossible at enterprise scale; the only defense is continuous baseline enforcement, automated detection, and rapid remediation. This blog details how to proactively spot drift, leading practices for managing and preventing it, and how tools like CoreView automate visibility, reporting, and correction to keep your Microsoft 365 environment resilient and secure.
Misconfigurations in Microsoft 365
Misconfigurations in Microsoft 365 – including those that come about due to unintentional configuration drift – create entry points for cyberattacks. Configuration drift is particularly insidious because, if you’re not looking for it, it is almost undetectable. Even small, unexpected changes in configurations can create a vulnerability that gives an attacker an opening to gain access to otherwise secure systems.
A large organization can have thousands of unique configurations – impossible to manage manually. And “configuration” sounds deceptively innocuous. But your configurations govern virtually everything about access to your systems. A single misconfiguration can have significant consequences – for example, locking your whole business out of your tenant, or, as happened with the 2024 CrowdStrike bug, spreading downtime across a global supply chain.
What is configuration drift in Microsoft 365?
Configuration drift happens when Microsoft 365 settings gradually move away from the organization’s intended security baseline or security posture, usually without IT noticing.
Configuration drift is a critical security, cyber resilience, and governance challenge. It means that:
Security controls may silently weaken (e.g., MFA disabled for certain accounts, sharing settings loosened).
Compliance posture erodes because the actual tenant no longer matches the defined policy.
IT loses visibility and consistency across workloads (Exchange, Teams, SharePoint, etc.).
Configuration drift in Microsoft 365 amounts to unintended, unnoticed changes to tenant settings, which create risk.
What are the main causes of configuration drift in M365?
In large, dynamic environments, configuration drift in M365 can occur for a variety of reasons.
Some of the primary causes include:
Manual changes and human error
Lack of formal change management
Poor visibility into who changed what and when
Microsoft updates and feature rollouts that silently alter default settings
The complexity of managing thousands of configuration types across multiple workloads and tenants
Absence of a clearly defined baseline or automation to enforce it
Individually or in combination, these factors lead to unnoticed deviations from an organization’s intended security and compliance posture.
How to detect configuration drift in Microsoft 365
Configuration drift can be insidious largely because change can go undetected for a long time. For this reason, organizations of all sizes should be vigilant about their M365 configurations and aim to detect changes in real time.
Here are general steps and considerations for adopting drift detection in Microsoft 365.
1. Define and document the “ideal” baseline
Before you can detect drift, you need a reference or “golden” configuration state. What should your ideal policies, roles, settings, and security posture look like?
What configurations are in scope, i.e., workloads, policies, identity, device settings, compliance/security settings, etc.
Include different environments, such as dev, test, and prod, if applicable.
Capture versioned snapshots over time.
Map baseline to business, security and compliance requirements, e.g., NIST, CIS, internal policies.
2. Identify which configuration types and settings to monitor
Not all settings have equal weight. Some are operationally critical; some change more often than others. This is a step where you prioritize your key configurations.
Establish prioritization criteria, such as risk, regulatory impact, and exposure.
Use Microsoft tools, such as the open source Microsoft 365 DSC, to understand what settings are trackable.
Decide thresholds: What constitutes “drift” – is it any change at all, or only changes away from baseline? What severity level?
3. Set up monitoring and sync schedule
Make it regular practice to get your current state and compare it with your established baseline. This should happen automatically and frequently enough to catch drift early.
Decide frequency levels, e.g., nightly, hourly, etc., considering how dynamic your environment is
Ensure all tenants/devices/environments are included
Account for time/latency of applied changes
Consider tools like Microsoft 365 DSC for continuous monitoring
4. Detect drift
Compare your live/current configuration state with baseline to spot the differences.
Use built-in Microsoft tools, such as Defender’s Configuration Analyzer for threat policies, to check settings against standard or strict profiles.
Select third-party tools that cover M365 gaps in detection, particularly full visibility
Use Microsoft 365 DSC’s drift detection and event-logging mechanism
Determine how to surface drift: dashboards, alerts, reports
Include metadata: Who made the change, when, from which source
5. Set up alerting and notification
Once drift is detected, relevant stakeholders can receive alerts, if needed (for example, security, compliance, IT, operations, and so on). Alerts are a good option to have, but it’s most important to ensure remediation. The quicker this is done, the quicker corrective actions are underway.
Set up appropriate escalation paths
Prioritize alert by severity and impact
Integrate with SIEM or incident-response workflows
Consider automated notification with context (i.e., what changed, impact, remediation suggestions)
6. Audit and log configuration changes
For governance, compliance, and incident response, you need detailed logs of configuration changes over time.
CoreView’s CRO, Mark Cravotta highlights the importance of logs in an investigatory capacity: “Nobody gets breached knowingly, so they do not actually know why or what happened, or to what extent they have been breached. Part of incident response is an investigation, and it requires detailed forensic tools and expertise to find out what happened, determine the impact, and ensure it does not happen again.”
Ensure audit logs are enabled in Microsoft 365 (e.g., Unified Auditing)
Capture change details: before/after values, user making the change, time, context (did it happen via portal, API, script, etc.)
Retention policies for logs
Reports/historic drift analysis
7. Risk of drift/severity analysis
Just as configurations have different levels of importance, so too does drift. Some drift may be safe or even expected, while other kinds of drift are clear security risks or violations of policy that need to be remediated.
Categorize level of drift, i.e., whether it is benign, risky, a policy violation, etc.
Map drift to business risk, e.g, user lock-out versus permissions escalation versus compliance risk
Use threat modeling or impact assessment
Consider external benchmarks (CIS, Microsoft best practices)
Detect and fix configuration drift in Microsoft 365 with CoreView
Methods using Microsoft tools to detect configuration drift
To make your detection workflow robust, consider:
Microsoft365DSC: It’s open source, allows you to export configuration into code, monitor drift vs desired state, log events, and schedule checks.
Defender / Security Center Configuration Analyzer: For threat and security policies, you can use Defender to compare current settings vs Standard or Strict recommended profiles and view the history of drift.
Native Audit Logs/Unified Auditing: Enable and collect, so that changes both expected and malicious are traceable.
Microsoft Secure Score: Get visibility into how your tenant configuration stacks up against best practices and get some insight into when controls are misconfigured.
Microsoft Entra ID Identity Protection and Access Reviews: Detect risky sign-ins, misconfigurations, and permission drift.
Microsoft Intune Compliance Policies and Baselines: Detect device and app (endpoint) config drift that could affect overall security posture.
Microsoft Purview Compliance Manager: Get assessments based on regulatory requirements and Microsoft recommendations, while also flagging deviations in compliance-related configs, such as data loss prevention or retention policies.
Microsoft Defender for Cloud Apps (formerly MCAS): Monitors apps and service configurations for risky changes, and detects drift from baseline policies, especially identity and access management.
Change Management and Version Control: Store baseline and templates in version control (GitHub, Azure DevOps, etc.), so you can track changes over time, roll back, and see diffs.
Alert/SIEM Integration: Push drift alerts into your Microsoft Sentinel SIEM tool or incident-response dashboards; correlate with other signals (e.g., after admin account login, after a policy change, etc.).
Methods using third-party tools for detecting M365 Configuration Drift
Microsoft-native tools like Secure Score, Compliance Manager, Intune baselines, and Audit Logs provide foundational drift detection but often require manual correlation and oversight.
Third-party tools like CoreView extend these capabilities by adding automation, proactive drift reporting, delegated administration, and corrective workflows, making them more effective for large or complex M365 environments.
CoreView, for example, provides advanced tenant-wide monitoring, auditing, and automation for Microsoft 365. By continuously monitoring and comparing current system settings against established baselines, CoreView identifies discrepancies between how settings were intended to be configured and how they are actually set at any given moment.
When a deviation is detected, for example, if a security policy is modified or a compliance rule is disabled, CoreView logs and reports these changes. It provides detailed information about the drift, including which setting changes, when the change occurred, and which user or process was responsible. This real-time drift detection helps organizations spot unintentional or unauthorized changes, reducing risk and improving consistency in cloud configurations.
Third-Party Tools for Detecting M365 Configuration Drift
A variety of third-party tools for the detection of M365 drift exist:
CoreView
Provides advanced tenant-wide monitoring, auditing, and automation for Microsoft 365.
Key Capabilities for Drift Detection:
Configuration Drift Reports: Tracks baseline security and operational settings across Exchange, Teams, SharePoint, and OneDrive.
Policy Enforcement: Automatically detects when settings drift from defined baselines and can trigger corrective actions.
Delegated Administration: Helps avoid misconfigurations by limiting who can change sensitive settings.
Audit & Alerting: Real-time detection of unauthorized or unintended configuration changes.
CoreView excels in multi-tenant or large enterprise environments where native tools may lack visibility or automation.
Quest On-Demand Audit
Provides centralized auditing and reporting across M365 services.
Detects and alerts on configuration changes that drift from baselines, with strong change-tracking features.
ManageEngine M365 Manager Plus
Offers reporting and alerting for configuration changes across Exchange Online, SharePoint Online, and Teams.
Helps identify and remediate drift through scheduled reports and anomaly detection.
AvePoint Cloud Governance
Provides policy enforcement and lifecycle management for M365.
Detects drift by flagging when Teams, Groups, or SharePoint sites deviate from governance policies.
BetterCloud
SaaS management platform that can enforce policies across M365.
Detects drift by monitoring admin actions and automatically remediating policy violations.
How to manage configuration drift in Microsoft 365
Drift detection in Microsoft 365 is only half the battle – the other half is getting everything back to baseline and managing drift as a whole.
Here are typical drift management steps:
1. Remediation and rollback
Restore to baseline or correct misconfiguration.
Define rollback procedures (manual or automated)
Keep backups/snapshots of prior states
Ensure changes are tested first in dev and tested environments before going live in prod
Document remediation steps
Where possible, automate correction (for low-risk drift) versus manual review for high risk
2. Validate and test configuration changes
Before changes back to baseline are pushed into production, validate in a non-prod environment to avoid unintentional conflicts or the creation of new drift.
Maintain consistency between environments as much as possible
Use staging of changes
Use change management with approvals
Use test harnesses, rollback testing, and possibly simulations
3. Continuous review and improvement
Drift detection is not a one-and-done exercise. Policies, best practices, and threats evolve, meaning your review needs to be constant with an aim to stay on top of change and improve your processes.
Review baselines periodically versus new Microsoft or industry guidance
Monitor Microsoft feature and policy changes (new controls, deprecated settings)
Review drift incidents, root causes, process gaps
Update tooling, filters, alert thresholds
Involve relevant stakeholders (security, compliance, operations) to align risk appetite.
Methods using Microsoft tools within the M365 environment to manage configuration drift
These Microsoft native tools help define, enforce, and restore desired state (rather than just detect):
Microsoft Intune – Compliance Policies & Baselines Not only detects drift, but it can also enforce compliance by applying corrective policies to endpoints.
These focus on correcting, preventing, or governing drift once it’s found:
Change Management & Version Control – Maintain baselines/templates in GitHub/Azure DevOps, roll back, view diffs.
Alert / SIEM Integration – Route drift alerts into Microsoft Sentinel for faster triage and response.
Third-party tools for managing M365 configuration drift
A number of platforms go beyond detection by enforcing baselines, automating rollback or reapplying policies.
CoreView tops this list by providing policy enforcement and automated remediation workflows when drift or misconfigurations are found.
A sampling of other config drift tools includes:
Quest On Demand Recovery Complements detection by allowing rollback of configuration drift at the object or tenant level.
AvePoint Cloud Governance / Policies Enforces policies across M365 tenants and can auto-remediate drift by applying governance rules.
SkyKick Cloud Manager Automates remediation tasks and applies standardized baselines across tenants to correct drift.
BetterCloud Automates policy enforcement and corrective actions for M365 drift events.
Best practices for preventing M365 configuration drift
Preventing configuration drift in Microsoft 365 (M365) starts with enforcing consistency and visibility across your environment. A best practice is to define and document baseline security and compliance configurations, then use tools such as Microsoft Secure Score, Compliance Manager, and Defender for Cloud Apps to monitor adherence. Automating configuration management through Intune, PowerShell Desired State Configuration (DSC), or third-party governance platforms can help ensure that policies are applied uniformly and reverted quickly if drift occurs.
In addition, implementing change management processes is key: require approvals for administrative changes, use role-based access control (RBAC) to limit who can alter critical settings, and enable auditing and alerting for high-risk modifications. Regular configuration reviews—combined with automated reporting and alerts—help teams detect unauthorized or accidental drift early, reducing the risk of misconfigurations that could lead to security gaps or compliance violations.
M365 Configuration Drift Prevention Checklist
✔Define a baseline: Document security and compliance configurations as your standard.
✔Monitor continuously: Use Secure Score, Compliance Manager, and Defender for Cloud Apps to track adherence.
✔Automate enforcement: Apply policies through Intune, PowerShell DSC, or governance tools.
✔Control changes: Enforce change management, require approvals, and restrict privileges with RBAC.
✔Audit & alert: Enable logging and set alerts for high-risk or unauthorized changes.
✔Review regularly: Schedule periodic configuration reviews and automated reports.
Impact of configuration drift in M365
If it were not already clear, these actions help to mitigate the worst effects of configuration drift. But what are these effects, and how do they come about?
No visibility = Cascading problems due to human error/manual changes When admins or operators make direct changes (e.g. via the portal, PowerShell) outside of approved process, the scope for misconfigurations widens. People are fallible and can make changes and then forget to update documentation, follow established processes, or apply settings correctly. This creates a messy situation in which human error meets up with a lack of detailed awareness or insight into who changed what, when.
No change management + scale + complexity = Increasingly divergent configurations Without a standard process, no testing, no review or approval workflow before changes, changes can be made in production without having consistent replications of baseline settings across environments when you are ultimately striving for consistency. The sheer number of configuration types (CoreView often refers to “5,000+ configuration types” across many workloads) means it is easy to miss things. Multiple tenants, multiple workloads (Exchange, Teams, SharePoint, Intune, Entra, etc.), environments across development/test/prod. Keeping everything consistent is hard.
No visibility into Microsoft updates, feature rollouts and setting deprecations = Broken compatibilities are disruptions to productivity/business continuity Microsoft changes or deprecates features, updates behaviors of settings, and updates things all the time without informing anyone about the changes made. One day you may just find that whatever defaults had been are no longer, and your configuration has moved away from your baseline, which can cause everything from a minor disruption to complete outages or lack of access.
No configuration backups = You lose your configurations and thus hours, days or even weeks of productivity Organizations often incorrectly believe that Microsoft’s native tools back up all their configuration settings to enable a full restore. This is completely false. If you lose your tenant configurations, you are starting from scratch. Because of those gaps, when changes or deletions happen (maliciously, accidentally, or via system issues), there’s no fallback.
No visibility into drift = What you don’t know can hurt you Configuration drift that goes undetected because there isn’t continuous monitoring or alerts can have a real impact. Small config drifts happen all the time, and to avoid catastrophic consequences, it works in your favor to know the real-time state of your configurations at all times.
Lack of baseline = No way to measure Without a clearly defined “ideal configuration” or policy baseline, drift can’t be measured. Organizations sometimes don’t have a known good state to compare against.
Lack of automation = Too much room for error, too much time on manual work Manual processes dominate; little to no automation for deploying, auditing, remediating configuration changes. Because of this, small changes creep in, error margins increase, and drift accumulates.
Streamline M365 Configuration Drift Management with CoreView
With CoreView, you can detect, monitor, and remediate drift automatically. CoreView continuously audits Microsoft 365 tenant configurations, compares them against best practices or custom baselines, and alerts or auto-corrects when drift occurs. Enterprises can maintain consistent policies across global tenants, enforce security, and prove compliance.
CoreView allows you to:
Template your ideal configurations and save current/historic variations as code.
Include/exclude configuration types and individual settings in its filters.
Configure sync schedule (default nightly) to monitor for drift.
Monitor for drift from your baseline, trigger alerts, and keep an audit of configuration changes.
Roll back to your ideal state, restoring previous configurations in one step.
Deploy configs to dev and test tenants to test changes before deploying to the product environment.
Don’t get caught out by inevitable configuration change – combat it by identifying it as it happens. Find out how you can use CoreView to catch configuration drift in action to help you maintain your ideal baseline and security posture.