Microsoft Defender for Cloud · Virtual Machines
Machines should be configured securely
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Machines should be configured securely" check?
Flags Azure VMs and Arc-enabled servers whose operating system drifts from the Azure compute security baseline, the hardening profile Microsoft derives largely from the CIS benchmark. The Azure machine configuration extension (formerly Guest Configuration) reads in-guest settings such as password length and complexity, account lockout thresholds, audit logging, administrative group membership and insecure protocols like legacy SMB or weak ciphers, compares each against the baseline, and reports every rule that fails. It assesses configuration only: it does not patch the OS, scan installed software for CVEs, or check network security groups, encryption or disk-level controls, all of which are tracked by separate Defender for Cloud recommendations. The machine must already have the extension and a managed identity, otherwise it shows as not assessed rather than non-compliant.
Why does "Machines should be configured securely" matter?
A VM can be fully patched and still trivially compromised if its OS is configured loosely: weak password and lockout policy invites brute forcing, missing audit logging blinds your incident response, and legacy protocols hand attackers a foothold for lateral movement. These baseline gaps rarely show up in a vulnerability scan, so they linger for years and are exactly what an intruder pivots through after the initial breach. Holding every machine to the CIS-aligned baseline closes the quiet misconfigurations that turn one compromised host into a domain-wide incident.
How do I fix "Machines should be configured securely"?
- Get the machine assessable: install the machine configuration extension and grant the system-assigned identity it needs, for example 'az vm extension set --publisher Microsoft.GuestConfiguration --name ConfigurationForLinux --extension-instance-name AzurePolicyforLinux --resource-group <rg> --vm-name <vm> --enable-auto-upgrade true' followed by 'az vm identity assign --resource-group <rg> --name <vm>' (use ConfigurationforWindows / AzurePolicyforWindows on Windows).
- Assign the auditing policy at scale rather than hardcoding a GUID: look the built-in up by display name with 'pid=$(az policy definition list --query "[?displayName=='\''Linux machines should meet requirements for the Azure compute security baseline'\''].name" -o tsv)' then 'az policy assignment create --name linux-baseline --policy "$pid" --scope <scope>', and repeat with the Windows equivalent display name.
- Remediate the failing rules in the guest: review each unhealthy check in Defender for Cloud, then apply the setting through your configuration tooling (OSConfig, Desired State Configuration or your existing automation) and bake the hardened image into your VM build pipeline so new machines start compliant.
Remediation script · bash
# 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" Full walkthrough (console steps, edge cases and verification) in the lesson Apply guest configuration baselines.
Is "Machines should be configured securely" a false positive?
These policies audit the broad Azure compute baseline, not a tailored profile. A locked-down jump host or a system deliberately running a stricter or app-specific standard can still flag individual rules that conflict with the generic baseline. Where that exception is reviewed and justified, use a customised baseline policy assignment or document the deviation rather than loosening the host to satisfy a rule that does not fit its role.
More Virtual Machines controls
- Adaptive application controls for defining safe applications should be enabled on your machines
- Allow list rules in your adaptive application control policy should be updated
- Authentication to Linux machines should require SSH keys
- Azure Backup should be enabled for virtual machines
- EDR configuration issues should be resolved on virtual machines
- EDR solution should be installed on Virtual Machines
- File integrity monitoring should be enabled on machines
- Guest Attestation extension should be installed on supported Linux virtual machines
- Guest Attestation extension should be installed on supported Windows virtual machines
- Linux virtual machines should enable Azure Disk Encryption or EncryptionAtHost
- Linux virtual machines should enforce kernel module signature validation
- Linux virtual machines should use only signed and trusted boot components