This chapter covers Microsoft Defender for Endpoint (MDE) integration within the Azure ecosystem, a critical topic for the AZ-500 exam's Security Operations domain (Objective 4.1). You will learn how MDE integrates with Microsoft Defender for Cloud and Microsoft Sentinel, enabling unified endpoint detection and response (EDR) across hybrid and multi-cloud environments. Expect approximately 5-10% of exam questions to touch on MDE integration, focusing on onboarding, data flow, and configuration steps.
Jump to a section
Imagine a large corporate building with its own internal security team (the local security guards) and a central security command center that monitors all buildings in the city. Each building has its own security system that can detect suspicious activity, like an unauthorized person entering a restricted area. When the local system detects something, it sends a detailed alert to the central command center, which then correlates alerts from multiple buildings. The central command center can also send instructions back to the local system, such as 'lock down the east wing' or 'let this known visitor through.' This is exactly how Microsoft Defender for Endpoint (MDE) integrates with Microsoft Defender for Cloud (MDC) and Microsoft Sentinel. The 'local security system' is MDE installed on endpoints (servers, workstations) that collects telemetry and detects threats. The 'central command center' is MDC or Sentinel, which receives alerts and can respond. The integration requires the endpoint to be 'onboarded' to MDE (installed and connected), then MDE must be connected to MDC or Sentinel via a connector. Once connected, alerts flow from MDE to the central platform, where they can be investigated and remediated. The analogy breaks down if you think of the local system as independent—it actually works best when fully integrated with the central command, just as MDE integration provides unified visibility and response across hybrid environments.
What is Microsoft Defender for Endpoint Integration?
Microsoft Defender for Endpoint (MDE) is an enterprise-grade endpoint security platform that provides preventative protection, post-breach detection, automated investigation, and response. Integration refers to connecting MDE with other Microsoft security services—primarily Microsoft Defender for Cloud (MDC) and Microsoft Sentinel—to centralize alerts, enable cross-service correlation, and orchestrate automated responses. The AZ-500 exam specifically tests your ability to configure and manage these integrations to ensure seamless security operations.
Why Integration Exists
Organizations often have endpoints across on-premises, Azure, and other clouds. MDE alone provides rich telemetry but lacks a unified dashboard for cloud workloads and SIEM capabilities. By integrating with MDC, you get a single pane of glass for cloud security posture management (CSPM) and cloud workload protection (CWP). Integration with Sentinel adds SIEM and SOAR capabilities, allowing correlation of MDE alerts with other data sources (e.g., firewall logs, Azure AD sign-ins). The exam expects you to understand that integration reduces alert fatigue and improves mean time to respond (MTTR).
How It Works Internally
#### Data Flow: Endpoint to MDE to MDC/Sentinel 1. Onboarding: Each endpoint must run the MDE agent (Windows 10/11, Windows Server, Linux). The agent collects telemetry (process creation, network connections, file modifications) and sends it to the MDE cloud service. 2. Alert Generation: MDE's behavioral analysis and machine learning models detect suspicious activity and generate alerts. Each alert has a severity level (Informational, Low, Medium, High) and contains structured data in JSON format. 3. Integration Connector: To forward alerts to MDC or Sentinel, you must enable a connector. For MDC, this is done via the 'Defender for Endpoint' connector in the MDC environment (formerly Azure Security Center). For Sentinel, you use the 'Microsoft Defender for Endpoint' data connector. 4. Data Ingestion: Once connected, alerts are streamed via Azure Monitor's ingestion pipeline. The connector uses the Microsoft Graph Security API to pull alerts from MDE and push them into the Log Analytics workspace associated with MDC or Sentinel. 5. Correlation and Response: In MDC, MDE alerts appear under 'Security alerts'. In Sentinel, they populate the 'SecurityEvents' table (or a custom table). You can then create analytic rules to correlate MDE alerts with other signals, and automation rules to trigger playbooks (e.g., isolate a machine via MDE's response actions).
#### Key Components, Values, and Defaults
- MDE Agent: On Windows, the agent is included in Windows 10/11 build 1607+ and Windows Server 2016+ (requires servicing stack update). On Linux, you install the 'mdatp' package. The agent communicates via HTTPS to endpoints like *.endpoint.microsoft.com.
- Onboarding Methods: For servers, you can onboard via Group Policy, Microsoft Endpoint Configuration Manager, or a script (downloaded from the MDE portal). For Azure VMs, you can onboard automatically via MDC's 'Enable Microsoft Defender for Endpoint' setting.
- Connector Defaults: In MDC, enabling the 'Defender for Endpoint' connector is a one-click operation (no additional cost if you have MDE licenses). In Sentinel, the connector requires you to select a Log Analytics workspace and may incur ingestion costs.
- Alert Retention: MDE alerts are retained for 180 days in the MDE portal. When forwarded to Sentinel, retention follows the Log Analytics workspace settings (default 30-730 days).
- Response Actions: MDE supports 'Isolate machine', 'Run antivirus scan', 'Initiate investigation', and 'Collect investigation package'. These can be triggered from MDC or Sentinel via the API.
#### Configuration Steps (Exam-Relevant) 1. Onboard Endpoints to MDE:
- Download the onboarding package from the MDE portal (Settings > Onboarding).
- For Azure VMs, use the 'Enable' button in MDC under 'Environment settings' > 'Microsoft Defender for Cloud' > 'Defender plans' > 'Defender for Servers' > 'Microsoft Defender for Endpoint'.
- Verify onboarding with Get-MpComputerStatus in PowerShell (Windows) or mdatp health (Linux).
2. Connect MDE to MDC:
- In Azure portal, go to Microsoft Defender for Cloud > Environment settings > Select subscription > Defender plans > Turn on 'Defender for Servers' (Plan 1 or Plan 2). - Under 'Integrations', ensure 'Allow Microsoft Defender for Endpoint to access my data' is enabled. - Validate: In MDC, under 'Security alerts', you should see alerts tagged with 'MITRE ATT&CK' tactics. 3. Connect MDE to Sentinel:
In Azure portal, go to Microsoft Sentinel > Data connectors > 'Microsoft Defender for Endpoint'.
Click 'Open connector page' > 'Connect'.
Configure which alerts to ingest (e.g., all alerts, or by severity).
Validate: Run a query in Sentinel's Logs: SecurityEvent | take 10 (if using legacy connector) or MicrosoftDefenderEndpointAlerts | take 10 (if using new connector).
#### Verification Commands - Check MDE agent status on Windows:
Get-MpComputerStatus | select AMRunningMode, AMProductVersion, OnboardingState Expected: AMRunningMode = 'Normal', OnboardingState = 'Onboarded'.
- Check MDE agent on Linux:
mdatp health --field real_time_protection_enabled Expected: true.
- Check connector health in Sentinel:
MicrosoftDefenderEndpointAlerts
| where TimeGenerated > ago(1h)
| summarize count() by AlertSeverityIf no results, the connector may be misconfigured.
#### Interaction with Related Technologies - Microsoft Defender for Cloud: MDE integration is a prerequisite for MDC's 'Defender for Servers' plan. Without integration, MDC can only assess vulnerabilities (via Qualys or Microsoft Defender Vulnerability Management) but cannot perform EDR. The exam often tests that MDE must be enabled before you can use adaptive application controls or just-in-time VM access. - Microsoft Sentinel: MDE alerts are a common data source. Sentinel's fusion engine can correlate MDE alerts with Azure AD sign-in logs to detect advanced attacks. The exam may ask about the 'Microsoft 365 Defender' connector, which ingests alerts from all Microsoft 365 Defender products (including MDE) into Sentinel. - Azure Policy: You can use Azure Policy to automatically deploy MDE extensions to Azure VMs. The built-in policy 'Deploy Microsoft Defender for Endpoint agent on Windows VMs' is exam-relevant.
#### Common Pitfalls and Exam Traps - Trap 1: Assuming MDE integration is automatic when you enable MDC. Reality: You must explicitly enable the connector in MDC settings. - Trap 2: Confusing MDE with Microsoft Defender Antivirus (MDAV). MDE includes MDAV but adds EDR capabilities. The exam may ask which component provides behavioral detection. - Trap 3: Thinking MDE can be integrated with third-party SIEMs. While MDE supports API-based export, the exam focuses on native integration with Microsoft tools. - Trap 4: Overlooking license requirements. MDE requires a separate license (e.g., Microsoft 365 E5, Windows E5, or standalone). MDC's Defender for Servers Plan 2 includes MDE license for Azure VMs, but on-premises servers require separate MDE licensing.
#### Specific Numbers and Values - MDE agent heartbeat interval: 5 minutes (if no heartbeat for 7 days, the device is considered inactive). - Default retention for MDE alerts in Microsoft 365 Defender portal: 180 days. - Maximum number of devices that can be onboarded to a single MDE tenant: 1 million (practical limits may apply). - Supported OS for MDE on Azure: Windows Server 2008 R2 SP1+ (requires Microsoft Monitoring Agent), Windows Server 2012 R2+, Linux (Ubuntu 16.04+, RHEL 7+, etc.).
Enable MDE on Azure VMs
In the Azure portal, navigate to Microsoft Defender for Cloud > Environment settings > Select your subscription > Defender plans. Turn on 'Defender for Servers' (Plan 2 for full EDR). Then, under 'Settings & monitoring', ensure 'Microsoft Defender for Endpoint' is set to 'On'. This triggers automatic extension installation on all existing and new VMs. The extension (MDE.Windows or MDE.Linux) is deployed via Azure VM agent. You can verify installation by checking the VM's extensions blade; the status should show 'Provisioning succeeded'. If the extension fails, common causes include missing outbound HTTPS connectivity to *.endpoint.microsoft.com or insufficient permissions.
Connect MDE to Defender for Cloud
In MDC, go to 'Integrations' under 'Environment settings'. Find 'Microsoft Defender for Endpoint' and click 'Enable'. This establishes a data pipeline using the Microsoft Graph Security API. Once enabled, MDC will start receiving MDE alerts. You can confirm by viewing 'Security alerts' in MDC; alerts will have a 'Product name' of 'Microsoft Defender for Endpoint'. Note that this integration is one-way: alerts flow from MDE to MDC, but response actions (e.g., isolate VM) can be initiated from MDC, which sends commands back through the same API.
Connect MDE to Microsoft Sentinel
In the Azure portal, open Microsoft Sentinel and select your workspace. Under 'Data connectors', search for 'Microsoft Defender for Endpoint' and open the connector page. Click 'Open connector page' and then 'Connect'. You can optionally select which alert severities to ingest (e.g., only High and Medium). After connection, alerts appear in the 'MicrosoftDefenderEndpointAlerts' table. To validate, run the query: `MicrosoftDefenderEndpointAlerts | where TimeGenerated > ago(1h)`. If no results, check that the connector status shows 'Connected' and that MDE is generating alerts.
Configure automated response playbooks
In Sentinel, you can create automation rules that trigger on MDE alert creation. For example, create a rule that runs a playbook to isolate a compromised machine. The playbook uses the MDE connector action 'Isolate machine' (requires API permissions). You must grant the playbook managed identity access to the Microsoft Graph API with 'Machine.Isolate' permission. In the exam, be prepared to identify that playbooks are Azure Logic Apps, and that you need to assign appropriate roles (e.g., 'Security Administrator') to the managed identity.
Monitor and verify integration health
Regularly check the health of the integration. In MDC, under 'Integrations', you can see the status of the MDE connector. In Sentinel, the data connector page shows 'Last data received' timestamp. If data stops flowing, check the Log Analytics workspace for ingestion errors using: `union withsource=sourceTable * | where TimeGenerated > ago(24h) | where _ResourceId contains 'MicrosoftDefenderForEndpoints'`. Common issues include license expiration, network connectivity problems, or changes to service principal permissions. The exam may ask about troubleshooting steps, such as verifying the MDE agent is running and that the connector is enabled.
Enterprise Scenario 1: Hybrid Server Protection
A multinational corporation runs 5,000 Windows servers across on-premises datacenters and Azure. They need unified endpoint detection and response. They deploy MDE using Configuration Manager for on-premises servers and the Azure extension for VMs. They integrate MDE with Defender for Cloud to get a single dashboard for security alerts across all workloads. The integration allows the SOC team to see alerts from both environments in one place. A common issue: on-premises servers must have outbound internet access to the MDE cloud service. If a server is behind a strict firewall, they must allow URLs like *.endpoint.microsoft.com and *.events.data.microsoft.com. Performance considerations: MDE agent CPU usage averages 5-10% on modern hardware, but during scans it can spike to 30%. They schedule scans during off-peak hours.
Scenario 2: SIEM Integration with Sentinel
A financial services company uses Microsoft Sentinel as its primary SIEM. They have 10,000 endpoints (Windows and Linux) running MDE. They integrate MDE with Sentinel to correlate endpoint alerts with Azure AD sign-in logs and firewall logs. This enables detection of lateral movement and credential theft. They configure automation rules to automatically isolate a machine when a 'Ransomware' alert fires. A misconfiguration they encountered: the connector was set to ingest only 'High' severity alerts, but a critical attack used 'Medium' severity alerts that were missed. They changed the connector to ingest all severities and then used Sentinel analytics rules to filter noise. Scale considerations: each endpoint generates about 1-2 MB of data per day; with 10,000 endpoints, that's 10-20 GB/day. They set a daily ingestion cap in Log Analytics to control costs.
Scenario 3: Multi-Cloud Endpoint Detection
A tech startup uses Azure for some VMs and AWS for others. They deploy MDE on all servers (Azure VMs via extension, AWS EC2 via manual installation). To get a unified view, they connect MDE to Defender for Cloud, which also supports AWS via Azure Arc. They enable the 'Defender for Servers' plan on the AWS connector. This allows them to see MDE alerts from both clouds in one MDC dashboard. A common pitfall: MDE licenses are tied to the Azure tenant, so they must ensure all AWS servers are properly licensed. They use Azure Arc to project on-premises and AWS servers as Azure resources, which simplifies policy enforcement and integration.
What AZ-500 Tests on MDE Integration
The exam objectives under '4.1 Configure and manage security monitoring solutions' include: - 'Configure Microsoft Defender for Endpoint integration with Microsoft Defender for Cloud' - 'Configure Microsoft Defender for Endpoint integration with Microsoft Sentinel' - 'Manage endpoint detection and response' Specific objective codes: AZ-500: 4.1.1, 4.1.2. Expect 2-3 questions on integration steps, data flow, and licensing.
Common Wrong Answers and Why
'MDE is automatically integrated when you enable Defender for Cloud.' This is false because you must explicitly enable the connector in MDC settings. Candidates choose this because they assume enabling a service includes all sub-services.
'You can use MDE without a license if you have Defender for Cloud.' Wrong. MDE requires a separate license (included in Defender for Servers Plan 2 for Azure VMs, but on-premises need MDE license). Candidates confuse 'Defender for Cloud' with 'Defender for Endpoint' licensing.
'MDE integration with Sentinel uses the same connector as MDC.' Wrong. MDC uses a built-in integration; Sentinel uses a data connector. Candidates think both use the same mechanism because both are Microsoft security products.
'MDE alerts are stored in the Log Analytics workspace indefinitely.' Wrong. MDE alerts in the MDE portal are retained for 180 days; in Sentinel, retention follows workspace settings (default 30-730 days). Candidates assume infinite retention.
Specific Numbers and Terms on the Exam
Default MDE alert retention: 180 days.
Onboarding script location: MDE portal > Settings > Onboarding.
Connector name in Sentinel: 'Microsoft Defender for Endpoint'.
Required permission for response actions: 'Machine.Isolate' in Microsoft Graph.
Heartbeat interval: 5 minutes.
Edge Cases and Exceptions
Non-Azure servers: For on-premises servers, you must onboard via a script or Configuration Manager; the Azure extension only works for Azure VMs.
Linux support: MDE on Linux supports specific distributions (Ubuntu 16.04+, RHEL 7+, etc.). The exam may test that you cannot use MDE on older unsupported versions.
Multiple tenants: If you have multiple Azure tenants, each tenant must have its own MDE instance. Integration with MDC/Sentinel is per-tenant.
Government clouds: MDE is available in GCC, GCC High, and DoD, but connector URLs differ. The exam may ask about endpoint URLs for sovereign clouds.
How to Eliminate Wrong Answers
If an answer says 'no additional configuration needed', it's likely wrong because integration always requires explicit steps.
If an answer mentions 'Microsoft Monitoring Agent' for MDE onboarding on Windows Server 2008 R2, it's correct (older OS requires MMA).
If an answer suggests using 'Azure Security Center' (old name), it's outdated; the current name is 'Microsoft Defender for Cloud'.
If an answer discusses 'automatically deploying MDE via Azure Policy', it's correct because built-in policies exist.
MDE integration with Defender for Cloud requires explicitly enabling the connector under Environment settings > Integrations.
MDE integration with Microsoft Sentinel uses the 'Microsoft Defender for Endpoint' data connector.
MDE alerts are retained for 180 days in the MDE portal; retention in Sentinel follows Log Analytics workspace settings.
MDE requires a license: included in Defender for Servers Plan 2 for Azure VMs, but on-premises servers need a separate MDE license.
Onboarding Azure VMs to MDE can be automated via the Defender for Cloud 'Enable' button or Azure Policy.
Response actions (e.g., isolate machine) require the 'Machine.Isolate' permission in Microsoft Graph.
The MDE agent sends a heartbeat every 5 minutes; if no heartbeat for 7 days, the device is marked inactive.
These come up on the exam all the time. Here's how to tell them apart.
MDE Integration with Defender for Cloud
One-click enable in MDC integrations settings
Alerts appear in MDC security alerts dashboard
No additional cost (included with Defender for Servers Plan 2)
Supports automated response via MDC's workflow automation
Best for unified cloud workload protection (CSPM + CWP)
MDE Integration with Microsoft Sentinel
Requires data connector configuration in Sentinel
Alerts appear in Sentinel's 'MicrosoftDefenderEndpointAlerts' table
Incurring Log Analytics ingestion costs
Supports advanced correlation with other data sources
Best for SIEM/SOAR capabilities and cross-source correlation
Mistake
MDE integration with Defender for Cloud is automatic once Defender for Cloud is enabled.
Correct
You must manually enable the 'Microsoft Defender for Endpoint' connector in Defender for Cloud's integrations settings. Without this step, no MDE alerts appear in Defender for Cloud.
Mistake
MDE can be used without a license if you have Microsoft Defender for Cloud.
Correct
MDE requires a separate license (e.g., Microsoft 365 E5, Windows E5, or standalone MDE). Defender for Cloud's Defender for Servers Plan 2 includes MDE license for Azure VMs only, not for on-premises servers.
Mistake
MDE integration with Sentinel uses the same connector as Defender for Cloud.
Correct
Defender for Cloud has a built-in integration toggle, while Sentinel uses a specific data connector named 'Microsoft Defender for Endpoint'. Both use the Microsoft Graph API but are configured separately.
Mistake
MDE alerts are stored indefinitely in the Log Analytics workspace.
Correct
MDE alerts in the MDE portal are retained for 180 days. When forwarded to Sentinel, retention follows the Log Analytics workspace settings (default 30-730 days, configurable).
Mistake
You can deploy MDE to Azure VMs without any agent or extension.
Correct
MDE requires an agent (MDE.Windows or MDE.Linux extension for Azure VMs). For Windows Server 2008 R2, the Microsoft Monitoring Agent is needed. Without the agent, no telemetry is collected.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
In the Azure portal, go to Microsoft Defender for Cloud > Environment settings > Select your subscription > Defender plans. Turn on 'Defender for Servers' (Plan 2 for full EDR). Then, under 'Settings & monitoring', ensure 'Microsoft Defender for Endpoint' is set to 'On'. This enables the integration and automatically deploys the MDE extension to Azure VMs. For on-premises servers, you must onboard them separately via a script or Configuration Manager.
Microsoft Defender Antivirus (MDAV) is the built-in antimalware solution in Windows. MDE includes MDAV but adds endpoint detection and response (EDR) capabilities, such as behavioral analysis, automated investigation, and response actions. MDE also provides a richer set of alerts and integrates with Microsoft 365 Defender. The exam tests that MDE is a superset of MDAV.
Yes, MDE supports exporting alerts via the Microsoft Graph Security API, which can be consumed by third-party SIEMs. However, the AZ-500 exam focuses on native integration with Microsoft Defender for Cloud and Microsoft Sentinel. For third-party SIEMs, you would need to build a custom connector using the API.
Disabling the connector stops the flow of MDE alerts into Defender for Cloud. However, MDE continues to run on endpoints and generate alerts in the MDE portal. The connector can be re-enabled at any time. Note that disabling the connector does not uninstall the MDE agent from VMs.
In Sentinel, go to Data connectors and check that the 'Microsoft Defender for Endpoint' connector shows 'Connected'. Then run a sample query: `MicrosoftDefenderEndpointAlerts | where TimeGenerated > ago(1h)`. If results appear, integration is working. If no results, check that MDE is generating alerts and that the connector is not filtered by severity.
If you have Defender for Servers Plan 2 enabled, the MDE license is included for Azure VMs. For on-premises servers or VMs in other clouds, you need a separate MDE license (e.g., Microsoft 365 E5, Windows E5, or standalone MDE). The exam may test that Plan 1 does not include MDE.
In the Microsoft 365 Defender portal (MDE console), alerts are retained for 180 days. When forwarded to Sentinel, retention follows the Log Analytics workspace retention policy (default 30-730 days, configurable). The exam may ask about the 180-day default.
You've just covered Microsoft Defender for Endpoint Integration — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?