Defender Antivirus Modes, MDA Integration & Third-Party AV Coexistence

About This Lab

Microsoft Defender Antivirus operates in one of four modes - Active, Passive, EDR in Block Mode, or Disabled - depending on whether a third-party antivirus product is installed and how MDE is configured. Most organizations running CrowdStrike, SentinelOne, or another third-party AV alongside MDE do not fully understand which MDE capabilities survive in passive mode and which silently stop working. This lab systematically maps every MDE feature across all four AV modes, with a focus on the network-dependent features (MDA unsanctioned app blocking, custom URL/IP/domain indicators, web content filtering, network protection) that require Defender AV to be the active engine. You will learn to identify the enforcement gap, build compensating controls, and validate your architecture with KQL queries.

🏢 Enterprise Use Case

Scenario: Contoso Ltd runs CrowdStrike Falcon as their primary endpoint AV across 8,000 devices. They also have MDE Plan 2 for EDR, vulnerability management, and threat analytics. The security team recently deployed Defender for Cloud Apps and marked several shadow IT applications (Dropbox, WeTransfer, Mega) as "Unsanctioned." They also created custom URL/IP indicators to block known phishing infrastructure. After two weeks, the SOC discovers that users on CrowdStrike endpoints can still freely access all unsanctioned apps and blocked URLs - the indicators show as "Active" in the portal but enforcement never reaches the endpoints.

Root cause: Defender AV is in passive mode on all CrowdStrike devices. The network protection driver (WdNisDrv.sys) only loads when Defender is the active AV engine. All network-dependent MDE features - MDA blocking, custom URL/IP indicators, web content filtering, and network protection - silently fail. Meanwhile, file hash indicators and endpoint DLP continue to work because they use the MDE sensor, not the AV engine.

Success criteria: correctly identify all affected features, enable EDR in block mode for post-breach remediation, implement proxy/DNS-based alternatives for URL/IP enforcement, and deploy a KQL detection rule that alerts when devices in passive mode access blocked resources.

🎯 What You Will Learn

1. How to identify and verify the current Defender AV mode on any endpoint (Active, Passive, EDR Block, Disabled)
2. How the MDE sensor runs independently of Defender AV in CrowdStrike + MDE coexistence
3. How to set ForceDefenderPassiveMode as a baseline policy to guarantee passive mode
4. How to enable EDR in block mode as a defense-in-depth safety net alongside CrowdStrike
5. Which MDE features work in each AV mode - the complete 18-feature capability matrix
6. Why MDA unsanctioned app blocking fails silently with CrowdStrike and what alternatives exist
7. Which custom indicator types (URL, IP, file hash, certificate) survive passive mode and which do not
8. How to build KQL detection rules that expose the enforcement gap
9. The four most common pain points in CrowdStrike + MDE deployments and how to troubleshoot each
10. How to choose the right architecture: MDE-only vs CrowdStrike+MDE vs CrowdStrike+MDE+proxy

🔑 Why This Matters

The gap between "indicator created in the portal" and "indicator enforced on the endpoint" is where organizations get breached. When security teams create URL/IP block indicators or mark apps as unsanctioned, they expect enforcement across all endpoints. But with a third-party AV in place, these controls silently fail on every device - with no error, no warning, and no log entry. The Defender portal still shows the indicator as "Active" and the app as "Unsanctioned." This creates a false sense of security that persists until a real incident exposes the gap. Understanding AV mode dependencies is essential for any organization running dual AV/EDR stacks.

• Licensing: Microsoft Defender for Endpoint Plan 2 (or Microsoft 365 E5 / E5 Security)
• Devices: Windows 10/11 or Windows Server 2019/2022 onboarded to MDE
• Third-party AV (optional): CrowdStrike Falcon, SentinelOne, or similar for coexistence testing
• Portal Access: Security Administrator role in security.microsoft.com
• Defender for Cloud Apps: Microsoft Defender for Cloud Apps license for MDA integration testing
• PowerShell: Administrator access on test endpoints for Get-MpComputerStatus and registry changes
• Advanced Hunting: Familiarity with KQL and the DeviceInfo, DeviceNetworkEvents, and DeviceTvmInfoGathering tables
• Prior Labs: Completion of MDE Lab 01 (Onboarding) and Lab 05 (Network Protection) is recommended

The Four Modes of Microsoft Defender Antivirus

Microsoft Defender Antivirus operates in one of four modes depending on whether a third-party antivirus product is installed and how MDE is configured. Getting this wrong is the single most common reason MDE features silently stop working.

Verify Current AV Mode

Run this PowerShell command on any endpoint to check the current Defender AV state:

# Check Defender Antivirus mode
Get-MpComputerStatus | Select-Object AMRunningMode, AMServiceEnabled,
    AntispywareEnabled, AntivirusEnabled, RealTimeProtectionEnabled,
    IsTamperProtected, IsVirtualMachine

# Expected outputs:
# Active mode:  AMRunningMode = Normal, AntivirusEnabled = True
# Passive mode: AMRunningMode = Passive, AntivirusEnabled = True (but RTP = False)
# EDR Block:    AMRunningMode = EDR Block Mode (same as passive + post-breach remediation)
# Disabled:     AMRunningMode = Not Running OR AMServiceEnabled = False

KQL: Identify AV Mode Across Your Fleet

The following queries use Advanced Hunting tables. Column names and available fields may vary by MDE agent version and tenant configuration. Test in your environment and adjust as needed.

// Advanced Hunting: Find devices and their AV mode
DeviceTvmInfoGathering
| where AdditionalFields has "AvMode"
| extend AvMode = parse_json(AdditionalFields).AvMode
| summarize arg_max(Timestamp, *) by DeviceId
| project DeviceName, AvMode, Timestamp
| summarize DeviceCount = count() by tostring(AvMode)

// Find devices where Defender AV is completely disabled
DeviceInfo
| where Timestamp > ago(1d)
| where OnboardingStatus == "Onboarded"
| join kind=leftanti (
    DeviceTvmInfoGathering
    | where AdditionalFields has "AntivirusEnabled"
    | where parse_json(AdditionalFields).AntivirusEnabled == true
    | distinct DeviceId
) on DeviceId
| project DeviceName, OSPlatform, OnboardingStatus

Coexistence Architecture

The behavior when a third-party AV is present differs between Windows client and Windows Server:

• Windows 10/11 (client): Defender AV automatically enters passive mode when a third-party AV is detected and the device is onboarded to MDE. No manual configuration is needed.
• Windows Server: Defender AV does NOT automatically enter passive mode. You must set ForceDefenderPassiveMode = 1 in the registry to put Defender into passive mode. Without this, both Defender and the third-party AV may run in active mode simultaneously, which can cause performance issues and conflicts.
• MDE sensor (MsSense.exe): Runs independently of Defender AV on both client and server. Provides EDR telemetry, live response, device inventory, TVM, and Endpoint DLP regardless of the AV mode.

ForceDefenderPassiveMode - Required for Windows Server

On Windows Server, you must set this registry key to put Defender AV into passive mode when a third-party AV is installed. On Windows client (10/11), this is optional since passive mode is automatic, but can be set as an explicit safeguard:

# Force Defender AV into passive mode (requires reboot)
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection" `
    -Name "ForceDefenderPassiveMode" -Value 1 -Type DWord

# Verify after reboot
Get-MpComputerStatus | Select-Object AMRunningMode
# Should show: Passive or EDR Block Mode

# Via Intune: Endpoint Security > Antivirus > Microsoft Defender Antivirus
# Set "Allow antivirus service running alongside third-party AV" = Allowed

Why EDR in Block Mode Matters with CrowdStrike

EDR in block mode is a safety net. When CrowdStrike misses a threat (no AV is 100%), Defender's EDR engine detects it post-execution and remediates using its own engine - even though Defender AV real-time protection is off.

1. Navigate to Microsoft Defender XDR portal > Settings > Endpoints > General > Advanced features
2. Enable "Enable EDR in block mode"
3. This is a tenant-wide setting - applies to ALL devices in passive mode
4. No device-level configuration needed

What Works and What Breaks in Each Mode

The table below maps MDE features to AV modes. Feature availability can change between Windows and MDE agent versions. Always verify against the official Microsoft Defender Antivirus compatibility documentation for your specific environment.

How MDA Unsanctioned App Enforcement Works

When you tag an app as "Unsanctioned" in Defender for Cloud Apps, the enforcement path goes through MDE's network protection on the endpoint:

1. Admin marks app as "Unsanctioned" in the MDA cloud app catalog
2. MDA generates URL/domain indicators and pushes them to MDE
3. MDE's network protection driver intercepts the traffic on the endpoint
4. User sees a block page when trying to access the unsanctioned app

Alternatives When MDA Blocking Fails (Passive Mode)

If you run CrowdStrike as primary AV, you need alternative enforcement for unsanctioned apps:

• Conditional Access App Control (CAAC): Uses a reverse proxy - works regardless of AV mode. Requires Azure AD Conditional Access + MDA session policies. Only works for apps users access through a browser.
• CrowdStrike Falcon URL filtering: Use CrowdStrike's own URL/domain blocking to enforce the same list. Requires manual sync or API automation between MDA and CrowdStrike.
• Firewall/proxy-level blocking: Block domains at the network perimeter using Zscaler, Palo Alto, or similar. Works for all devices regardless of endpoint AV.
• DNS-level blocking: Use DNS filtering (e.g., Azure DNS Private Resolver, Cisco Umbrella) to block resolution of unsanctioned app domains.

KQL: Detect Unblocked Access to Unsanctioned Apps

// Find devices accessing unsanctioned apps despite "block" policy
// This query exposes the passive mode enforcement gap
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any ("dropbox.com", "wetransfer.com", "mega.nz") // your unsanctioned apps
| where ActionType == "ConnectionSuccess" // should be "ConnectionBlocked" if enforcement works
| summarize AccessCount = count(), LastAccess = max(Timestamp) by DeviceName, RemoteUrl
| sort by AccessCount desc

// Cross-reference with AV mode to confirm the gap
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any ("dropbox.com", "wetransfer.com")
| where ActionType == "ConnectionSuccess"
| join kind=inner (
    DeviceTvmInfoGathering
    | extend AvMode = tostring(parse_json(AdditionalFields).AvMode)
    | where AvMode == "Passive" or AvMode == "SxS Passive"
    | summarize arg_max(Timestamp, *) by DeviceId
) on DeviceId
| project DeviceName, RemoteUrl, AvMode, Timestamp

Indicator Types and Their AV Mode Dependency

Not all custom indicators are equal when CrowdStrike is present:

Pain Point #1: "We Set Up MDA Unsanctioned Apps But Users Still Access Them"

Root cause: CrowdStrike is the primary AV. Defender is in passive mode. Network protection driver is unloaded. MDA enforcement path to the endpoint is broken.

How to diagnose:

# On the endpoint
Get-MpComputerStatus | Select-Object AMRunningMode
# If "Passive" or "EDR Block Mode" - network protection is NOT active

# Check if network protection is reporting
Get-MpPreference | Select-Object EnableNetworkProtection
# 0 = Disabled, 1 = Enabled (block), 2 = Audit
# Even if set to 1, it is ignored in passive mode

# Verify SmartScreen / network filter driver
sc query WdNisDrv
# If STATE is STOPPED - no network-level enforcement is possible

Pain Point #2: "Custom URL/IP Indicators Show as Active But Don't Block"

Root cause: Same as above. The indicator is stored in the MDE cloud and synced to the device, but the network protection driver that enforces it is not loaded.

What makes it worse: The Defender portal shows the indicator as "Active" with a green status. There is NO warning that enforcement depends on active AV mode. Admins assume it is working until an incident proves otherwise.

Pain Point #3: "Web Content Filtering Categories Don't Apply"

Root cause: Web content filtering uses the same network protection stack. Passive mode = no filtering.

Alternative: Use CrowdStrike Falcon's URL filtering categories, or deploy a dedicated web proxy (Zscaler, Netskope) that works independently of the endpoint AV engine.

Pain Point #4: "Devices Show as Onboarded But No Telemetry in Advanced Hunting"

Root cause: Defender AV is not running (service disabled or not installed). The MDE sensor may also be missing if the device was never onboarded. Verify with Get-Service Sense - if the SENSE service is not present, the device needs to be onboarded to MDE.

// Find onboarded devices with no recent telemetry (likely disabled mode)
DeviceInfo
| where Timestamp > ago(1d)
| where OnboardingStatus == "Onboarded"
| join kind=leftanti (
    DeviceEvents
    | where Timestamp > ago(1d)
    | distinct DeviceId
) on DeviceId
| project DeviceName, OSPlatform, LastSeen = Timestamp
| sort by LastSeen asc

Architecture Options Summary

Post-Deployment Validation

1. Confirm every device reports AMRunningMode = Passive (not Disabled)
2. Confirm EDR in block mode is enabled tenant-wide
3. Test a file hash indicator - confirm block works in passive mode
4. Test a URL indicator - confirm it does NOT block in passive mode
5. Test MDA unsanctioned app - confirm access is NOT blocked at the endpoint
6. Confirm your alternative enforcement (proxy/DNS/CAAC) blocks unsanctioned apps
7. Run the KQL queries above to confirm no devices are in disabled mode
8. Set up an alert for new devices entering disabled mode

Microsoft Documentation References

• Defender Antivirus compatibility with other security products
• EDR in block mode
• Network protection
• Manage indicators
• MDA integration with MDE
• Defender AV on Windows Server

What You Accomplished

• Identified all four Defender AV modes (Active, Passive, EDR Block, Disabled) and how to verify the current mode on any endpoint
• Understood how the MDE sensor runs independently of Defender AV and how ForceDefenderPassiveMode ensures passive mode as a baseline policy
• Enabled EDR in block mode as a defense-in-depth safety net that catches threats CrowdStrike misses
• Mapped 18 MDE features across all four AV modes using the definitive capability matrix
• Understood why MDA unsanctioned app blocking fails in passive mode and configured alternative enforcement via proxy/DNS/CAAC
• Distinguished which custom indicator types survive passive mode (file hash, certificate) and which do not (URL, IP, domain)
• Built KQL queries to detect unsanctioned app access, identify disabled-mode devices, and expose enforcement gaps
• Diagnosed the four most common CrowdStrike + MDE deployment pain points with PowerShell and KQL
• Evaluated three architecture options and selected the right approach for your organization

Cost Considerations

• EDR in block mode is included in MDE Plan 2 at no additional cost
• Custom indicators (all types) are included in MDE Plan 1 and Plan 2
• Defender for Cloud Apps (MDA) requires a separate license (included in Microsoft 365 E5)
• Conditional Access App Control (CAAC) proxy services are included in the MDA license
• Third-party proxy/DNS solutions (Zscaler, Netskope, Cisco Umbrella) have separate licensing costs

Cleanup (Lab Environment Only)

• Remove ForceDefenderPassiveMode registry key if you want Defender to return to active mode: Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection" -Name "ForceDefenderPassiveMode"
• Delete test custom indicators (URLs, IPs, file hashes) created during the lab
• Remove any test MDA unsanctioned app tags if they impact production users
• Resolve test alerts generated by EDR in block mode

Next Steps

• Deploy Conditional Access App Control for browser-based SaaS enforcement that works regardless of AV mode
• Build a Sentinel workbook that visualizes AV mode distribution and enforcement gaps across your fleet
• Automate MDA-to-proxy sync so unsanctioned app lists are enforced at the network level
• Explore Endpoint DLP configuration in DLP Lab 05 - one of the features that works fully in passive mode
• Use Security Copilot to analyze AV mode inconsistencies and recommend remediation across your fleet