Microsoft Defender for Servers Overview

Last updated: 2026-07-27

References

• Defender for Servers overview
• Plan a deployment
• Deploy Defender for Servers
• Defender for Endpoint detection test
• Configuration, plans, and pricing

Back to the documentation hub

Defender for Servers protects Windows and Linux machines in Azure, AWS, GCP, and on-premises environments. Non-Azure machines normally connect through Azure Arc. Microsoft Defender for Endpoint supplies endpoint detection and response, and the plan adds vulnerability assessment, file integrity monitoring, and agentless disk scanning so a server is protected whether or not an agent is healthy at any moment.

Why enable it

Servers hold the operating systems, credentials, and data that attackers pursue after an initial foothold. Defender for Servers gives those machines the same endpoint-grade detection and response used to protect managed devices, extended across every cloud and on-premises estate from a single plan.

Without Defender for Servers	With the plan enabled
Virtual machines (VMs) rely on inconsistent, per-team antivirus	Unified Defender for Endpoint endpoint detection and response (EDR) across Windows and Linux
Vulnerabilities are discovered on a periodic scan cycle	Integrated vulnerability assessment reports continuously
Non-Azure servers sit outside central security	Arc-connected AWS, GCP, and on-premises servers are covered
A disabled agent means a blind spot	Agentless disk scanning still evaluates the machine

Value in one line: it extends enterprise endpoint detection, vulnerability management, and hardening to every server, not just the ones inside Azure.

How it works

Defender for Servers combines two layers. The first is Microsoft Defender for Endpoint, whose sensor runs on the machine to provide next-generation antivirus, attack surface reduction, and behavioral endpoint detection and response (EDR). Its alerts and device data flow into both Defender for Cloud and the Microsoft Defender portal, so a server incident sits next to the endpoint and identity signals it relates to.

The second layer is agentless. Defender for Cloud periodically snapshots the machine's disk to assess installed software, vulnerabilities, exposed secrets, and malware without depending on a running agent, while integrated vulnerability assessment keeps a live list of weaknesses. Non-Azure machines join through Azure Arc, which projects them into a subscription so the same plan, policies, and reporting apply whether the server runs in Azure, another cloud, or a datacenter.

Plan choice

Plan	Use case
Plan 1	Core server protection with Defender for Endpoint capabilities
Plan 2	Broader server protection, including additional vulnerability, monitoring, and cloud workload capabilities

Always compare the current plan matrix before purchase; features, billing, and included data allowances can change. Use the configuration, plans, and pricing reference for the current pricing and regional-support checks.

Enable

1. Inventory Azure VMs, Arc-enabled servers, VM scale sets, and multicloud VMs.
2. In Environment settings, enable the selected Servers plan.
3. Review Settings & monitoring and configure required components.
4. Configure Defender for Endpoint integration and onboarding status.
5. Define Log Analytics and data collection architecture where required.
6. Roll out through a pilot ring before enabling all subscriptions.

Verify and operate

• Check Defender for Cloud inventory and Defender portal device inventory.
• Confirm sensor health, vulnerability assessment, and recommendation freshness.
• Run Microsoft's documented detection test only on an approved test machine.
• Route alerts to the incident owner and test machine isolation procedures.
• Track uncovered machines, stale agents, exclusions, and unsupported systems.

Architecture and prerequisites

• Endpoint sensor: Plan 1 and Plan 2 provision Microsoft Defender for Endpoint through the unified Microsoft Defender for Endpoint (MDE) extension, with automatic onboarding for Azure and Arc machines.
• Agentless disk scanning: snapshot-based assessment evaluates vulnerabilities, exposed secrets, and malware without an in-guest agent; it complements, not replaces, the MDE sensor.
• Data collection: the Azure Monitor Agent (AMA) supports capabilities such as file integrity monitoring; the legacy Log Analytics agent (MMA) is retired, so new deployments should standardize on AMA or agentless.
• Connectivity: machines need outbound access to Defender for Endpoint and Defender for Cloud service endpoints; closed networks require the documented proxy or private configuration.
• Permissions: enabling the plan requires Security Admin or Owner on the subscription; Arc onboarding requires the Azure Connected Machine Onboarding role.

Detections and MITRE ATT&CK

Alerts map to MITRE ATT&CK so responders can reason in tactic terms:

Example detection	ATT&CK tactic
Suspicious PowerShell or shell command execution	Execution
Credential-dumping behavior (for example Local Security Authority Subsystem Service (LSASS) access)	Credential Access
Reverse shell or anomalous outbound connection	Command and Control
Web shell or scheduled-task persistence	Persistence
Sign-in from a known-malicious IP	Initial Access

Alerts surface in Defender for Cloud and the Microsoft Defender portal and can be exported to the SecurityAlert table in Log Analytics or Microsoft Sentinel.

Scale the deployment

• Enable the plan at management-group scope and use the Defender for Endpoint integration setting so new machines onboard automatically.
• For Arc, deploy the Connected Machine agent at scale with a service principal, a configuration-management package, or the install script.
• Govern configuration with Azure Policy (for example, "Defender for Servers should be enabled") and remediate non-compliant subscriptions with DeployIfNotExists.

Important

Azure Arc enrollment and Defender for Servers licensing are separate concerns. An Arc-connected server is not necessarily protected until its plan and required components are healthy.

Operational decisions

• Select a single onboarding authority for Azure VMs, Arc servers, and endpoint tooling so duplicate agents and coverage gaps can be reconciled quickly.
• Define who may isolate a server, what application dependency check is required, and the recovery evidence needed before it is released.
• Retain plan scope, extension health, MDE device ID, OS owner, and offboarding date for every protected server.

Business example

An Arc-enabled SQL Server in a datacenter appears in Azure inventory but has no Defender for Endpoint device record. The team enables Defender for Servers Plan 2 on the Arc resource's subscription, verifies the MDE extension reports healthy, and uses the documented detection test on a maintenance-window clone. They then add a policy initiative so future Arc servers are onboarded automatically.