Microsoft Defender for Endpoint Guide: Deployment, Hardening and Operations

Microsoft Defender for Endpoint is only as strong as its configuration and the people who can change it, and most weak deployments fail on both counts. Many organisations have the licence through Microsoft 365 E5, onboard devices, and stop there: tamper protection is left to defaults, attack surface reduction (ASR) rules sit in audit mode for years, exclusion lists grow unchecked and too many people can run scripts on any device through live response. This guide covers onboarding and rollout rings, the role model and device groups, API applications, hardening settings, logging and the misconfigurations that let attackers switch the sensor off. It is written for endpoint engineers, SOC leads and security architects running Defender for Endpoint on Windows fleets, with notes on macOS and Linux where they differ.

Key takeaways

• Tamper protection is the first control, not an option. Manage it centrally from the Defender portal or Intune, and protect antivirus exclusions too, or a local administrator can blind the agent.
• Roles and device groups decide your blast radius. Live response, response actions and settings permissions are as powerful as domain admin on endpoints; scope them with device groups and Microsoft Entra groups.
• ASR rules belong in Block, not Audit. Start with the three standard protection rules in Block, test the rest in Audit for a defined period, then enforce by ring.
• Exclusions are the most abused weakness. Every exclusion switches off scanning, and process exclusions also switch off network protection and ASR for that process.
• API applications are privileged non-human identities. An app that can isolate devices or run live response needs an owner, a certificate instead of a secret, and monitoring like any admin account.

Plans, components and onboarding

Defender for Endpoint is sold as Plan 1 and Plan 2, plus Microsoft Defender for Business for smaller organisations; Microsoft 365 E5 and E5 Security include Plan 2. Endpoint detection and response (EDR), EDR in block mode and live response require Plan 2, while device groups are supported in both plans. Confirm the current Plan 1 and Plan 2 split on Microsoft's licensing page before buying, as it changes.

Onboarding starts in the Defender portal under Settings, Endpoints, Device management, Onboarding: choose the operating system, the connectivity type (Streamlined, which has prerequisites, or Standard) and the deployment method, usually Intune or Configuration Manager. Microsoft recommends a ring-based rollout:

1. Evaluate (ring 1): about 50 devices, including security staff and developers. Check devices appear in the device inventory, alerts reach the dashboard, and run Microsoft's detection test and an attack simulation.
2. Pilot (ring 2): the next 50 to 100 production endpoints across business units and server roles. Put ASR rules in Audit and collect events.
3. Full deployment (ring 3): the rest of the estate in larger increments, with the same exit criteria at each step.
4. Ongoing updates: keep a validation ring for Windows (Microsoft's Security Update Validation Program covers selected machines before Patch Tuesday) and run a few macOS and Linux systems on the Beta or Preview channel. Changing channel after installation requires uninstalling and reinstalling.
5. Rollback: keep offboarding packages and the previous antivirus configuration available per ring, and move a misbehaving ASR rule back to Audit with the same tool that deployed it rather than by local change.

If another antivirus stays primary, Defender Antivirus runs in passive mode. In passive mode real-time protection, network protection, ASR rules and file, IP, URL and certificate indicators do not work; turn on EDR in block mode so behavioural EDR detections can still be remediated. It needs cloud-delivered protection on and can also be set through the Defender CSP setting Configuration/PassiveRemediation or the Group Policy setting Enable EDR in block mode.

How identity and access work in Microsoft Defender for Endpoint

All portal access comes from Microsoft Entra ID. Before role-based access control (RBAC) is enabled, Security Administrator has full portal access and Security Reader has read-only access. New Defender for Endpoint customers since 16 February 2025 get Microsoft Defender XDR Unified RBAC (URBAC) only; existing tenants keep their roles until they migrate. Opting in to RBAC cannot be reversed, and read-only users lose access until they are given a role, so prepare Entra groups first.

Device groups control who sees which devices and how much automation runs on them. A device joins the highest-ranked group whose rules it matches (device name, domain, tags, operating system), unmatched devices fall into Ungrouped devices, and a tenant can hold up to 2,000 groups. Each group has a remediation level:

Device groups become access boundaries only when you assign Entra user groups to them; otherwise every portal user sees every group. A practical pattern, which Microsoft also suggests, is tiered: local SOC triages its own region, a regional SOC remediates, a global SOC can do everything, and Tier 0 assets such as domain controllers sit in their own group with access granted through Privileged Identity Management.

Admin roles and privileged access

Defender for Endpoint permissions are effectively remote administration of every onboarded device. Treat them as privileged access, not as an analyst tool. In URBAC the key permissions are:

• Global Administrator: also has unrestricted Defender access. Keep it for emergencies, as Microsoft advises, and alert on every new assignment. In the Stryker Intune wiper attack a compromised administrator created a new Global Administrator and used the legitimate device management service to wipe devices; the same tenant-wide reach applies to Defender response actions. See the Privileged Identity Management (PIM) Guide.
• Live response governance: enable Enable live response and Enable live response for servers only with RBAC in place, and keep Enable live response unsigned script execution off unless there is a documented need. Scripts run only from the tenant library, so restrict who can upload to it (uploading from the console requires Manage Security Settings in the legacy model). Review the Command log after sessions, and remember Ctrl+C in the portal does not stop a command already running on the device.
• Separation of duties: the person who adds exclusions or indicators (Detection tuning, Core security settings) should not be the same person who approves remediation on the same assets.
• Strong authentication: require phishing-resistant MFA and Conditional Access for every account holding Response, live response or settings permissions.

Integrations, API tokens and service accounts

SOAR playbooks, SIEM connectors, ticketing tools and in-house scripts call the Defender for Endpoint API through a Microsoft Entra app registration with WindowsDefenderATP application permissions, which require admin consent. Permissions such as Isolate machine or Run advanced queries give the app the same power as a privileged analyst, without MFA. Microsoft's example uses a client secret and the client credentials grant against the resource https://api.securitycenter.microsoft.com; a certificate is also supported and is the better choice.

• Inventory every app: list app registrations and enterprise applications holding WindowsDefenderATP permissions, with a named owner and purpose for each.
• Least privilege per integration: a SIEM connector needs alert read permissions, not machine isolation; a SOAR playbook that isolates devices should not also run live response scripts.
• Credentials: prefer certificates or workload identity federation over client secrets, keep secret lifetimes short, store them in a vault and rotate on staff change. See the Entra ID Applications and Consent Guide.
• Multitenant partner apps: an MSSP app consented in your tenant runs with your data. Review consent, restrict it to the permissions in the contract, and remove it on exit.
• Monitor use: alert on new credentials added to these apps, sign-ins from unexpected IP ranges and response actions triggered by apps outside playbook windows.

On the endpoint, the identity angle is local administrator rights. Any account in the local Administrators group can attempt to stop or reconfigure the agent, which is why tamper protection matters. Remove standing local admin and manage the built-in account with Windows LAPS. See the Local Administrator Password Solution (LAPS) Guide.

Hardening baseline

Tamper protection and exclusions

With tamper protection on, virus and threat protection, real-time protection, behaviour monitoring, IOAV, cloud protection, security intelligence updates, automatic actions, notifications, archive scanning and exclusions cannot be changed locally, and Group Policy changes to those settings are ignored. Microsoft is renaming the management setting to controlled configuration. Turn it on tenant-wide from the Defender portal or with the Intune Antivirus policy, profile Windows Security Experience, setting Tamper protection (device). Use troubleshooting mode for temporary changes instead of switching tamper protection off.

Exclusions are only protected when all conditions hold: platform 4.18.2211.5 or later, DisableLocalAdminMerge enabled, devices managed by Intune only or Configuration Manager only (co-managed devices are not supported), and exclusions managed in that tool. The read-only registry value HKLM\SOFTWARE\Microsoft\Windows Defender\Features\TPExclusions reports 1 when exclusions are protected.

Attack surface reduction rules

Microsoft's ASR deployment phases are Plan, Test (Audit), Enable (Block or Warn by ring) and Manage and monitor. Use per-rule file and folder exclusions rather than global antivirus exclusions when a rule blocks a legitimate tool.

Driver and kernel protection

The Microsoft Vulnerable Driver Blocklist has been on by default since the Windows 11 2022 update and is enforced when memory integrity (HVCI), Smart App Control or S mode is active. Microsoft recommends enabling memory integrity and the ASR driver rule together; test memory integrity on each hardware model first, because incompatible drivers can fail to load or, rarely, stop the device booting. See the Windows Endpoint Hardening Guide and the Microsoft Intune Guide.

Exclusions hygiene

• Full paths only: a bare file name is not a reliable exclusion; use a fully qualified path.
• One list per workload: separate SQL Server, IIS and backup exclusions, and check the automatic server role exclusions first.
• Environment variables: the antivirus service runs as LocalSystem, so %TEMP% resolves to C:\Windows\TEMP.
• Process exclusions are expensive: they also stop network protection and ASR rules for that process. See the EDR Tuning and Exclusions Management Guide.

Logging and detection

Defender for Endpoint raises an alert when tampering is attempted, and the device timeline and advanced hunting hold the evidence. Locally, the Microsoft-Windows-Windows Defender/Operational log records ASR blocks (event ID 1121), ASR audits (1122), user overrides in Warn mode (1129) and configuration changes (5007). The CodeIntegrity Operational log records event 3099 when the driver blocklist policy loads.

Stream these tables to your SIEM so the evidence survives if an attacker impairs the sensor (MITRE ATT&CK T1685 Disable or Modify Tools). See the Microsoft Sentinel Guide and the KQL for Threat Hunting Guide. Also log the control plane: role and device group changes, exclusion and indicator changes, live response sessions and API app activity in the Microsoft 365 unified audit log and Entra audit logs.

Metrics that show the deployment is working:

• Coverage: percentage of managed devices onboarded and reporting in the last 7 days, against the CMDB or Intune inventory.
• Tamper protection: percentage of devices with tamper protection on and, where conditions allow, TPExclusions equal to 1.
• ASR enforcement: percentage of devices with the standard protection rules in Block, and number of rules still in Audit after their planned end date.
• Exclusion count: number of antivirus and process exclusions, each with an owner and review date; the trend should be flat or falling.
• Privileged access: number of users holding Advanced live response or Response permissions permanently rather than through PIM.
• Response time: median time from high-severity alert to containment action.

Common misconfigurations

• Tamper protection managed per device: left to the Windows Security app or defaults, so policy cannot prove it is on, and co-managed devices leave exclusions unprotected.
• ASR rules forgotten in Audit: rules tested years ago never move to Block, or a script quietly switched a rule back to Audit (Microsoft names both causes). Ransomware operators then use the exact paths the rules would have stopped. See the Ransomware Prevention Guide.
• Broad exclusions: whole folders such as temporary or download directories, script interpreters as process exclusions, or bare file names. Attackers look for these (ATT&CK T1564.012 File/Path Exclusions).
• Everyone is Security Administrator: no URBAC custom roles, no device group scoping, and advanced live response available to the whole SOC and to the MSSP.
• Passive mode without EDR in block mode: devices with a third-party antivirus get no ASR rules or indicators and no behavioural blocking either.
• Unmonitored API apps: old automation apps holding isolation and live response permissions with client secrets that never expire and no owner.

Framework mapping

In CIS Controls v8.1 the platform supports Control 10 (Malware Defenses), Control 8 (Audit Log Management) and Control 13 (Network Monitoring and Defense).

Practitioner checklist

• Confirm licence coverage (Plan 2 for EDR, EDR in block mode and live response) for every device class, including servers.
• Onboard in Evaluate, Pilot and Full rings with documented exit criteria and a detection test per ring.
• Turn on tamper protection tenant-wide from the portal or Intune and meet the conditions for protected exclusions.
• Set the three standard protection ASR rules to Block now; give every other rule an Audit end date.
• Enable memory integrity where hardware allows and keep the vulnerable driver blocklist on.
• Build URBAC custom roles and device groups by tier; put Advanced live response and settings permissions behind PIM.
• Keep unsigned live response scripts disabled and review the Command log weekly.
• Inventory WindowsDefenderATP API apps, assign owners, replace secrets with certificates and remove unused permissions.
• Review every exclusion quarterly with an owner and justification; remove bare names and broad folders.
• Stream Device tables and control-plane audit logs to the SIEM and alert on tamper attempts and policy changes.

Standards and references

• Microsoft Learn: Protect security settings with tamper protection
• Microsoft Learn: Attack surface reduction rules reference
• Microsoft Learn: Endpoint detection and response in block mode
• Microsoft Learn: Permissions in Microsoft Defender XDR Unified RBAC
• Microsoft Learn: Create and manage device groups
• Microsoft Learn: Investigate entities on devices using live response
• Microsoft Learn: Common mistakes to avoid when defining exclusions
• MITRE ATT&CK: Disable or Modify Tools

Related NHI Mgmt Group resources: EDR Guide · Top 10 EDR Evasion Techniques · Microsoft 365 Security Guide · Endpoint Hardening Checklist · Endpoint Security Guide