Configuration drift in Microsoft 365 is widening identity risk

At a glance

What this is: This is an analysis of how configuration drift in Microsoft 365, Entra ID, and Intune turns ordinary tenant change into a persistent identity and compliance risk.

Why it matters: IAM and compliance teams need continuous drift detection because baseline reviews alone cannot keep pace with settings, permissions, and policy changes across modern Microsoft environments.

Context

Configuration drift is the gap between the state you designed and the state your tenant actually reaches after routine admin changes, user behaviour, and vendor updates. In Microsoft 365, Entra ID, and Intune, that gap can quietly change access, sharing, and compliance posture without a formal change event.

The identity governance issue is that periodic review assumes the environment remains stable long enough to inspect it. In practice, cloud tenants shift continuously, so a baseline can become stale before a scan or manual review finishes.

Key questions

Q: What breaks when Microsoft 365 settings drift away from approved identity policy?

A: The control breaks when approved access rules and live platform settings stop matching. In Microsoft 365, that means auto-forwarding, mailbox delegation, or MFA exceptions can remain active long after the policy changed, creating silent exposure across collaboration and identity services. The practical failure is not one bad setting, but a control plane that no longer reflects governance intent.

Q: Why does configuration drift create compliance risk even when controls look healthy?

A: Because compliance depends on the current operating state matching the approved baseline, not on a previous scan. A tenant can look healthy in a report while a new policy change, sharing rule, or privilege assignment has already altered the real security posture. That gap is what creates audit failures and delayed certification problems.

Q: How should teams detect Microsoft 365 drift without relying on snapshots?

A: Use continuous monitoring for the controls that change most often, especially directory, collaboration, and device settings. Snapshot scans are useful for periodic assurance, but they cannot close the exposure window between review cycles, which is where drift usually becomes actionable risk.

Q: What should IAM teams do when drift is found in a tenant?

A: Treat it as a governed change, not an ad hoc fix. Capture the affected control, assess the blast radius, route the issue through an approval workflow, and remediate in a way that preserves audit evidence and ownership.

Technical breakdown

How configuration drift alters identity baselines in Microsoft 365

Configuration drift occurs when settings, policies, permissions, or defaults move away from their intended state over time. In Microsoft 365 ecosystems, that drift can touch Entra ID access controls, Intune device policy, SharePoint and OneDrive sharing, and tenant-level security settings. The technical problem is not only change volume, but the fact that each change can interact with others, creating a new effective baseline that no longer matches the approved one. That makes drift a state-management problem, not a one-time hardening task.

Practical implication: track the approved baseline for identity, device, and collaboration settings as continuously changing state, not as a static checklist.

Why periodic scans miss real-time identity exposure

Periodic scans are snapshots, not control loops. They tell you what the environment looked like when the query ran, but not what changed immediately after. In tenant-heavy Microsoft environments, the interval between scans becomes the exposure window for risky group edits, sharing changes, app registrations, or policy relaxation. This is why drift often survives long enough to become an audit issue or a breach enabler before anyone notices it.

Practical implication: replace scan-only governance with continuous detection for settings that affect access, sharing, and privilege.

Why in-tenant processing matters for configuration governance

When configuration data is exported to an external platform, the monitoring design itself creates another trust boundary and another compliance question. The article's core tension is that security teams want visibility into drift without moving sensitive tenant configuration outside the environment being governed. In-tenant processing keeps the detection loop closer to the source of truth and avoids creating a second configuration repository that must also be secured, audited, and justified.

Practical implication: prefer monitoring models that preserve tenant locality when configuration evidence is sensitive or regulated.

Threat narrative

Attacker objective: The practical objective is to exploit or benefit from a weakened tenant state before the drift is detected and remediated.

1. Entry occurs through routine tenant change, such as an admin tweak, a user sharing action, or a Microsoft update that alters the approved configuration state.
2. Credential or access impact emerges when a drifted control weakens sharing, group membership, or tenant policy enough to expose data or privilege paths.
3. Escalation follows when the unchanged baseline remains in place long enough for the drifted setting to be used operationally without review.
4. Impact is security exposure, audit failure, or compliance loss that accumulates quietly until the organisation discovers the configuration no longer matches its policy.

Breaches seen in the wild

• Canvas Instructure Data Breach: ShinyHunters exploits Canvas LMS platform to expose millions of student records via third-party NHI credential abuse.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Configuration drift is a governance failure, not just a visibility gap. The central issue is that Microsoft 365 environments keep changing after the baseline is approved, so the approved state and the effective state diverge. That divergence matters because access, sharing, and policy controls are only as strong as their current configuration. Practitioners should treat drift as a control state problem, not a reporting problem.

Continuous drift detection is now part of identity operations. A tenant that changes between review cycles cannot be governed safely by periodic snapshots alone. The more frequently admins, users, and platform updates alter settings, the more identity teams need real-time or near-real-time control feedback. The practitioner conclusion is simple: governance must move at the same speed as the tenant.

Tenant-local monitoring reduces a new trust boundary. If configuration evidence leaves the tenant, the monitoring layer becomes another system that can leak sensitive posture data. That is a material governance consideration in regulated environments, especially where configuration reveals privilege structure, external sharing exposure, or compliance gaps. Practitioners should evaluate where their evidence is processed, not just what is detected.

Configuration drift creates identity blast radius across collaboration, device, and directory controls. A small change in Intune, SharePoint, or Entra ID can widen exposure well beyond the original change request. The named concept here is identity blast radius: the spread between a small administrative action and the downstream access and compliance impact it creates. Practitioners should govern settings by downstream effect, not by the size of the original change.

Microsoft tenant governance is becoming a live control plane. The article shows that static policy checks no longer match the operating tempo of cloud identity environments. That does not make baseline policy less important; it makes the enforcement model more continuous and more operational. The practitioner conclusion is to align change detection, policy review, and remediation into a single governance loop.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Identity Security Posture Management (ISPM) Guide

What this signals

Identity Security Posture Management becomes the right lens for drift-heavy tenants. Microsoft 365 environments need posture visibility that is tied to live configuration state, not only to report cadence. The practical implication is that teams should evaluate whether their control model can detect changes in the same operational window in which those changes happen.

Identity blast radius is the more useful way to think about configuration drift. A minor settings change in one Microsoft control plane can widen access or undermine evidence in another. The governance task is to identify which settings have disproportionate downstream impact and watch those first.

92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. While this article is about tenant configuration, the broader lesson is the same: governance breaks fastest when control state changes faster than review state.

For practitioners

• Implement continuous configuration monitoring Monitor Microsoft 365, Entra ID, and Intune settings continuously so drift is detected when it occurs, not during the next scheduled review.
• Track approved baselines by control domain Maintain explicit baselines for sharing, group membership, conditional access, and device policy so deviations can be classified against the right control owner.
• Route drift into ticketed remediation Send detected changes into your existing ITSM workflow with impact context, affected policy details, and approval steps before any fix is applied.
• Keep configuration evidence inside the tenant Prefer in-tenant processing for posture and drift evidence when the configuration data itself is sensitive or subject to strict compliance handling.
• Prioritise high-impact drift paths first Focus first on settings that can widen access, expose shared data, or weaken auditability, because those changes create the largest security and compliance blast radius.

Key takeaways

• Configuration drift in Microsoft 365 turns routine admin and platform change into a standing governance risk because the approved baseline and the live tenant diverge.
• The article frames drift as both a security exposure and a compliance failure, with audit and certification issues appearing after the configuration has already shifted.
• Continuous detection, in-tenant processing, and ticketed remediation are the operational controls that matter most when tenant state changes faster than review cycles.

Key terms

• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Baseline Governance: Baseline governance is the discipline of defining, tracking, and validating the intended state of identity and security controls over time. For drift-heavy tenants, it matters because the baseline is only useful if the control model can detect when the live state departs from it.
• Tenant-local Processing: Tenant-local processing means detection and analysis happen inside the customer environment instead of exporting sensitive configuration data elsewhere. For Microsoft identity governance, it reduces data movement risk while preserving visibility into drift and control exceptions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.