Microsoft Purview Endpoint DLP Not Blocking: Why Policies Silently Stop Enforcing
Proactive Security for the AI Era
NodeZero continuously and autonomously pentests infrastructure, identity, cloud, and now web applications, chaining weaknesses across every domain the way real attackers do. Every finding ships with replayable proof showing exploitable business impact, not theoretical risk.
This is a different problem than setting Purview DLP up for the first time. Our companion guide, How to Implement Data Loss Prevention with Microsoft Purview, covers building sensitive information type scope, running simulation mode, and configuring Exchange, Teams, and endpoint policies from scratch. That guide assumes nothing is deployed yet. This guide assumes the opposite: endpoint DLP was working, a policy was actively blocking USB copy or browser upload of sensitive files, and now it isn't, with no error banner, no failed-policy alert, and often no obvious trigger. The absence of an alert is itself the problem: Purview does not raise a notification when enforcement silently degrades, so the first sign is usually a security team member noticing that a file that should have been blocked went through. This guide walks through isolating the failure to one of four root causes (policy precedence conflict, device configuration or sync failure, agent health problem, or the documented scan timeout) and fixing and validating each.
Causes: Why a Working Policy Stops Enforcing
Endpoint DLP enforcement degrades silently because the platform is designed to fail toward availability, not toward blocking, when something upstream is unhealthy. Four causes account for nearly all cases of a previously enforcing policy going quiet.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Diagnostics: Isolating Which Cause You Have
Work through these in order; each step either confirms a cause or rules it out and narrows the remaining set.
-
Check policy precedence first, before touching the device. In the Purview compliance portal, go to Data Loss Prevention > Policies and list every policy scoped to the affected location (Devices) and the same sensitive information type as the policy that stopped blocking. Note each policy's enforcement mode (block, block with override, audit) and priority number. If an audit-mode policy with broader scope or higher priority exists alongside your block policy, check Activity Explorer for the specific blocked-then-unblocked file event: it will show which policy actually matched.
-
Check device configuration and policy sync status. Purview portal > Settings > Device onboarding > Devices, then select the affected device. Confirm Configuration status and Policy sync status are both 'Updated.' If either shows 'Not updated' or 'Not available,' open the device details pane, which lists the specific remediation needed (commonly Defender real-time protection or behavior monitoring disabled). Also check 'Last seen': a device that has not phoned home recently cannot have received a policy update regardless of what caused it to go offline.
-
Query DeviceInfo in Advanced Hunting for a fleet-wide view. Rather than clicking through devices one at a time, run this against the Microsoft Defender portal's Advanced Hunting to surface every device with an unhealthy DLP configuration in one pass:
DeviceInfo
| where DlpInfo != ""
| extend Dlp = parse_json(DlpInfo)
| project DeviceName, Timestamp,
IsDlpEnabled = Dlp.IsDlpEnabled,
IsDlpConfigurationValid = Dlp.IsDlpConfigurationValid,
IsDefenderRealTimeProtectionEnabled = Dlp.IsDefenderRealTimeProtectionEnabled,
IsDefenderBehaviorMonitoringEnabled = Dlp.IsDefenderBehaviorMonitoringEnabled,
DlpPolicyLastModifiedTimeUTC = Dlp.DlpPolicyLastModifiedTimeUTC
| where IsDlpConfigurationValid == false or IsDefenderRealTimeProtectionEnabled == false
-
Check the endpoint's local DLP event log for agent-level failures. On the device itself, open Event Viewer and look under Applications and Services Logs > Microsoft > Windows for the DataLoss Prevention admin log. Repeated errors around service start, policy download, or classification engine failures point to an agent problem rather than a portal-visible configuration issue; the portal's sync status can lag what is actually happening on the endpoint by up to two hours, so the local log is the faster source of truth when you already suspect the agent.
-
On macOS, verify Full Disk Access separately from sensor health. Check
mdatp healthfor sensor connectivity, but also check System Settings > Privacy & Security > Full Disk Access to confirm the Defender extension still has the permission. A healthy sensor with revoked Full Disk Access will still report as running while DLP file visibility is effectively blind. -
If nothing above shows a fault, suspect the scan timeout. Reproduce the failure with the same file type and size that slipped through, on the same device, and watch whether it is intermittent (sometimes blocks, sometimes doesn't) rather than consistent. Consistent failure means one of the first four causes; intermittent failure under load is the timeout behavior.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Fixes: Resolving Each Root Cause
Apply the fix that matches what diagnostics identified. Do not apply all four preemptively; each has a different blast radius and an unnecessary change (especially to policy priority) can introduce a new precedence conflict elsewhere.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Validation: Confirming Enforcement Is Actually Restored
Do not close the investigation on the diagnostic signal alone (a device showing 'Updated,' a service reporting running, a policy conflict resolved on paper); confirm the policy blocks again with a real test. Create a synthetic test file containing an obviously fake instance of the sensitive information type the policy targets (a clearly fake SSN or a synthetic payment card number that fails a Luhn check is standard practice and avoids using real sensitive data in testing). On the specific device that was failing, attempt the exact activity that previously slipped through: USB copy, upload to the specific cloud service, or clipboard paste, depending on what the policy scopes. Confirm three things together: the action is blocked or prompts for justification as designed, the block event appears in Activity Explorer within a few minutes, and the event attributes the correct policy name (not a different policy that happens to also match, which would indicate the precedence issue is still unresolved). Repeat the test on at least one additional device in the same group to confirm the fix isn't specific to the one machine you diagnosed, since a policy-level fix should restore enforcement fleet-wide while a device-level fix only restores it for that device.
Failure Cases: When the Fix Doesn't Stick
A few patterns explain most cases where a fix appears to work and then the same silent gap reappears. First, policy sync status can show 'Updated' immediately after a portal change while the actual device has not yet received it, because the documented refresh window is up to two hours; testing immediately after a fix can produce a false negative where the old, still-broken policy is what actually got tested. Wait out the sync window before validating. Second, an MDM configuration profile that resets Full Disk Access or real-time protection settings on a schedule will silently undo a manual remediation on macOS or Windows; if the same device relapses on a predictable cadence, check for a device management baseline that is fighting your change rather than re-applying the same manual fix repeatedly. Third, re-scoping one conflicting policy can surface a second, previously-masked conflict with a different policy that was lower in the evaluation order; if a device blocks correctly for one sensitive information type but not another after a precedence fix, re-run the full policy inventory rather than assuming the fix was incomplete. Fourth, a device that was offline long enough to miss several policy versions can come back online, sync, and still enforce the wrong rule set for a short window before catching up; give it one full sync cycle before treating a fresh relapse as a new incident.
Escalation Criteria: When to Open a Microsoft Support Case
Escalate to Microsoft support rather than continuing to self-remediate when any of the following hold. The device shows 'Updated' for both configuration and policy sync status, the Defender sensor and, on macOS, Full Disk Access all check out healthy, and Activity Explorer confirms the correct policy is matching, yet the block still doesn't occur on the endpoint: that combination points to a platform-side enforcement bug rather than a configuration issue you can fix. The DeviceInfo Advanced Hunting query or the Purview device list itself returns inconsistent or contradictory health values for the same device across two consecutive checks, which suggests a telemetry pipeline problem rather than a device problem. The gap affects a large fraction of your onboarded fleet simultaneously rather than isolated devices, which is more consistent with a service-side policy distribution issue than individual device drift. Or the DataLoss Prevention admin log on the endpoint shows a specific error code that isn't documented in Microsoft's troubleshooting reference. Before opening the case, gather the device's OS version, Defender engine and client versions, MDATP device ID, and Valid user status from the device details pane, and run the Microsoft Defender client analyzer for the platform involved; Microsoft support will ask for all of this, and having it ready shortens the case significantly.
The bottom line
A Purview endpoint DLP policy that stops enforcing after working correctly almost always traces to one of four causes: a lower-priority audit policy winning a precedence conflict, a device that has fallen out of configuration or policy sync health, the underlying Defender for Endpoint sensor or macOS Full Disk Access permission being unhealthy, or the documented content scan timeout letting an upload through under load. Diagnose in that order using Activity Explorer, the Purview device onboarding page, the DeviceInfo Advanced Hunting table, and the endpoint's local DataLoss Prevention event log, fix only the specific cause identified, and validate with a real synthetic-data test on the affected device before considering the incident closed.
Frequently asked questions
Why did my Microsoft Purview endpoint DLP policy stop blocking without any alert?
Purview does not generate an alert when endpoint DLP enforcement silently degrades, because most of the causes (a device losing policy sync, an audit policy winning a precedence conflict, or a scan timing out under load) are treated internally as normal operating states rather than failures. The only way to catch the gap is to notice a file that should have been blocked going through, or to proactively monitor device configuration and policy sync status and Activity Explorer's blocked-event attribution rather than assuming silence means the policy is still working.
How do I tell if an audit policy is overriding my block policy in Microsoft Purview?
List every DLP policy scoped to the same location and sensitive information type as the block policy that stopped working, and check each one's enforcement mode and priority. Then look at Activity Explorer for the specific event where the file should have been blocked: it shows which policy actually matched. If a broader or higher-priority audit policy claimed the match, Purview's most-restrictive-rule logic still applied the audit action because that was the highest-precedence rule that matched, not because the block policy itself failed.
What does 'Not updated' mean for policy sync status in Microsoft Purview device onboarding?
'Not updated' policy sync status means the device has not downloaded the current version of the DLP policies assigned to it, so it is still enforcing an older policy version or none at all. Microsoft's documentation notes this status can take up to 2 hours to refresh in the portal even after the underlying cause is fixed, so a device that shows 'Not updated' immediately after a remediation may already be resolved and just hasn't reported it yet.
Does Full Disk Access affect Microsoft Purview endpoint DLP on macOS?
Yes. On macOS, the Defender for Endpoint extension that Purview endpoint DLP relies on for file-level visibility requires Full Disk Access to be granted in System Settings > Privacy & Security. If that permission is revoked, by a macOS update, a user action, or an MDM profile that drifted, the sensor process can still report as running while DLP effectively loses visibility into file activity, which is why sensor health alone is not sufficient to rule out an agent-side cause on macOS.
Is the Microsoft Purview endpoint DLP content scan timeout a bug I should report?
No. The scan timeout (roughly 2 seconds by default before an action is allowed to proceed if classification hasn't finished) is a documented, by-design tradeoff between blocking every action indefinitely and keeping the endpoint usable under load. It is expected to let occasional uploads through unclassified when a device is under heavy CPU load or scanning an unusually large file. Treat it as a known limitation to plan around, such as narrowing sensitive information type patterns, rather than a defect to escalate as a bug.
How is this troubleshooting guide different from a Microsoft Purview DLP implementation guide?
An implementation guide walks through setting up DLP for the first time: choosing sensitive information types, running simulation mode, and configuring policies across Exchange, Teams, and endpoints. This guide starts from the opposite situation, where a policy was already deployed and successfully blocking data, and addresses diagnosing and fixing why enforcement has since silently stopped, using policy precedence review, device health and sync checks, agent diagnostics, and the documented scan timeout as the four root-cause categories.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.