Configuration drift in Microsoft 365 is widening identity risk

At a glance

What this is: This is an analysis of why configuration drift creates persistent identity and compliance exposure in Microsoft 365, Entra ID, and Intune environments.

Why it matters: It matters because drift changes the effective access model across human and non-human identities, so IAM, IGA, and compliance teams need continuous detection rather than snapshot reviews.

By the numbers:

• One early adopter, a global retail chain, reported a 70% reduction in configuration-related incidents within the first month of using Drift Manager.
• Drift Manager covers 650+ checks across Microsoft 365, Intune, Defender, and Entra ID.

👉 Read Senserva's analysis of configuration drift in Microsoft 365 and Entra ID

Context

Configuration drift is the gap between a system's intended baseline and its current state after repeated changes, exceptions, and platform updates. In Microsoft 365, Entra ID, and Intune, that gap becomes an identity governance problem because access, sharing, and policy settings can drift without a corresponding review cycle.

For IAM, IGA, and compliance teams, the issue is not just configuration hygiene. Drift changes who can access what, how controls behave, and whether evidence still matches the approved baseline, which is why periodic snapshots rarely keep pace with live tenant change.

Key questions

Q: How should security teams manage configuration drift in Microsoft 365 and Entra ID?

A: Security teams should treat configuration drift as a continuous identity governance issue, not a periodic admin task. The practical model is to define authoritative baselines, watch for changes in real time, and route deviations into the same approval workflow used for other access and policy changes. That keeps drift visible while preserving audit evidence and accountability.

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: What breaks when organisations rely on periodic scans for identity configuration?

A: Periodic scans break the assumption that a report represents the live environment. In fast-changing Microsoft tenants, settings can change again before the report is reviewed, which means teams end up correcting yesterday's state while today's exposure remains active. Continuous monitoring closes that timing gap.

Q: Who is accountable when configuration drift causes an access failure or breach?

A: Accountability should sit with the control owner for the affected baseline and the team managing change in that tenant area. If drift crosses IAM, security, and compliance boundaries, the response process should assign ownership for detection, triage, and remediation separately so the issue does not disappear into a shared governance gap.

Technical breakdown

Why baseline drift persists in Microsoft 365 and Entra ID

Configuration drift emerges when the as-designed state and the as-is state diverge over time. In Microsoft environments, that divergence is driven by administrator changes, user collaboration, and vendor updates that alter defaults or policies. Because identity controls are distributed across sharing, permissions, conditional access, and device policy, a small change can alter the effective security posture without changing any formal governance document. That is why drift is not an exception condition but an operating reality in large tenants.

Practical implication: teams need continuous detection tied to policy baselines, not periodic manual reconciliation.

Why periodic scans miss identity risk in live tenants

Periodic scans produce a point-in-time snapshot, which means they describe the past rather than the current tenant state. By the time a report is reviewed, new changes may already have created a different exposure pattern. Manual review has the same limitation at larger scale because analysts cannot continuously watch thousands of policies, groups, and assignments as they move. The technical weakness is timing, not intent: governance cadence lags operational change.

Practical implication: replace snapshot-based control checks with event-driven drift detection and workflow routing.

How in-tenant analysis changes the data handling model

When configuration analysis happens inside the tenant, the control question shifts from visibility to data movement. Exporting configuration data to external systems creates a new trust boundary, especially where tenant metadata, policy objects, and access structures are sensitive in their own right. In-tenant processing reduces that exposure by keeping the evidence where the identity system already lives, while still allowing classification, ticketing, and remediation workflow integration. The architecture matters because governance tools should not widen the risk surface they are meant to monitor.

Practical implication: evaluate whether your drift tooling creates an external data custody problem before you deploy it.

Threat narrative

Attacker objective: The attacker objective is to exploit unnoticed configuration changes to reach data or permissions that were supposed to remain restricted.

1. Entry occurs through ordinary administrative change, user collaboration, or platform-driven configuration updates that alter the Microsoft tenant baseline.
2. Escalation follows when a forgotten guest account, risky sharing rule, or outdated access policy expands effective permissions beyond the approved state.
3. Impact appears as unauthorized access, compliance failure, audit friction, or breach exposure before the drift is detected and corrected.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Configuration drift is an identity governance problem before it is a tooling problem. Once Microsoft 365, Entra ID, and Intune settings diverge from the approved baseline, access control no longer reflects governance intent. That means the control plane can remain technically functional while the organisation is already out of policy. Practitioners should treat drift as a live identity state issue, not a periodic hygiene task.

Baseline as truth is the assumption that drift breaks. Governance programmes assume the recorded configuration still matches the operating configuration long enough for review, audit, and remediation. That assumption fails when admins, users, and platform updates change the tenant continuously. The implication is that review cadence itself becomes part of the risk model, because stale baselines create false confidence.

Configuration drift creates identity blast radius by widening the gap between intended and effective access. A forgotten guest account, a sharing rule change, or a policy exception can convert a narrow control failure into tenant-wide exposure. In practice, the issue is not whether drift exists but how quickly it can alter privilege and evidence at scale. Teams should measure blast radius, not just configuration count.

Continuous drift detection aligns better with NIST CSF and ZT principles than report-based control checking. NIST Cybersecurity Framework 2.0 emphasises ongoing governance, while Zero Trust assumes verification must continue as conditions change. Drift management belongs in that operating model because the security question is always current state, not last week’s export. Practitioners should fold drift into continuous control monitoring rather than separate it from IAM oversight.

Microsoft tenant change management and identity governance are now inseparable. If platform updates can quietly change permissions, sharing, or policy behaviour, then identity teams cannot rely on access review alone to preserve security intent. The operational conclusion is that governance must track configuration events as first-class identity evidence. Teams should treat change detection, remediation routing, and review evidence as one control loop.

From our research:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For deeper lifecycle context, see NHI Lifecycle Management Guide and Top 10 NHI Issues.

What this signals

Identity teams should expect configuration drift to merge with privilege creep, not sit beside it. In practice, the more frequently a tenant changes, the harder it becomes to prove that the access model still matches the approved one. The monitoring question is no longer whether drift exists, but whether your governance loop can detect it before it changes the blast radius.

Configuration drift is becoming a control-plane visibility problem across human and non-human identity programmes. When policy, sharing, and access settings change underneath the governance model, evidence quality degrades even if the directory itself looks clean. That is why drift monitoring belongs alongside continuous control monitoring, not after the fact in audit preparation.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market is moving toward continuous identity assurance rather than periodic review. Teams that still depend on snapshots will struggle to reconcile current tenant behaviour with their governance records, especially as change velocity rises and evidence retention becomes a control in its own right.

For practitioners

• Map drift controls to identity-owned baselines Define which Microsoft 365, Entra ID, and Intune settings are governed baselines, then tie each baseline to an owner, review cadence, and remediation path.
• Move from snapshot scans to continuous detection Use event-driven monitoring for configuration changes so deviations are flagged when they occur, not after a scheduled report is generated.
• Route drift findings into the existing ticketing process Send each deviation into the same approval and remediation workflow used for other identity changes so exceptions do not bypass operational control.
• Treat external data export as a control risk If a tool copies tenant configuration outside the environment, assess the added custody and compliance exposure before relying on its output.

Key takeaways

• Configuration drift turns routine tenant change into identity risk because the approved baseline no longer matches the live control state.
• The article links drift to breach, compliance, and audit failure evidence, showing that configuration changes can become access incidents before anyone notices.
• Continuous, in-tenant detection is the control shift this problem demands because snapshot reviews cannot keep pace with Microsoft tenant change.

Key terms

• Configuration drift: Configuration drift is the gradual divergence between a system's approved baseline and its live operating state. In identity programmes, that divergence changes access, sharing, and policy behaviour without a corresponding governance decision, so the recorded control state and the real control state stop matching.
• Baseline: A baseline is the approved configuration state that security, compliance, and operations teams use as the reference point for control. In practice, it only works when it stays current, is owned, and is tied to monitoring so changes can be detected before they become exposure.
• Continuous control monitoring: Continuous control monitoring is the practice of checking control state as changes happen rather than waiting for periodic review. For identity governance, it means watching configuration, access, and policy events in near real time so drift, privilege changes, and evidence gaps are caught while they are still actionable.
• Identity blast radius: Identity blast radius is the amount of access, data, or control that can be affected when one identity or one configuration change goes wrong. It is a useful way to measure how far a small drift event can spread before teams detect and contain it.

What's in the full article

Senserva's full blog post covers the operational detail this post intentionally leaves for the source:

• The full change-detection workflow for Microsoft 365, Entra ID, and Intune configurations.
• The rule library and baseline logic behind continuous drift classification.
• The ticket routing and approval flow used to move drift findings into remediation.
• The implementation details for keeping analysis inside the tenant boundary.

👉 The full Senserva post covers drift detection workflow, policy rules, and tenant-bound analysis.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.