Microsoft Defender for Endpoint (MDE) is part of Microsoft Defender XDR and can be deployed via multiple configurations. During my experience with the product, I deployed/ reviewed and evaluated many Defender for Endpoint instances and configured new instances for many customers around the world; from small companies to larger enterprises. This blog will explain the common mistakes/ configuration mistakes around Defender for Endpoint deployments.

Background – Components of Defender for Endpoint

Microsoft Defender for Endpoint or MDE is the grouping of 3/4 main items. MDE is the logical grouping of the following items:

  • TVM (Threat Vulnerability Management)
  • EDR (Endpoint Detection and Response)
  • AV (Defender Antivirus)
  • ASR (Attack Surface Reduction)

Defender for Endpoint (MDE) in general is part of Defender XDR which correlates with other products and services in the Defender XDR ecosystem.

Microsoft Defender for Endpoint is a key component of the Microsoft 365 Defender architecture and part of the Microsoft 365 Defender platform. It shares data/ signals and architecture with the following products;

  • Microsoft Defender for Endpoint (MDE)
  • Microsoft Defender for Office 365 (MDO
  • Microsoft Defender for Cloud Apps (MDA)
  • Microsoft Defender for Identity (MDI)
  • Azure AD Identity Protection (AADIP)
  • Azure Defender (Preview)

Defender for Endpoint relies on multiple system components and integrations. In this blog, I will explain the common mistakes when using and deploying Defender for Endpoint.

Blog tip: MDE blog series (from what is Defender for Endpoint to configuration using Intune)

Common mistakes

When deploying Defender for Endpoint it all starts with preparation. It is important to investigate the current environment to avoid policy conflicts and design the solution perfectly for the used management methods/ systems/ network configuration in the environment. What are the common mistakes? I know the list can be long. (;

  • No structure in Defender for Endpoint
  • Service settings not correctly enabled
  • No plans for the onboarding mechanism
  • No “design” around policies/ deployment (results in policy conflicts)
  • Exclusions migrated from other AV solutions
  • Defender AV not configured correctly
  • Deploying it in production without understanding all the features
  • Audit mode is doing protection in MDE
  • Updates are not needed in passive mode
  • Not using the portal (waiting for incidents/alerts)
  • Not using Threat Analytics
  • Deploy to unpatched systems
  • Defender for Servers is fully automated including AV configuration
  • Misconfiguration of block at first sight (BAFS)
  • Emergency (real-time) updates with cloud protection.
  • And many more

No structure in Defender for Endpoint

The portal looks simple; there is an onboarding method/ device inventory and a set of features on top of the collected data. For larger enterprises with multiple environments/ geo-locations/ companies device groups are important for assigning more in-depth RBAC controls and for giving visibility in the reporting. When different IT teams are responsible for a smaller set of devices it is a must to configure a well-structured grouping structure.

It is heavily recommended to design a proper RBAC/ device group structure in Defender for Endpoint. Since a good structure is efficient in the use and reporting of features. Indicators can be scoped to device groups, and permissions can be limited to specific groups.

Since it is not only Defender for Endpoint, my recommendation is to start with the Unified RBAC experience and grant permissions across the Defender XDR product, since this helps more with defining the roles.

Permissions to everyone

Did you know there is a risk when onboarding devices (Domain Controllers/ Tier-0 servers) to Azure Arc/ Defender for Endpoint (MDE) – the risk can generate a huge impact when the access model is not configured correctly and allows potential a take-over of the machine. Let me explain why and how to design a good structure without risk.

The risk with Azure Arc

After enabling Azure Arc on Domain Controllers or other Tier-0 servers there is the option to do a server takeover via the Arc agent and policies/scripts. You can easily run PowerShell scripts (Custom script extension) for generating local accounts or changing critical settings on the domain controllers via the available extensions. When enrolled in MDE there is a detection capability of the EDR for malicious performed actions; all not for all performed actions.

If you were to deploy a domain controller/other Tier-0 assets and manage the servers using Azure Arc, then the Azure Arc admins and all other sufficient roles who can become an Azure ARC admin in that tenant are effectively a Domain Admin for that AD forest.

What can we do?

When designing Azure Arc it is needed to define a good RBAC/ subscription model and define only permissions for a specific set of people. Syncing Azure Arc to one subscription/ resource group? Each member with sufficient roles can manage the servers via Azure Policies/ scripts.

– Design a good RBAC/ Azure/ IAM structure
– Give limited access to Tier-0 and Domain Controllers
– Dedicated Resource Group for Tier-0 with limited access
– Check who has control over the Azure Arc resources

The risk with Defender for Endpoint

When using Defender for Endpoint without Azure Arc there is even a risk. For all MDE onboarded devices there is a risk of a complete take-over via Live Response. With the use of Live Response, it is possible to upload custom PowerShell scripts and run scripts on any onboarded machine when there are permissions. Check always the permissions and who can use live response.

For MDE consider a good device structure and limited access to the Tier-0/ Domain Controller assets to a specific group of people.

What can we do?

Tag devices and assign them to a specific device group in MDE. Limit access to the device group in MDE with only access from a specific group of people. With the use of permissions, it is possible to allow only a specific group to have access.

– Tag machines
– Create separate device groups for T0/ critical assets
– Grant limited permissions to the device group
– Review live response activity
– Disable Live Response unsigned script execution when possible in the Advanced features.

Did you know you can review all performed live response sessions? Go to M365D – Actions & Submissions – Action Center and open the History tab. Filter here for the action; Live Response command. 30 days of history is visible.

Service settings not correctly enabled

Customers started onboarding Defender for Endpoint without full protection enabled. Defender for Endpoint works based on a couple of features (Advanced Features) – without features enabled there is less protection or weakness in the product. Before starting with any onboarding of a machine, make sure the service settings are correctly enabled.

Not following new configurations/ features

Microsoft released rapidly new features around Defender for Endpoint. Defender for Endpoint is a story, important to follow the new developments. A good example is the ASR rule; “Block vulnerable drivers” This ASR rule is not available via the MECM policies or old Intune policies – it is always needed to follow the new developments and improve the Defender for Endpoint instance.

Another good example is when still using the Microsoft Monitoring Agent (MMA) for 2012R2/ 2016 systems. Microsoft released a new unified agent with more support and better protections.

Still, using the device configuration profile in Intune? Good idea to migrate them to the new Endpoint Security profiles – since Endpoint Security profiles are supported for MDE Configuration Management and upcoming features rely on this policy framework.

No plans for the onboarding mechanism

Onboarding is a different topic – currently, many solutions are available for onboarding Defender for Endpoint. Intune, GPO, PowerShell, Configuration Manager, Azure Arc, Defender for Servers. There are many options; my tip here is don’t focus only on Defender for Endpoint – check if more is possible. For example; Defender for Servers/ Azure Arc and Microsoft Intune support way more features for a better security landscape.

When using Azure Arc/ Defender for Cloud make sure to align the specific teams with a focus on Azure and start with a well-designed Azure landing zone. Another common mistake is related to the Azure Arc agent updates.

The Azure Connected Machine agent is updated regularly to address bug fixes/ stability enhancements and new functionalities. The agent update recommendations are visible via Azure Advisor. There is no automatic update based on the agent itself; it requires changes in the update process.

No “design” around policies/ deployment (results in policy conflicts)

GPO, Intune, Configuration Manager, Local Policy, PowerShell, and more. There are many tools available for configuring settings on Windows. Avoid conflicts and document the configured policies.

Before starting Defender for Endpoint projects, analyze the current configuration landscape. Common mistakes:

  • Defender AV disabled via GPO/ Local GPO
  • Microsoft Security GPO baseline conflicts with Intune
  • Configuration Manager Endpoint Protection site role conflicts with Intune

When using Intune and GPO; it can be useful for the deployment of a configuration for making the MDM policy a higher order. Without any configuration, GPO is always the highest configuration when there is a conflict. With the use of a custom policy, it is possible to define the MDM policy over GPO.

MDMWinsOverGP is available via the following OMA-URI setting:

OMA-URI./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP
Data typeInteger
Value1

The setting is also available via the settings catalog with the name: MDM Wins over GP

Exclusions migrated from other AV solutions

This one is quite often visible in environments. Organizations used other third-party AV solutions for many years, resulting in many legacy exclusions. Never migrate the entire list from any other AV in Defender AV. Each AV works differently – add only exclusion when there is a critical need (performance issues/ compatibility issues).

When using exclusion make sure it is documented (ticket number, reason, troubleshooting details). Defining exclusions lowers the protection offered by Microsoft Defender Antivirus, so use exclusions only in situations when there is no other solution.

Defender AV not configured correctly

Common misunderstanding; we have the Defender for Endpoint sensor onboarded and all is good and protected. The sensor is reporting “healthy/active” in Defender for Endpoint and Defender AV is running.

Defender AV/ NGP/ ASR is part of Defender for Endpoint and must be configured. Without Defender AV correctly configured, there is a lack of protection; Cloud Protection, ASR, Network Protection, and many more settings depend on the AV component. See the following blogs:

Tip: Use the security recommendation part of Defender for Endpoint

The first step in enrolling MDE is confirming that all configurations are compliant. Using Microsoft Defender Vulnerability Management it is possible to check the configured security controls for Antivirus, Application Guard, ASR, Bitlocker, Credential Guard, EDR, Exploit Guard, Firewall, SmartScreen, and the general onboarding state of MDE.

Use security recommendation data often and make it part of the IT process.

View via the portal: Go to recommendations and filter on the related component “Security controls” for viewing the compliance of all security controls policies.

For Attack Surface Reduction Rules – the recommendation insights are visible based on user impact information. User impact calculation is collected in the past 45 days and based on collected sensor telemetry.

Important: Recommendation is based on the enablement/disabled state of the feature. Specific settings (MAPS level, timeout) are not part of the result/ check. Always confirm the baseline and correct MAPS settings with in-depth testing of the machines (simulations/ validation) See:

Microsoft Defender for Endpoint series – Defender Vulnerability Management – Part5 

Microsoft Defender for Endpoint series – Validate Defender protection and additional troubleshooting – Part6 

Deploying it in production without understanding all the features

Essential for the IT teams to understand the features part of Defender for Endpoint. Based on real experiences by organizations there is often knowledge by the full IT team. Train users and make sure all features are explained (including service desk teams). Examples:

  • What is EDR in Block Mode
  • What is MAPS/ Cloud Protection
  • What is PUA protection
  • How to exclude feature xx in the portal or configuration
  • How works Tamper Protection
  • What is audit mode/ block mode

Most of the weakness starts with IT knowledge (Excluding complete folders; disabling AV features, offboard machines, not knowing the detection logic/ agent features) – make sure the team is informed and “knows” the products in-depth including all sub-features.

Recommended: View/ read all content part of the Defender for Endpoint Ninja show/ Ninja blog for in-depth knowledge.

Audit mode is doing protection in MDE

Common situation; we have some components (ASR/ Network Protection, PUA) in audit mode and are safe. Nope, audit mode is not doing any protection in MDE. It collects in some cases audit events, all there is no actual block.

Attack Surface Reduction (ASR) is always tricky and requires some fine-tuning. Don’t use audit mode for months; after configuring audit mode review the events and plan the enablement in block mode. Don’t use audit mode for years when not needed, since ASR is enabling additional protection controls.

In cases for ASR where the rule is not compatible with the environment; enable always audit mode instead of disabling the rule. With the use of audit mode, all data is collected and available via Advanced Hunting.

Updates are not needed in passive mode

When using Defender for Endpoint/ Defender AV in passive mode/ EDR in block mode it is still required to update the agent with the correct updates. Make sure the signature updates/ platform updates and Sense updates are deployed.

Not using the portal (waiting for incidents/alerts)

Defender for Endpoint is installed on all machines and up and running, there is no need to use the portal – only in cases when there is an alert. Not true; When Defender for Endpoint is correctly deployed there are many insights. After deploying it is important to use all data, start with hunting,/ exploring events, and use the data in Defender Vulnerability Management for patching all systems. More information later in this blog for the usage and insights

Not using Threat Analytics

The threat analytics part of Defender for Endpoint is important. Threat analytics is a feature with in-depth information from Microsoft security research and automated insights for possible impacted assets and available mitigations. In the Analyst report section, there is a detailed expert write-up available with in-depth information about the attack techniques and used KQL queries for hunting.

Deploy to unpatched systems

When starting with the deployment of Defender for Endpoint – make sure all systems are correctly updated to one of the latest updates. Based on experience there are many possible issues when systems are not on the correct level.

When the Servicing Stack Update (SSU) and Latest Cumulative Update (LCU) are correctly updated it will result in easier onboarding. Based on experience; Server 2016 gives a couple of issues when the SSU/ LCU is not updated to a specific version.

Defender for Servers

When using Defender for Servers there is still configuration needed for the Defender for Endpoint configuration. Defender for Servers starts only the onboarding via provisioning – it is still needed to configure additional components (AV, ASR, Firewall e.d). Ideally, use the new MDE security settings management for managing servers centralized via Intune.

Blog tip: Manage Defender for Endpoint for Windows, macOS, and Linux via Security settings management

Not updating the unified agent

For 2012R2 and 2016 with the unified agent installed, it is needed to update the sense component. The SENSE component requires to update KB5005292 for improvements related to the EDR sensor component.

When using WSUS or Microsoft Endpoint Configuration Manager it is important to include the updates part of the “Microsoft Defender for Endpoint” category.

Misconfiguration of block at first sight (BAFS)

Block at first sight (BAFS) is a threat protection feature of the Defender AV/ NGP component and detects new malware and blocks it within seconds. BAFS relies on a couple of configurations.

  • Cloud protection
  • Sample submissions (Send all samples automatically/ send safe samples automatically)
  • Cloud extended timeout period (recommended to use 50)

The combination of the above three settings enables block at first sight (BAFS). Block at first sight detects new malware and blocks it within some seconds. To get BAFS enabled it is needed to configure the above configuration. When all items are configured Block at first sight is correctly enabled.

Emergency updates

Microsoft Defender Antivirus uses cloud-delivered protection/ MAPS) to periodically download dynamic security intelligence updates to provide more protection. These dynamic updates are pushed automatically. Microsoft can push emergency updates via MAPS. Make sure that cloud-delivered protection is correctly enabled.

Knowing the unknown with device discovery

Ideally, there is a CMDB where all assets are available and correctly registered. In almost all environments, there are “unknown” devices. New onboarded machines outside the process/ test machines or playgrounds are often. For Defender for Endpoint and the threat landscape, it is critical to make sure all devices are covered by Defender for Endpoint.

With the use of Defender for Endpoint Device Discovery it is possible to discover the unmanaged part of the network. Microsoft Defender for Endpoint provides a device discovery capability based on onboarded endpoints to collect, probe, and scan the network to discover unmanaged devices.

The logic detects corporate networks and excludes private networks automatically. It is possible to manually exclude networks or devices from scanning.

Currently, it supports:

  • Endpoints
  • Network devices (Routers/ switches)
  • IoT devices (printers, cameras, scanners)

Defender for Endpoint supports two configurations of discovery (Basic discovery and Standard discovery).

Standard discovery is recommended. This method is based on smart active probing to discover additional information. Standard discovers minimal information using the SenseNDR.exe.

All devices are visible in the device inventory – filter for can be onboarded/Unsupported/Insufficient info state for MDE-related devices.

Use KQL for getting all machines part of the discovery

DeviceInfo
| summarize arg_max(Timestamp, *) by DeviceId  
| where isempty(MergedToDeviceId)
| where OnboardingStatus != "Onboarded"

Authenticated scans

Microsoft Defender for Endpoint device discovery can scan the network based on endpoints. With the use of the authenticated network device discovery more in-depth scanning is possible based on dedicated MDE devices and SNMP authentication for deeper analysis. Authenticated scans will be explained in a separate blog.

The device discovery feature is critical for the Automatic Attack Disruption feature.

With the leverage of Defender for Endpoint device discovery and containment, it is possible to detect unmanaged devices and block incoming/outgoing communication with the suspected device. With this approach the contain action is way more powerful, since attackers can use unmanaged devices as part of the network.

Attackers leverage mostly unmanaged devices for performing advanced attacks. With the use of device contain it is possible to contain the unmanaged devices, even when the machine is not onboarded to Defender.

For the contain and attack disruption functionality it is needed to configure the standard discovery mode. This discovery is active and based on common discovery protocols/ multicast with smart active probing.

Using the portal and all available data/ insights

Defender for Endpoint is not an “install, roll-out, and completed” product. The main work starts when all devices are onboarded and data is collected. I have seen many organizations rolling it out quickly and forgetting all the features part of Defender for Endpoint.

Maintaining Defender daily is critical and needed for getting most of the benefits out of the product. It starts with a couple of main parts:

  • New incidents/ Alerts
  • New Vulnerabilities
  • New threat reports
  • Responding to incidents
  • Patch vulnerabilities

Vulnerability management

With the use of the Defender for Endpoint sensor it collects vulnerabilities. There are many vulnerabilities, and managing them all is not possible. Prioritizing the work based on the impact score. MDE knows the number of CVEs and the exploit that is being actively exploited in the wild.

Tip: Create an update/vulnerability process; ideally create a team for reviewing the vulnerabilities daily/ weekly and update all software/ perform actions. Try to make the exposure score lower by patching the most critical recommendations.

Focus not only on software vulnerabilities, all software configurations are useful for making the endpoint baseline more strict. When there are device groups configured it is easy to give separate insights based on the device groups (Servers/ Linux/ Windows Endpoints e.d)

Review automated actions and portal activities

Automated investigation/ device quarantine and some other AV-related actions can be useful. In some cases, Defender for Endpoint detects and remediates automatically files. When alerts are automatically resolved it is not always visible. With the use of the action center, there are more insights available.

The action center is not only scoped on “new” actions; all historic actions are available via the History tab. Action center is available via Actions & submissions:

History contains all performed actions. This view contains for example the isolated device feature/ quarantine file action part of the automated investigation or AV quarantine items:

The quarantine file action contains all related information and allows the security team to restore the quarantine file actions for specific actions or all instances.

For quarantine file actions there is a “devices by” field. When the field is filled in with Automation the file is automatically quarantined. Microsoft Defender AV is scoped on items quarantined by the Defender AV process.

Live response auditing?

The action center contains auditing for the live response feature. When opening the investigation page for a live response command action it shows the complete historical view and performed commands:

The investigation page contains an image snapshot of the console and command log including all performed actions and commands. All data is visible; including the session started/ session ended and total duration.

Common mistake; No tamper protection

There are still organizations not enabling tamper protection for the following reasons;

  • We need to manage devices
  • Developers are allowed to add/ change settings
  • Performance issues

There is no reason for disabling tamper protection; each machine needs to be protected with tamper protection against malicious changes in the Defender AV/ EDR solution. Without Tamper Protection it is easy to bypass core protection features.

As already mentioned in the series; there are for Windows a couple of ways of enabling tamper protection:

  • Via Defender for Endpoint portal – advanced features
  • Via Microsoft Endpoint Manager Intune

Advanced features: Enabled via advanced features part of security.microsoft.com

Intune: Using Microsoft Defender Antivirus profile in the Endpoint Security – Antivirus blade

Recently Microsoft announced the new tamper protection feature for exclusions. If you manage exclusions exclusively through Intune with both tamper protection and DisableLocalAdminMerge enabled, there is protection for exclusions where exclusions are managed by Intune. Exclusions are managed when configuring:

  • DisableLocalAdminMerge
  • Tamper Protection is deployed using Intune
Tip: Deploy tamper protection using the Intune configuration and Defender for Endpoint service settings. Deploy both so exclusions are protected and there is always a fallback when the cloud protection service is not available. Tamper protection via security.microsoft.com requires cloud protection to be fully enabled.

Based on my opinion tamper protection must be always enabled. The new troubleshooting mode can be used during troubleshooting situations to disable the features for troubleshooting. Sometimes customers like to disable Microsoft Defender during troubleshooting and not configure tamper protection, which makes a security cap. The new troubleshooting mode is fixing this request, where teams have more flexibility. View the in-depth troubleshooting blog here.

Local admin

When using an endpoint with local admin permissions it is recommended to restrict the following registry location: ( to avoid policy changes) 

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Policy Manager

This registry location can be restricted with a custom policy in Intune/ GPO or other systems. For Intune use a custom OMA-URI profile or settings catalog and configure the following value:

OMA-URI./Device/Vendor/MSFT/Defender/Configuration/HideExclusionsFromLocalAdmins
Data typeInteger
Value1
OMA-URI./Device/Vendor/MSFT/Defender/Configuration/HideExclusionsFromLocalUsers
Data typeInteger
Value1

HideExclusionsFromLocalAdmins restricts the view. If the value is set to 1, it blocks all access to the policy location in the policy manager:

Common mistake; No updates deployed

Defender for Endpoint requires a couple of monthly/daily updates to get new features and updates. Important to make sure the updates are working correctly and are accepted.

When using WSUS/ Configuration Manager; try to move to more modern solutions – based on real experience all issues start with WSUS/ Configuration Manager and corrupt update packages. Issues with syncing the catalog, corrupt databases, and no maintenance. Try to move to a cloud-managed distribution (MicrosoftUpdate) for at least the signature updates.

Defender for Endpoint/ Defender AV needs to be updated with recent updates. The following updates are important. Don’t forget KB5005292 which is required for the 2012R2/ 2016 EDR sensor part of the unified agent.

UpdateKBDescription
Update for Defender antimalware platform (AmProductVersion)KB4052623It is critical to make sure Defender platform is updated with the latest version, for getting the latest technology and features
Security Intelligence updatesKB2267602Defender AV requires Security Intelligence Updates/ Signature updates
Update for EDR sensor (2012R2/ 2016)KB5005292This update includes updates and fixes to the EDR sensor that is used by MDE for 2012R2/ 2016

I still see many environments where the Update for EDR sensor (2012R2/ 2016) is not deployed in the environment. It is needed to deploy the update since SENSE requires new updates

Common mistakes; not changing installation files

When installing Defender via GPO or another management system the source files are used. A good example is when installing Defender on 2012R2/ 2016 machines. It requires MSI files/ updates and onboarding files.

When deploying it is recommended to update the source files a couple of times a year. Microsoft improves the installers and onboarding packages – when updating the source files the known bugs are solved and the monthly Defender platform version and sense version is already included in the MSI.

Common mistake; Exclusions

Before starting with deploying Defender for Endpoint make sure the preventions as already explained are correctly configured:

  • DisableLocalAdminMerge
  • Tamper Protection
  • HideExclusionsFromLocalAdmins (when users are local admin)

In Intune, DisableLocalAdminmerge can be configured using the setting “Disable Local Admin Merge” Configure the setting to the following: (I know it is a bit confusing with the name convention in Intune)

When configured on “Disable Local Admin Merge” the local exclusion list added via local Group Policy, PowerShell UI is not merged with the effective policy.

For exclusions, it is recommended to hide the exclusions, as already explained above. This is possible via the settings catalog in Intune or a custom OMA-URI setting:

OMA-URI./Device/Vendor/MSFT/Defender/Configuration/HideExclusionsFromLocalAdmins
Data typeInteger
Value1
OMA-URI./Device/Vendor/MSFT/Defender/Configuration/HideExclusionsFromLocalUsers
Data typeInteger
Value1

Each vendor shares most of the time a large list of exclusions. A good example of Veaam advice; excluding the complete C:\Program Files\Veeam\ folder. Good job!! All it is great for running malware directly from a folder (-;

Even when the vendor shares a large list of exclusions review each exclusion, based on experience most of the applications run well without the vendor-recommended exclusions. When needed use procmon/ performance analyzer or more in-depth toolings for checking specific paths. More information:

Add only exclusion when there is a critical need (performance issues/ compatibility issues). And never, never migrate old exclusions!!

When using exclusion make sure it is documented (ticket number, reason, troubleshooting details). Defining exclusions lowers the protection offered by Microsoft Defender Antivirus.

Explanation of the exclusions is not part of the MDE series with a reason. Fabian Bader published an in-depth exclusions guide with almost all related information. Must read!!!

Fabian Bader/ Cloudbrothers.info: The Hitchhiker’s Guide to Microsoft Defender for Endpoint exclusions

Common mistake; Only network protection configured without SmartScreen

Network protection is critical in combination with Defender for Endpoint network indicators and web content filtering. For blocking indicators the Network protection feature must be enabled in block mode. Network protection is an attack surface reduction capability, and prevents access to dangerous domains or custom-blocked indicators.

The network protection component of Defender for Endpoint identifies and blocks connections to C2 infrastructures used in ransomware attacks. Blocking C2 attacks makes Network Protection more important.

Enable SmartScreen for Edge and include the SmartScreen potentially unwanted app feature (removes the yellow warning of Defender). Don’t forget to enable SmartScreen for all components (Windows Explorer)

For Microsoft Edge browsers Defender SmartScreen must be enabled.

Always test and confirm the protection state – this validates that the actual configuration is working correctly on the endpoints.

Common mistake; disabling auto-remediation

Currently, 5 different levels of remediation are available. Full automation is recommended and has been configured by default since 2021 for new tenants. I still see environments where the automated investigation is completely disabled for all machines.

When AIR is disabled (No automated response) there is no automated investigation. Full automation has proven to be reliable, efficient, and safe, and is recommended for all customers. Full automation frees up your critical security resources so they can focus more on your strategic initiatives.

When full automated response is not possible – configure at least one of the semi-levels. Avoid disabling AIR completely, since this lacks in the protection and attack disruption capabilities.

Attack Disruption

Attack Disruption relies on the auto-remediation feature for a couple of flows. It is recommended to use full automated response w hen possible since this improves the 24/7 protection posture.

More information: Automatic attack disruption in Microsoft Defender XDR and containing users during Human-operated Attacks

Common mistake; Not using Advanced Hunting/ Custom detections

Advanced Hunting is powerful. Out of the box Defender for Endpoint is not alerting for all activities. Advanced Hunting is powerful enough to create additional detection and close the detection caps. Since a lot of data can be found in the Advanced Hunting dataset.

With custom detections, you can proactively monitor for and respond to various events and system states, including suspected breach activity and misconfigured endpoints, and automate response actions. With the availability of data, there are many use cases to use the customs detection capabilities.