With just 2 remaining months in 2025, it is a good idea to check the Microsoft Defender environment and check of new features are correctly configured. In recent months, Microsoft has released numerous new features and security solutions to protect against increasingly advanced cyberattacks. What I currently see is quite common: environments are often configured some time ago and not updated with the latest features and settings, resulting in less protection and reduced visibility. In this blog the Get your Microsoft Defender optimized and configured” cheat sheet. This blog includes a couple of items that, in my opinion, should be fixed before 2026 or at least early 2026.

Why no set-and-forget strategy?

In recent years, Microsoft has significantly enhanced Defender’s capabilities and attack posture. With Defender evolving rapidly, “set and forget” is no longer an option. Stay up to date to get the latest innovations and protections. Years ago, it was just deploying an AV agent and updating the tool – now it is needed to check all innovations and make security a bit better each day. This applies to Entra/Defender and all products in the Microsoft suite.

Microsoft continuously adds features, but many require manual configuration. Here’s my updated cheat sheet with the settings I still see overlooked daily:

To see all the new features and innovations released by Microsoft Security: Microsoft Defender XDR Blog | Microsoft Community Hub

Defender items

Since more items are moved between the individual products, it is important to check that Defender is correctly configured. The below is top of mind to configure and check;

  • Enable M365 Unified Audit Log with 12+ months retention for all event types
  • Ensure Attack Disruption is fully configured and test the flow with sample attacks
  • Define and tag critical assets in Exposure Management
  • Explore Attack Paths and Choke Points in Exposure Management
  • Evaluate Exposure Management and make it part of the IT/ Security organization
  • Review of the audit retention is enough (when data is needed for incidents) – the default 30 days is not enough
  • Migrate to Unified RBAC
  • Review and document RBAC configurations, including available actions per role

Enable M365 Unified Audit Log

I know this point can be discussed heavily. From my point of view, the audit log should include at least 12 months of retention for all event types. Make sure the M365 Unified Audit Log is enabled for all event types. It is essential to track admin activities and have logging available. Good examples: people adding/deleting indicators should be logged, and another example is when RBAC roles and advanced features are getting changes.

More information: Turn auditing on or off | Microsoft Learn & Audit log activities | Microsoft Learn

Action point: Check that the M365 Unified Audit Log is enabled with at least 12 months of retention for all event types.

Attack Disruption

Personally, I would say this is the most important point of the list. In the past years, I have seen many attacks prevented/ limited with the use of Attack Disruption, and still seeing environments where the configuration is not correctly implemented, configuration mistakes, and not onboarded MDI sensors.

Common mistakes

  • Not all products are deployed (MDI is commonly forgotten)
  • Device discovery is not configured on standard discovery (this is needed for the contain device action)
  • Automation settings for devices not on “Full – remediate threats automatically”
  • Defender for Identity auditing is not correctly configured, and auditing is not configured
  • Defender for Cloud Apps connectors are not enabled
  • App Governance is not enabled and configured
  • Mailbox auditing logging is not enabled

The wider the deployment, the greater the protection coverage is. It is advised to use all of the relevant products, including Defender for Identity and Defender for Cloud Apps.

Action point: Check that Attack Disruption is fully enabled and configured in the environment.

Device groups

Review the configured automation level for your device group policies, whether automated investigations run, and whether remediation actions are taken automatically or only upon approval for your devices, depending on certain settings. It is recommended to use the level “Full – remediate threats automatically” for most of the devices. For exclusions, try to avoid the “No automated response” level. When configuring the no automated response, the automated containment will not run.

Action account

Defender for Identity allows you to take remediation actions targeting on-premises Active Directory accounts if an identity is compromised. When on-premises Active Directory is still used, it is needed to configure the action accounts. By default, Microsoft uses the LocalSystem account of the domain controller and performs the actions automatically. In some environments, I see that a manual action account is used without the correct permissions.

Personal advice is to use the “sensor local system account”

Tip: When using manual action accounts, confirm that the account is correctly configured and granted to all OUs/ including admin users, to automatically disable admin accounts when the account is part of the Attack Disruption scope. Another good tip is to validate and test the action account. This can be tested to disable the user account via the Defender portal of Defender.

App Connectors

Since Attack Disruptions uses events ingested in Defender, it is needed to connect Microsoft 365 with Defender for Cloud Apps. This is commonly not configured. It is advised to connect to at least Microsoft 365 and Azure in the App Connectors. This will result in more data and visibility in Defender.

More information: Configure automatic attack disruption in Microsoft Defender XDR | Microsoft

Blogs: Configure automatic Attack Disruption in Microsoft Defender XDR & Automatic attack disruption in Microsoft Defender XDR and containing users during Human-operated Attacks

Re-enablement of accounts

Some HR, MDM, or identity sync tools (like on-prem AD or IAM automation scripts) re-enable disabled accounts based on employee state. Ensure “disable” signals from Defender remain authoritative and will not be changed by any other tool.

When this happens, Defender disables the account, and the HR or sync tool re-enables it automatically. This gives a lack of overall protection.

I’ve seen this in real environments; one client’s HR sync re-enabled a compromised account within 2 minutes. The attacker was back in before anyone noticed.

Exposure Management

Critical assets help the team to prioritize efforts to improve the security posture. It is also a key item as part of the attack paths calculation. It is important to classify the manual assets and define them as critical assets. In the future, Microsoft will do more with the critical calculation of the asset, which makes it more important to align a strategy to maintain and tag critical assets as part of the organization.

Asset criticality is a measure of the importance of an asset to your organization’s operations and security posture. It reflects a combination of its cyber-role, production context, and system or subsystem.

Microsoft used the following levels:

  • Very High – Very high criticality assets are essential to the survival and continuity of your business. Their compromise could result in catastrophic consequences.
  • High – High criticality assets are crucial to your organization’s core operations. Their compromise could lead to significant disruptions.
  • Medium – Medium criticality assets have a moderate impact and might affect certain functions or processes.
  • Low – Low criticality assets have minimal impact on your business operations and security if compromised.

The current list of critical assets can be reviewed via Defender -> Settings > Microsoft XDR > Rules > Critical asset management. Microsoft included a pre-list of classifications and the option to create custom classification rules for company-owned assets not detected in the predefined classifications.

More information: Review and classify critical assets in Microsoft Security Exposure Management – Microsoft Security Exposure Management | Microsoft Learn

Action point: Explore Exposure Management and define critical assets, and review existing choke points and data in exposure management to improve the exposure.

Unified RBAC

For years, many organizations have relied on the legacy RBAC models spread across individual Defender products (Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps, etc.). While that worked at a basic level, it also led to:

  • Fragmented access management across portals
  • Inconsistent role assignments
  • Gaps in visibility and accountability
  • Complex onboarding and offboarding workflows

Microsoft continues to expand Unified RBAC support across all Defender workloads, and future innovations will rely on this new model. Staying on legacy RBAC means missing out on new capabilities, automation scenarios, and consistent least-privilege enforcement. If your Defender environment still uses the old RBAC structure, start planning your Unified RBAC migration. Map existing roles, align them to Unified RBAC equivalents.

Another point – focus on documentation – it is important to document the RBAC assignments and which roles have high-impact permissions. A well-documented RBAC structure not only strengthens your security posture but also improves operational accountability and simplifies audits or incident response. During incidents, the clock is counting, and there is no time to research why not all permissions are applied.

Action point: When not using – move from the product-based RBAC to Unified RBAC. With the use of Unified RBAC there is way more visibility across the portal. Don’t forget to document all the roles and linked permissions.

Defender for Endpoint

For Defender for Endpoint the following items are important to check and implement.

  • Ensure Unified Audit log is enabled in Defender
  • Enable ASR rules on all Windows Devices in at least audit mode and switch to block mode based on the events. Microsoft recently released new rules, make sure to adopt new rules as well
  • Windows Server 2012R2 and 2016 still running on MMA agent, please migrate them to the new improved Unified Agent. Or better migrate the OS to one of the latest supported Windows versions
  • Manage all endpoints via Intune/ MDE-Management or other solutions
  • Be sure Linux is not for all machines running in passive mode (this is the default) when onboarding
  • Review Advanced Features (Microsoft released a couple of new configurations recently)
  • Tamper Protection is enabled, and Tamper Protection for exclusions
  • All machines are reporting correctly and are updated

Defender/Intune lets you configure various policies, but not all settings are in the default templates. Make sure at least the following are enabled:

  • EnableFileHashComputation is enabled
  • Network Protection is enabled (servers require additional configuration)
  • Firewall is enabled, and Firewall object access auditing is enabled

And another important setting:

  • Configure the hide exclusions for both users and local administrators

All of the above settings except Firewall auditing are not available in the Endpoint Security policies, and can be configured via the settings catalog/ security baseline or when not using Microsoft Intune; with the use of GPO

Read the following blog for all common Defender for Endpoint mistakes and recommendations: Common mistakes during Microsoft Defender for Endpoint deployments

Action point: Fix the most common items and check the common mistakes blog

Linux

Don’t forget to put Defender for Endpoint on Linux in active mode. The default configuration settings are different then Windows and are by default in passive mode. Same for the AV configuration – only onboarding of the MDE agent is no rocket science, all keep them managed with the correct settings, including AV scans and the correct configuration. MDE-Management can be used to maintain and manage the AV settings for Linux.

Action point: Check of Linux is correctly onboarded and managed, since by default there is no management and the AV agent is in passive mode.

Enterprise IoT

Many organizations focus on traditional endpoints, Windows, Linux, and macOS – but IoT devices often fly under the radar. As part of the device discovery is Enterprise IoT discovery. When enabled, it will give more information in the portal.

Enabling Enterprise IoT as part of your device discovery process ensures that all connected devices – not just traditional endpoints are visible, monitored, and protected. This reduces blind spots and strengthens the overall organizational security posture.

How to enable? In Microsoft Defender, select Settings > Device discovery > Enterprise IoT and toggle the option to On. When enabled, the discovered IoT devices will be included in alerts, vulnerabilities, and recommendations.

Action point: Enable Enterprise IoT as part of Device Discovery when the license is part of the existing license.

Each E5 license includes 5 EIoT devices as part of the license. More information: Manage EIoT monitoring support – Microsoft Defender for IoT | Microsoft Learn

Defender for Cloud Apps

  • Enable App Governance (included in license, often ignored!)
  • Enable all pre-set policies in App Governance and review the alerts
  • Connect App Connectors for Microsoft Azure & Microsoft 365
  • Defender for Endpoint is correctly configured for checking the traffic (Monitoring)

App Connectors

Sometimes the Microsoft 365 connector is connected by default, all not fully connected. It is important to check the App Connectors settings and ensure the Microsoft 365 Activities are configured correctly. This is also important to bring the Unified Audit Log to the CloudAppEvents table for custom detections. Without the configuration enabled, there is a blind spot in the detection capabilities.

Check the events connected as part of the connector:

Action point: Connect at least the app connector for Microsoft 365 and Azure and where possible, other apps like Okta and Box.

App Governance

As part of Microsoft Defender fort Cloud Apps the App Governance module can be enabled and configured. By default; this is sometimes not enabled and needs to be enabled manually. Go to Microsoft Defender XDR > Settings > Cloud Apps > App governance and click on Tun on app governance

When App Governance is enabled, it is visible via Cloud Apps – App Governance:

Make sure the template rules are enabled and configured under the policies section. The policies are predefined by Microsoft. By default, the rules are enabled without any policy action linked. Start with enabling the policies and fine-tune where needed, and disable/ tune rules if needed.

Action point: Enable App Governance and configure the policies

Microsoft Sentinel

Starting July 1, 2026, the Sentinel experience in Azure will retire. With this, there will be just one unified portal that brings together incidents, AI, and threat intel, and gives one solution from one single portal.

The upcoming transition means that Microsoft Sentinel needs to be migrated to the Defender portal. Customers not yet using the Defender portal should plan their transition accordingly.

Sentinel has “lived” in Azure since the start, but this is going to change. On July 1, 2026 Sentinel’s new location is in the Defender portal. If you are using Sentinel, you should definitely start thinking about the transition because, in the new Defender way things will change a bit. Just a couple of examples:

  • Move to custom detection rules in Defender (since data is already part of Defender XDR)
  • Check alert correlating and merging
  • Check automation and alert correlation
  • Evaluate Sentinel data lake for long-term retention and cheaper storage of events

Start before it’s too late. More information: Transition Your Microsoft Sentinel Environment to the Defender Portal | Microsoft Learn & Planning your move to Microsoft Defender portal for all Microsoft Sentinel customers

Action point: When using Microsoft Sentinel, start the migration from Microsoft Sentinel to Defender, don’t wait till July 1, 2026 and start already with the migration. It is not only UI change – it is a new platform which requires new techniques.

Sentinel data lake

Microsoft Sentinel data lake simplifies data management with a flexible, centralized experience in the Defender XDR portal – it is scalable and all managed by Microsoft. For analysts, it is possible to move between the analytics tier and the data lake tier.

Read the following two blogs related to data lake for reducing costs and making retention of logs possible.

Action point: Explore Sentinel datalake