Machines should be restarted to apply security configuration updates

What does the recommendation "Machines should be restarted to apply security configuration updates" check?

Flags Linux virtual machines that have applied security configuration or package updates but are still running because a reboot has not happened, so the pending changes are not yet in effect. Defender for Cloud reads this 'reboot required' state through the Azure Monitor Agent, which is why the assessment only covers Linux VMs that have that agent installed. It does not evaluate Windows machines, Arc-connected servers, or any Linux VM without the Azure Monitor Agent, and it is a posture signal with no backing Azure Policy: there is nothing to assign and nothing to deny, only a machine to restart.

Why does "Machines should be restarted to apply security configuration updates" matter?

A kernel patch, an updated openssl, or a hardened sysctl baseline only protects you once the process actually loads the new code or setting. Until the box reboots, the vulnerable libraries stay mapped in memory and the old configuration keeps serving traffic, so your patch reporting says 'fixed' while the running system is still exploitable. That gap is exactly where attackers live after a CVE goes public, and on long-lived servers it can persist for months because nobody wants to take the outage. The business consequence is a false sense of compliance: an audit shows updates installed, yet the live workload remains exposed to the very flaw the update was meant to close.

How do I fix "Machines should be restarted to apply security configuration updates"?

1. Confirm the pending reboot, then restart the affected Linux VM during a maintenance window: 'az vm restart --resource-group <rg> --name <vm>', adding '--no-wait' if you are scripting a fleet and tracking completion separately.
2. Stop the problem recurring by letting Azure Update Manager handle reboots: set the VM's reboot behaviour to 'IfRequired' (rather than 'Never') so a patch that needs a restart actually gets one inside the scheduled maintenance window, instead of leaving the machine in a pending state.
3. For estates you cannot reboot on demand, schedule a recurring maintenance configuration in Azure Update Manager with a reboot window so security updates and the restart that activates them land together on a predictable cadence, and reserve enough window time for the reboot to finish.

# Step 1: give a machine the system-assigned identity the agent needs to authenticate.
az vm identity assign --resource-group prod-apps --name legacy-app-01

# Install the machine configuration agent (instance name MUST be AzurePolicyforWindows / AzurePolicyforLinux).
az vm extension set \
  --resource-group prod-apps --vm-name legacy-app-01 \
  --publisher Microsoft.GuestConfiguration \
  --name ConfigurationforLinux \
  --extension-instance-name AzurePolicyforLinux \
  --enable-auto-upgrade true

# Step 2: assign the deploy-prerequisites initiative so identity + agent self-heal across the scope.
# Look the initiative up by its EXACT display name rather than pasting a GUID.
scope="/subscriptions/00000000-0000-0000-0000-000000000000"
setid=$(az policy set-definition list \
  --query "[?displayName=='Deploy prerequisites to enable Guest Configuration policies on virtual machines'].name" -o tsv)
az policy assignment create \
  --name deploy-gc-prereqs \
  --policy-set-definition "$setid" \
  --scope "$scope" \
  --location uksouth \
  --mi-system-assigned

# Assign the Windows compute security baseline initiative (look it up by display name too).
baseid=$(az policy set-definition list \
  --query "[?displayName=='Windows machines should meet requirements for the Azure compute security baseline'].name" -o tsv)
az policy assignment create \
  --name assign-win-baseline \
  --policy-set-definition "$baseid" \
  --scope "$scope"