Defender for Endpoint Troubleshooting Guide

Microsoft Defender for Endpoint (MDE) is Microsoft’s advanced security solution that helps protect your devices from cyber threats. In simple terms, it’s the system that continuously watches over your computers and servers, detecting suspicious behavior, blocking attacks, and alerting you before small issues turn into major security incidents.

When everything’s working properly, Defender for Endpoint provides visibility into what’s happening across your network. But when it’s not, that visibility can quickly disappear. Devices might fail to show up in the portal, sensors can stop sending data, or the system might stay stuck in passive mode, leaving gaps in your protection.

This Defender for Endpoint Troubleshooting Guide explains how to recognize and address these issues before they impact your ability to detect and respond to threats, and how Levacloud can help you get your environment back to full protection faster.

When Microsoft Defender for Endpoint isn’t working as expected, your visibility into potential threats immediately starts to shrink. You might still see activity in the Microsoft 365 Defender portal, but behind the scenes, telemetry gaps or failed device onboarding can leave parts of your network effectively unmonitored.

That loss of visibility is a security risk. Defender for Endpoint depends on continuous communication between your devices and Microsoft’s cloud services. If that link is interrupted, alerts won’t populate, detections can be delayed, and automated responses may fail to trigger.

Understanding where these issues occur and how to resolve them ensures that every endpoint is contributing telemetry, every alert is captured, and every threat response is backed by complete data.

Even with a clean deployment, Defender for Endpoint can run into issues that affect visibility, telemetry, or device protection. Understanding where these problems start is the first step to fixing them efficiently. Below are the most common troubleshooting scenarios our team sees when helping organizations get their Defender environments fully operational.

Troubleshooting Defender for Endpoint Onboarding

Goal: Confirm that a device appears in the Microsoft 365 Defender portal, reports telemetry, and that Defender Antivirus is in the correct mode. Active or Passive (if you’ve intentionally chosen a third-party AV strategy).

Symptoms that Point to Onboarding Trouble

• Newly enrolled devices never appear in the Defender portal.
• Devices show up but stop updating their Last seen
• Defender Antivirus remains in Passive or EDR Block Mode when you expect Active.

Quick Triage

1. Portal Visibility – Search the device hostname in the Microsoft 365 Defender portal. If it hasn’t appeared after an hour, treat it as not onboarded.
2. Antivirus Conflicts – Confirm no third-party AV or EDR is still registered in Windows Security Center. Even partial remnants keep Defender in passive mode until they’re removed and the device rebooted.
3. Network Reachability – Ensure the endpoint can reach the required Microsoft Defender service URLs and that SSL inspection is disabled. If onboarding appears to succeed locally but the device doesn’t report data, this is the most likely cause.

Step-by-Step Diagnostics

1. Confirm the Device’s Onboarding Status
   Check the SENSE event logs under Applications and Services Logs > Microsoft > Windows > SENSE. Errors here typically indicate sensor or policy delivery issues.
   Verify that the latest onboarding package or Intune policy was applied correctly and hasn’t been overwritten by older configurations.
   Reference: Microsoft: Onboard devices to Defender for Endpoint
2. Eliminate Third-Party Antivirus Remnants
   Windows automatically switches Defender to passive mode when another antivirus is registered. If Defender remains passive after removal, residual drivers or registry entries are likely still present. Perform a full cleanup and reboot before retesting.
3. Validate Network and Proxy Configuration
   Defender for Endpoint requires outbound HTTPS connectivity to Microsoft’s Defender service URLs. If those URLs are blocked, filtered, or intercepted by SSL inspection, telemetry cannot flow.
   After confirming access, retest onboarding to ensure telemetry starts updating within the portal.
4. Confirm Deployment Consistency
   If several devices in the same group fail, compare the onboarding method (Intune, GPO, or manual script) and confirm they use the same, current policy version. Mixing older onboarding packages with new ones often causes silent mismatches.

What “Good” Looks Like

• The device is visible in the Defender portal with a current Last seen
• SENSE logs show no repeated initialization or connectivity errors.
• Defender Antivirus runs in the expected mode with live telemetry flowing.

Defender Sensor and Data Collection Issues

Once a device is onboarded, Microsoft Defender for Endpoint relies on the sensor (MsSense.exe) to collect telemetry and send it to Microsoft’s cloud for analysis. The sensor is the heartbeat of the platform. If it fails or loses connectivity, detections stop appearing, automation slows down, and incident timelines become incomplete.

Symptoms of Sensor or Data Collection Problems

You may be dealing with a sensor issue if:

• A device is visible in the Microsoft 365 Defender portal but its Last seen time is outdated.
• The Defender Antivirus component is active, but no endpoint detections or incidents appear.
• The Microsoft Defender for Endpoint service (SENSE) won’t start or keeps restarting.
• Event logs show repeated entries referencing SENSE initialization or connectivity failures.

A. Validate the Sensor’s Operating State

Start by confirming that the SENSE service is running on the affected device. If it fails to start or repeatedly stops, the underlying issue is usually one of the following:

• Another security agent has disabled or interfered with the Defender components.
• One or more Defender dependencies (such as the Windows Security Center or Network Inspection Service) have been disabled by policy.
• The device is in Passive Mode, which limits sensor functionality and prevents active detections.

If you’ve recently removed a third-party antivirus, ensure all its drivers and services are fully cleared. Defender can remain in Passive Mode if remnants still exist in the Windows Security Center registry.

B. Confirm the Sensor Can Communicate with Microsoft

The Defender sensor sends telemetry over outbound HTTPS connections. If these are blocked or intercepted, the device will appear onboarded but fail to deliver data to Microsoft’s cloud.

Common causes include:

• Proxy configuration issues where system-level authentication is required but not configured.
• SSL inspection that breaks encrypted communication between Defender and Microsoft endpoints.
• Firewall rules that block outbound access to the Defender telemetry domains.

You can verify this by checking the SENSE Operational event log for repeated upload or handshake failures. Microsoft documents the exact domains and ports required in their environment configuration guide. These should always be reachable directly, without packet inspection or content modification.

C. Review Local Logs for Sensor Health

Each device maintains local logs that record Defender’s behavior and communication status. These logs are stored in the ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Logs directory and include files such as SenseIR.log and Telemetry.log.

If you see repeated errors like “Upload failed,” “Handshake error,” or “Failed to initialize sensor,” it indicates the device cannot reach Microsoft’s telemetry ingestion service or the sensor is failing to authenticate.

Clearing these issues typically requires restoring network access to the Defender endpoints, confirming no SSL interception is occurring, and ensuring all Defender services are running under their default startup types.

D. Confirm Data Visibility in the Portal

After resolving the service or network problem, the easiest validation step is in the Microsoft 365 Defender portal itself. A healthy device should display:

• An updated Last seen timestamp within minutes of the sensor resuming connectivity.
• Active telemetry and alert data under the device’s timeline.
• Normal policy synchronization without repeated onboarding attempts.

If a device remains inactive or shows inconsistent reporting after network and service checks, the sensor installation itself may be corrupt. Re-onboarding the device with a current package usually resolves that condition.

Detection or Alert Delays

Even when devices appear healthy and the Defender sensor is running, you may still notice delayed detections or missing alerts in the Microsoft 365 Defender portal. This often points to a telemetry flow or configuration synchronization problem rather than a failure of the Defender engine itself.

A. Understanding How Detections Flow

When Defender for Endpoint identifies a suspicious event, that telemetry is correlated in Microsoft’s cloud analytics service. The local device flags the event, uploads metadata, and the portal displays it as a detection or alert.
If there’s a delay in any step of that chain (sensor collection, cloud submission, or portal correlation) detections will appear late or not at all.

Common points of failure include:

• The sensor is collecting data but cannot upload it due to proxy or firewall restrictions.
• Telemetry uploads are queued locally because of network latency or packet inspection.
• The Defender portal’s correlation engine hasn’t yet processed the batch due to missing dependencies (for example, an incomplete EDR signal from another onboarded sensor).

B. Confirm the Device’s Current Protection Mode

If detections seem inconsistent, first verify whether the endpoint is running in Active Mode or Passive Mode.

In Passive Mode, Defender for Endpoint continues to collect telemetry but does not enforce blocking actions or real-time scanning. This means detections will still appear, but without automated response actions such as process termination or network isolation.

If you expect Active Mode but see Passive, check for any remaining third-party antivirus registration in the Windows Security Center. Defender automatically defers to other security products until they’re completely unregistered.

C. Check Telemetry Upload Health

Detection delays are frequently caused by telemetry queues that cannot upload. When the sensor is functioning but network connectivity is partially restricted, you might see long delays between the event’s local occurrence and its appearance in the Defender portal.

Indicators of this problem include:

• The Last seen time continues to update, but new alerts take hours to appear.
• Local logs show “Upload failed” or “Response timeout” messages.
• Devices in restricted networks (especially behind authenticated proxies or with SSL inspection enabled) experience longer gaps between detections and incident creation.

The fix typically involves reviewing outbound HTTPS communication and ensuring all required Defender endpoints are reachable without interception. Microsoft provides the full endpoint list in its Defender configuration documentation.

D. Verify Policy and Configuration Synchronization

In some cases, delayed or missing detections are caused by outdated policies or misaligned configurations between Intune, Group Policy, and Defender for Endpoint.

If multiple management systems apply security baselines to the same devices, conflicting policies can overwrite Defender’s local configuration, disabling features such as cloud-delivered protection, automatic sample submission, or network protection.
When those features are turned off, Defender’s detection coverage becomes inconsistent across devices.

Ensuring a single source of truth (preferably through Intune or Microsoft Security Baselines) helps keep policies synchronized and guarantees that every endpoint reports detections with the same logic and timing.

E. What to Look for After Resolution

After connectivity and configuration are restored, detections should begin normalizing in the Defender portal.
You should see:

• Timely alerts and incidents linked to recent activity.
• Updated timestamps under Last detected and Last seen.
• Incident correlation between multiple devices as expected.

If detections remain inconsistent after confirming these areas, the issue often lies with stale configuration data or a corrupted Defender policy. Re-onboarding the device using a clean, updated package typically resets telemetry and restores proper detection timing.

Once you’ve addressed onboarding, sensor health, detection consistency, and integration alignment, the next step is deeper analysis. For most environments, this comes down to three focus areas:

1. Connectivity Validation – Confirm Defender endpoints can reach all required Microsoft URLs directly, without SSL inspection or proxy authentication issues. Even a single blocked domain can stop telemetry.
2. Sensor Health Review – Use event logs under Microsoft-Windows-SENSE to identify persistent upload, initialization, or handshake errors. Consistent failure patterns usually point to proxy misconfiguration or service dependencies being disabled.
3. Configuration Integrity – Validate that your Defender, Intune, and Entra ID baselines align. Conflicting policies can reintroduce the same issues you’ve just resolved.

These steps help isolate lingering communication or policy anomalies after basic troubleshooting, but if the root cause remains unclear, Levacloud can help you perform a deeper review of network paths, log correlation, and baseline validation to ensure Defender operates at fully across every endpoint.

Work with Levacloud to optimize your configuration

Microsoft Defender for Endpoint is an exceptionally capable platform, but it depends on precise configuration and uninterrupted communication with Microsoft’s cloud to deliver full protection. When onboarding stalls, sensors fail, or alerts go missing, the impact reaches beyond visibility, it weakens your ability to detect and contain threats quickly.

Most issues can be resolved by addressing the core themes in this guide: clearing residual antivirus software, validating network access, ensuring sensor stability, and aligning Intune and Entra ID policies. These checks often restore normal operation without major rework.

For environments with persistent onboarding failures, sensor instability, or cross-platform reporting inconsistencies, a deeper diagnostic review is worth the effort. Levacloud can help you analyze log data, verify your configuration, and implement best practices tailored to your environment, so Defender for Endpoint works the way it’s meant to.

What is Microsoft Defender for Endpoint troubleshooting?

Defender for Endpoint troubleshooting is the process of identifying and resolving configuration, connectivity, or policy issues that prevent devices from fully integrating with Microsoft’s Defender service. It focuses on restoring telemetry, re-establishing cloud communication, and ensuring the Defender sensor is actively reporting data to the Microsoft 365 Defender portal.

Why is my device not showing in the Microsoft 365 Defender portal?

This usually means the device hasn’t onboarded correctly. The most common causes are incomplete onboarding scripts, blocked outbound HTTPS connections to Defender’s service URLs, or remnants of another antivirus product keeping Defender in passive mode. Reviewing onboarding logs and verifying network access typically resolves it.

Why is Defender for Endpoint stuck in passive mode?

Defender automatically switches to passive mode when another antivirus or EDR solution is still registered with Windows Security Center. Even if that product has been uninstalled, leftover registry entries or drivers can keep Defender from activating. Fully removing the old security software and rebooting usually returns Defender to active mode.

Why aren’t my Defender detections or alerts showing up?

If detections are delayed or missing, the Defender sensor may be unable to upload telemetry to Microsoft’s cloud. This can happen when a proxy or SSL inspection tool interferes with encrypted traffic, or when cloud-delivered protection has been disabled by policy. Restoring direct HTTPS access to the required Defender domains generally resolves the issue.

How does Intune affect Defender for Endpoint?

When Defender is managed through Intune, onboarding and configuration are enforced through compliance and security baselines. Conflicting policies, such as legacy GPOs or hybrid configurations, can disable Defender features or cause inconsistent reporting. Ensuring Intune is your single source of truth for Defender policy management avoids these conflicts.

How do I verify that the Defender sensor is working correctly?

You can confirm the Defender sensor’s health by checking that the Microsoft Defender for Endpoint Service (SENSE) is running, the device’s “Last seen” time in the portal is current, and new alerts or telemetry appear in the device timeline. If any of these indicators are missing, investigate network connectivity or service startup issues.

When should I re-onboard a device to Defender for Endpoint?

If the sensor has stopped reporting data for an extended period, logs show repeated onboarding errors, or the device consistently fails to appear in the portal, re-onboarding is often faster than continued troubleshooting. Always use a current onboarding package from the Microsoft 365 Defender portal to ensure compatibility with the latest configuration.

Can Levacloud help with complex Defender troubleshooting?

Yes. Levacloud can help you review logs, verify sensor connectivity, identify policy conflicts, and validate your Defender configuration across Intune and Entra ID. Our team works directly with your environment to restore telemetry, improve visibility, and ensure your endpoints stay fully protected.