Endpoint DLP Across Defender AV Modes & Third-Party AV Coexistence

About This Lab

Microsoft Purview Endpoint DLP is one of the most commonly misunderstood features in MDE deployments with third-party antivirus. Many security teams assume that Endpoint DLP - like network protection and MDA enforcement - stops working when CrowdStrike or another third-party AV takes over as the primary engine. In reality, Endpoint DLP uses the MDE sensor (MsSense.exe) for all monitoring and enforcement, NOT the Defender Antivirus engine. This architectural distinction means Endpoint DLP works fully in passive and EDR block modes. This lab explores the exact dependency chain, maps all 13 DLP activities across all four AV modes, addresses the most common deployment failures, and provides KQL queries for monitoring DLP enforcement across your fleet.

🏢 Enterprise Use Case

Scenario: A financial services company with 5,000 endpoints runs CrowdStrike Falcon as their primary AV and Microsoft Defender for Endpoint Plan 2 for EDR and vulnerability management. Their compliance team needs to enforce DLP policies on endpoints to prevent credit card numbers and Social Security numbers from being copied to USB drives, printed, uploaded to unauthorized cloud services, or pasted into personal webmail.

The compliance team is concerned that Endpoint DLP will not work because Defender AV is in passive mode. After researching the architecture, they discover that Endpoint DLP depends on the MDE sensor - not the AV engine - and will work fully alongside CrowdStrike. However, they also discover that some devices have Defender in disabled mode (not passive) because CrowdStrike was installed before MDE onboarding - those devices have no DLP enforcement at all.

Success criteria: DLP policies enforced on all onboarded devices regardless of AV mode, browser upload monitoring via Edge and Chrome extension, KQL queries to identify devices with broken DLP enforcement, clear understanding of the DLP vs. network protection architecture difference.

🎯 What You Will Learn

1. How Endpoint DLP uses the MDE sensor (MsSense.exe) and why it works independently of the AV engine
2. The complete Endpoint DLP activity matrix across all four Defender AV modes
3. Why Endpoint DLP works with CrowdStrike but network protection, MDA blocking, and URL indicators do not
4. How to verify that the MDE sensor and Endpoint DLP are working on devices with CrowdStrike
5. The difference between CrowdStrike Falcon Data Protection and Microsoft Endpoint DLP and how to avoid conflicts
6. How to troubleshoot the four most common Endpoint DLP deployment failures
7. How to use KQL to monitor DLP events, detect enforcement gaps, and track policy violations
8. The architectural comparison between Endpoint DLP and network protection features

🔑 Why This Matters

Data loss is a regulatory and reputational risk that compounds over time. Organizations that delay Endpoint DLP deployment because they incorrectly believe it requires Defender AV in active mode are leaving sensitive data unprotected. Understanding that Endpoint DLP uses the MDE sensor (not the AV engine) means you can deploy DLP policies immediately on all MDE-onboarded devices - even those running CrowdStrike. The only failure mode is when Defender is in disabled mode (not passive), which means the MDE sensor itself is not running. This lab ensures you can distinguish between these modes and deploy DLP with confidence.

• Licensing: Microsoft 365 E5 / E5 Compliance / E5 Information Protection & Governance, or standalone Microsoft Purview DLP add-on
• MDE Onboarding: Devices must be onboarded to Microsoft Defender for Endpoint (SENSE service running)
• Devices: Windows 10/11 (1809+) or Windows Server 2019/2022, or macOS 12+ (limited DLP feature set)
• Purview Portal Access: Compliance Administrator or DLP Compliance Management role in purview.microsoft.com
• Endpoint DLP Enabled: Purview portal > Settings > Data loss prevention > Endpoint DLP settings > Device onboarding
• Third-party AV (optional): CrowdStrike Falcon or similar for coexistence testing
• Browser extensions: Microsoft Edge 83+ (built-in) or Chrome with Purview DLP extension for browser upload monitoring
• Prior Labs: Completion of DLP Lab 01 (Deploy Endpoint DLP) and MDE Lab 06 (AV Modes) is recommended

The MDE Sensor Dependency

Microsoft Purview Endpoint DLP does NOT use a separate agent. It runs entirely on the MDE sensor (MsSense.exe). This is the critical architectural fact that determines everything:

• Endpoint DLP uses the MDE sensor's file system filter driver to monitor file operations
• It uses the MDE sensor's process monitoring to track clipboard, print, and app access
• DLP policies are delivered through the MDE cloud service and enforced locally by the sensor
• DLP activity logs are sent back through the MDE telemetry channel

Complete Endpoint DLP Capability Matrix

Why Endpoint DLP Works with CrowdStrike

Unlike network protection features (which require Defender AV to be active), Endpoint DLP uses different components of the MDE stack:

• File system minifilter driver (MDE sensor): Monitors file create/copy/move operations - works in passive mode
• Process monitoring (MDE sensor): Tracks which apps access files, clipboard ops - works in passive mode
• Print spooler hooks: Intercepts print operations - works as long as MDE sensor is running
• Browser extensions (Edge Chromium): Monitors browser upload/paste activities - works independently of AV mode

Verify Endpoint DLP Is Working with CrowdStrike Present

# Step 1: Confirm MDE sensor is running (required for DLP)
Get-Service Sense | Select-Object Status, StartType
# Must show: Running / Automatic

# Step 2: Confirm Defender AV mode (passive = OK for DLP)
Get-MpComputerStatus | Select-Object AMRunningMode
# Passive or EDR Block Mode = DLP works fine

# Step 3: Confirm CrowdStrike is running alongside
Get-Service CSFalconService | Select-Object Status
# Should show: Running

# Step 4: Check DLP policy sync status
# Open Event Viewer > Applications and Services > Microsoft > Windows > MDE-DiagTrack
# Look for event ID 1 showing successful policy pull

# Step 5: Test DLP enforcement
# Create a test file with known sensitive content (e.g., 16-digit number for credit card SIT)
# Attempt to copy it to a USB drive
# You should see the DLP policy tip toast notification on the endpoint

Pain Point #1: "DLP Policies Exist But No Alerts Are Generated"

Root causes (in order of likelihood):

1. Device not onboarded to MDE: Endpoint DLP requires MDE onboarding. Check Get-Service Sense - if not running, DLP cannot work.
2. Defender AV in disabled mode: If the MDE sensor is also not running, DLP cannot work. Verify with Get-Service Sense. If the sensor is stopped, re-onboard the device.
3. Policy not synced: DLP policies can take time to sync to endpoints. Check the Purview portal under Endpoint DLP settings to verify the device is listed.
4. Wrong content match: Test with a known sensitive information type (SIT). Use Microsoft's test numbers (e.g., 4539 9930 1034 7418 for credit card).
5. Device group not targeted: Check Purview portal > Data loss prevention > Endpoint DLP settings > Device onboarding. Verify the device appears.

Pain Point #2: "USB Copy Blocking Works But Browser Upload Does Not"

Root cause: Browser upload monitoring requires the Microsoft Purview browser extension or Microsoft Edge (Chromium-based). Without the right browser configuration:

• Microsoft Edge: Built-in DLP integration, no extension needed. Must be version 83+.
• Google Chrome: Requires the Microsoft Purview DLP extension from Chrome Web Store. Deploy via Group Policy or Intune.
• Firefox: Not supported for Endpoint DLP browser monitoring.
• Non-browser apps: Configure "Unallowed apps" in Purview DLP settings for apps like WinSCP, FileZilla, etc.

Pain Point #3: "DLP Shows Audit Events But Block Actions Don't Work"

Root cause: Policy is set to "Audit" instead of "Block with override" or "Block." Check your DLP policy rule actions:

1. Go to Purview portal > Data loss prevention > Policies
2. Edit the policy > Advanced DLP rules
3. Check the action: "Restrict access or encrypt the content in Microsoft 365 locations"
4. Under "Device" section, confirm "Block" or "Block with override" is selected for each activity
5. Audit-only mode generates alerts but NEVER blocks the action

Pain Point #4: "CrowdStrike Falcon Data Protection vs. Microsoft Endpoint DLP - Conflicts?"

Answer: They can coexist but you must understand the layering:

• No conflict at the driver level: Microsoft Endpoint DLP uses the MDE sensor's minifilter. CrowdStrike Falcon Data Protection uses its own driver. Both can monitor file I/O simultaneously.
• Potential double-blocking: If both products have policies for the same activity (e.g., USB copy block for credit card data), the user may see two block notifications. Decide which product owns which policy.
• Recommended approach: Use ONE product for endpoint DLP enforcement. Either Microsoft Purview Endpoint DLP OR CrowdStrike Falcon Data Protection - not both for the same activities. Use the other for audit/visibility only.

KQL Queries for DLP Monitoring

The following queries use Advanced Hunting tables in the Defender XDR portal. ActionType values and column names may vary by MDE agent version. Test in your environment and consult the Advanced Hunting schema reference for current schema.

// Find all Endpoint DLP policy matches in the last 7 days
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType startswith "Dlp"
| summarize EventCount = count() by ActionType, DeviceName
| sort by EventCount desc

// USB copy violations - who is copying sensitive data to USB
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "DlpCopyToRemovableMedia"
| project Timestamp, DeviceName, FileName, InitiatingProcessAccountName,
    AdditionalFields
| sort by Timestamp desc

// Find devices where DLP should be active but no events are logged
// (potential enforcement gap - maybe disabled mode)
DeviceInfo
| where Timestamp > ago(1d)
| where OnboardingStatus == "Onboarded"
| join kind=leftanti (
    DeviceEvents
    | where Timestamp > ago(30d)
    | where ActionType startswith "Dlp"
    | distinct DeviceId
) on DeviceId
| project DeviceName, OSPlatform, LastSeen = Timestamp
| sort by LastSeen asc

// Cloud upload violations - what are users uploading and where
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "DlpUploadToCloud"
| extend Details = parse_json(AdditionalFields)
| project Timestamp, DeviceName, FileName,
    InitiatingProcessAccountName,
    TargetDomain = Details.TargetDomain,
    PolicyName = Details.PolicyName
| sort by Timestamp desc

Side-by-Side Comparison

This is the source of most confusion. Endpoint DLP and network-based features use different MDE components:

Post-Deployment Validation

1. Confirm MDE sensor (Sense service) is running on all target devices
2. Confirm Defender AV is in passive mode (not disabled) when CrowdStrike is present
3. Verify devices appear in Purview portal > Endpoint DLP settings > Device onboarding
4. Test USB copy with known sensitive content - confirm block/audit works
5. Test browser upload - confirm Edge works natively, Chrome requires extension
6. Test print operation with sensitive content
7. Run KQL queries from Step 5 - confirm DLP events flow to Advanced Hunting
8. Check Activity Explorer in Purview portal for DLP activity entries

What You Accomplished

• Understood the MDE sensor dependency - Endpoint DLP uses MsSense.exe, not the Defender AV engine
• Mapped all 13 Endpoint DLP activities (USB, print, clipboard, browser upload, screen capture, etc.) across all four AV modes
• Confirmed that Endpoint DLP works fully in Active, Passive, and EDR Block modes - only Disabled mode breaks it
• Verified DLP enforcement on devices running CrowdStrike with PowerShell diagnostics
• Distinguished between CrowdStrike Falcon Data Protection and Microsoft Endpoint DLP to avoid double-blocking
• Troubleshot the four most common Endpoint DLP deployment failures
• Built KQL queries to monitor DLP events, detect enforcement gaps, and track policy violations
• Understood the architectural difference between Endpoint DLP (MDE sensor) and network protection (AV engine)

Cost Considerations

• Endpoint DLP requires Microsoft 365 E5 / E5 Compliance / E5 Information Protection, or standalone Purview DLP add-on
• MDE Plan 2 (for the sensor) may already be licensed through E5 - no additional endpoint cost
• Chrome DLP extension is free to deploy but requires Intune or GPO for enterprise rollout
• Advanced hunting queries run against 30 days of retained data; forwarding to Sentinel for longer retention incurs data ingestion costs
• Activity Explorer data is retained for 30 days in the Purview portal at no additional cost

Cleanup (Lab Environment Only)

• Delete test DLP policies created during the lab or switch them to audit-only mode
• Remove test files containing sensitive content from endpoints
• Remove the Chrome DLP extension from test devices if no longer needed
• Resolve test DLP alerts in the Defender XDR portal

Next Steps

• Expand DLP policies to cover Teams & Exchange in DLP Lab 02
• Investigate DLP incidents in the unified XDR portal with DLP Lab 03
• Build an enterprise DLP dashboard for executive reporting with DLP Lab 04
• Understand the full AV mode impact on MDE features with MDE Lab 06
• Configure Insider Risk Management to correlate DLP violations with user behavior patterns
• Use Security Copilot to analyze DLP trends and recommend policy tuning