Skip to main content
emnode
Compliance

Ensure endpoint protection on Azure machines

One capability across every VM and Arc-connected server: make sure each machine has a working antimalware or EDR solution installed, running, and healthy, rather than absent, switched off, or weeks behind on signatures.

14 min·10 sections·AZURE

Last reviewed

Endpoint protection on machines: the basics

What does an unprotected Azure machine actually look like?

Every virtual machine in an Azure subscription, and every on-premises or other-cloud server connected through Azure Arc, is an endpoint that an attacker can land on. Endpoint protection is the layer that detects and removes malware on that machine once they do, and exposure here shows up in two distinct shapes rather than one setting. A machine can have no antimalware or EDR solution installed at all, so nothing is watching it. Or it can have a solution installed but unhealthy: the service stopped, real-time protection switched off, or signatures days out of date so it is blind to recent threats. Defender for Cloud turns each shape into its own recommendation, but the underlying risk is the same: a server running production workloads with no working defence against malware.

Microsoft Defender for Cloud raises 'Endpoint protection should be installed on machines' when it detects no supported solution running, and 'Endpoint protection health issues on machines should be resolved' when a solution is present but not in a healthy state. Both map to the same Microsoft Cloud Security Benchmark control, ES-2, and both apply to the Compute service. They read as two separate problems on the report, but they are one job: make sure every machine has a working, current endpoint defence, not merely one that was installed and then drifted.

Most of this exposure is drift, not intent. A VM built from an older image where Microsoft Defender Antivirus was never enabled. A Windows Server 2012 R2 box that predates the antimalware extension and never received it. A Linux server onboarded to the estate before anyone added Defender for Endpoint. A signature service that quietly stopped updating after a network change. The work is to find every machine that has no protection or unhealthy protection, install or repair it, and then make the protected state the default so new machines arrive defended rather than bare.

In this lesson you will learn how Azure expresses endpoint protection coverage and health, how Defender for Cloud decides a machine is unprotected or unhealthy, how to find every affected machine across a subscription, and how to install or repair protection without leaving the fleet to drift again. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The antivirus that was installed but asleep

In a striking share of ransomware post-mortems, the compromised servers did have endpoint protection installed. It was simply not working: the service had been stopped, real-time protection was off, or the signatures were weeks stale, so the agent was present but blind. This is exactly why Defender for Cloud has two separate recommendations rather than one. 'Installed' is not the same as 'protecting', and a machine flagged 'Endpoint protection health issues should be resolved' is in many ways more dangerous than one with nothing installed, because everyone assumes it is covered.

Finding unprotected and unhealthy machines across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows endpoint-protection findings spread across two dozen machines in two subscriptions: some with nothing installed, some installed but flagged unhealthy.

Rather than work the findings machine by machine, Sam starts by listing which Windows VMs are missing the antimalware extension entirely, so the wholly unprotected boxes can be separated from the ones that merely need their existing protection repaired.

Start by finding Windows VMs that have no Microsoft Antimalware or Defender for Endpoint extension installed. These machines have nothing watching them at all.

$ az vm list -d --query "[?storageProfile.osDisk.osType=='Windows'].{name:name, rg:resourceGroup}" -o tsv | while read name rg; do ext=$(az vm extension list -g "$rg" --vm-name "$name" --query "[?contains(name,'IaaSAntimalware') || contains(name,'MDE')].name" -o tsv); [ -z "$ext" ] && echo "$name NO-ENDPOINT-PROTECTION"; done
vm-payments-prod NO-ENDPOINT-PROTECTION
vm-build-agent-07 NO-ENDPOINT-PROTECTION
# vm-payments-prod runs a production workload with nothing watching it. Fix first.

A production server with no endpoint protection installed is the highest-value target in this group. A short-lived build agent is real but lower priority. Triage by what the machine runs, not by name.

How Defender for Cloud decides a machine is unprotected or unhealthydeep dive

Defender for Cloud recognises a range of supported solutions: Microsoft Defender Antivirus, which is built into Windows Server 2016 and later; the Microsoft Antimalware extension (publisher Microsoft.Azure.Security, type IaaSAntimalware) for older Windows such as Server 2012 R2; Microsoft Defender for Endpoint on Linux; and several third-party products including Trend Micro, Symantec, McAfee, Sophos and Kaspersky. For Windows it reads protection state through the Get-MpComputerStatus surface. 'Endpoint protection should be installed on machines' fires when no supported solution is found running, in practice when AMServiceEnabled is false and nothing else is detected, so the machine is genuinely undefended.

'Endpoint protection health issues on machines should be resolved' fires when a solution is present but not healthy. On Windows that means any of these properties is false: AMServiceEnabled, AntispywareEnabled, RealTimeProtectionEnabled, BehaviorMonitorEnabled, IoavProtectionEnabled or OnAccessProtectionEnabled, or either AntispywareSignatureAge or AntivirusSignatureAge is seven days or more, meaning the agent is running but a week or more behind on definitions. On Linux the equivalent is checking that Defender for Endpoint reports real-time protection enabled, for example via mdatp health. The distinction matters: a machine can pass the install check and still fail the health check because the agent is asleep or stale.

Defender for Cloud assesses these against the Microsoft Cloud Security Benchmark (control ES-2) on a periodic cycle using agentless scanning, which replaced the retired Log Analytics agent, so a fix does not flip the recommendation to Healthy instantly. The change on the machine is immediate, but the posture catches up on the next assessment and resources can take up to 24 hours to move to the Healthy tab. The strongest position pairs the per-machine fix with an Azure Policy backstop, so coverage is guaranteed for machines that do not exist yet rather than only checked for the ones that do.

What is the impact of leaving machines unprotected?

The direct impact is that malware runs undetected. A server with no antimalware, or with protection that has been switched off or left stale, has nothing watching for malicious files, fileless attacks or known signatures. An unhealthy agent is the worst of both worlds: it is present, so everyone assumes the machine is covered, but it is not actually protecting anything. This is exactly how a single compromised endpoint becomes a foothold that an attacker uses to move laterally and, increasingly, to stage ransomware across the estate.

The second-order impact is blast radius and dwell time. Endpoint protection is also the EDR sensor that gives the security team visibility into what is happening on a machine. A fleet with gaps in coverage is a fleet with blind spots, the places an attacker can sit undetected for weeks. Closing the gaps shrinks both the attack surface and the time an intruder can operate unseen, and it gives the SOC a consistent signal across every server rather than a patchwork.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA, PCI DSS and the UK and EU data-protection regimes, expects evidence that endpoints are protected with current, monitored antimalware. The Microsoft Cloud Security Benchmark codifies this as ES-2. A passing set of endpoint-protection recommendations across every subscription is among the most basic artefacts an auditor or a cyber-insurer expects, and one of the most damaging to be unable to produce.

How do you get every machine protected safely?

Work the capability as one loop rather than chasing individual findings. The order matters: separate the wholly unprotected machines from the ones that merely need a repair, and fix the highest-value workloads first, so the most exposed servers are defended before you sweep up the rest.

1. Inventory every machine by protection state

List the machines with no supported solution installed and, separately, the ones installed but flagged unhealthy: stopped service, real-time protection off, or signatures seven or more days stale. Treat this inventory as the source of truth, not the raw finding count, because the two recommendations describe different fixes (install versus repair) and one machine can move between them.

2. Install where it is missing, matched to the OS

On Windows Server 2016 and later, Microsoft Defender Antivirus is built in: enable it and, where you want managed configuration, add the Microsoft Antimalware extension. On older Windows such as Server 2012 R2, deploy the antimalware extension to provide the engine. On Linux, onboard Defender for Endpoint. Prioritise production and data-bearing machines over short-lived agents.

3. Repair the unhealthy machines

For machines that have protection but fail the health check, restart the antimalware service, re-enable real-time protection, and force a signature update so definitions are current. On Linux, confirm Defender for Endpoint reports real-time protection enabled. A machine that was amber because signatures fell behind clears once it updates and Defender for Cloud re-assesses.

4. Ratchet it shut with Azure Policy and Defender for Servers

Assign the built-in 'Deploy default Microsoft IaaSAntimalware extension for Windows Server' policy so any new Windows server without the extension receives it automatically, and enable Defender for Servers so Defender for Endpoint is the EDR layer and the health assessment runs continuously. That way coverage is enforced for machines that do not exist yet, not merely checked for the ones that do.

# Install the Microsoft Antimalware extension on a Windows VM that has none.
# Microsoft Defender Antivirus is built into Windows Server 2016+; this extension
# adds managed configuration and covers older Windows such as Server 2012 R2.
az vm extension set \
  --resource-group rg-payments \
  --vm-name vm-payments-prod \
  --name IaaSAntimalware \
  --publisher Microsoft.Azure.Security \
  --version 1.5 \
  --settings '{"AntimalwareEnabled": true, "RealtimeProtectionEnabled": true, "ScheduledScanSettings": {"isEnabled": true, "scanType": "Quick", "day": 7, "time": 120}}'

# Ratchet it shut: auto-deploy the antimalware extension to any future Windows server.
az policy assignment create \
  --name deploy-antimalware-windows \
  --display-name "Deploy Microsoft Antimalware on Windows servers" \
  --policy 2835b622-407b-4114-9198-6f7064cbe0dc \
  --location uksouth \
  --assign-identity --identity-scope "/subscriptions/00000000-0000-0000-0000-000000000000" \
  --role Contributor --role-scope "/subscriptions/00000000-0000-0000-0000-000000000000" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

# On Linux, confirm Defender for Endpoint real-time protection is on; enable if not.
# mdatp health --field real_time_protection_enabled
# mdatp config real-time-protection --value enabled

Quick quiz

Question 1 of 5

Defender for Cloud shows both 'Endpoint protection should be installed on machines' and 'Endpoint protection health issues on machines should be resolved' across the fleet. What is the most efficient way to think about them?

You can now treat endpoint protection as one capability rather than a scatter of findings: inventory every machine by protection state, install where it is missing matched to the operating system, repair the machines that are present but unhealthy, and ratchet the estate shut with an auto-deploy Azure Policy and Defender for Servers. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.