Skip to main content
emnode
Compliance Medium severity MCSB IM-3

Microsoft Defender for Cloud · Virtual Machines

Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity

Written and reviewed by Emnode · Last reviewed

What does the recommendation "Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity" check?

Flags any Azure virtual machine that has the Guest Configuration extension (now called the Machine Configuration extension) installed but no system-assigned managed identity to authenticate it. The extension uses that identity to read and write its own compliance state to the Machine Configuration service, so without it the machine cannot report against any guest baseline. The check only inspects the identity attached to the VM; it does not validate the contents of any specific configuration assignment, nor does it report which baseline policies pass or fail. It also covers Azure VMs only: Arc-enabled servers are out of scope, and because the check looks specifically for a system-assigned identity, a VM that carries only a user-assigned identity is still flagged.

Why does "Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity" matter?

The Machine Configuration extension is the prerequisite for every in-guest audit Azure runs: OS hardening baselines, the Windows and Linux compute security baselines in the Microsoft Cloud Security Benchmark, password policy, and similar checks all depend on it. If the extension is present but has no identity to authenticate with, it cannot talk to the service, so those baselines silently stop reporting. The business consequence is a blind spot that looks like compliance: dashboards show no failures because nothing is being assessed, and a drifted or hardening-regressed machine can sit unnoticed until an incident or an audit exposes it. Granting the system-assigned identity restores the trust path so guest baselines produce real, current results.

How do I fix "Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity"?

  1. On each flagged VM, enable a system-assigned managed identity: Identity blade, System assigned tab, set Status to On, or run az vm identity assign --resource-group <rg> --name <vm>. This is the exact setting the recommendation wants and needs no role assignment, because the identity only authenticates the machine to the Machine Configuration service.
  2. Remediate at scale by assigning the built-in Modify policy that adds the identity automatically. Look it up by display name rather than pasting a GUID: pid=$(az policy definition list --query "[?displayName=='Add system-assigned managed identity to enable Guest Configuration assignments on virtual machines with no identities'].name" -o tsv); then az policy assignment create --name add-gc-sami --policy "$pid" --scope <scope> --location <region> --mi-system-assigned, and run a remediation task so existing VMs are fixed, not just new ones.
  3. Bake the identity into provisioning so new machines are born compliant. In Bicep set identity: { type: 'SystemAssigned' } on the Microsoft.Compute/virtualMachines resource, and deploy the extension through the same module so the two never drift apart.

Remediation script · bash

# 1. Give the app its own identity and capture the principal ID.
principalId=$(az webapp identity assign \
  --resource-group payments-rg \
  --name payments-api-prod \
  --query principalId -o tsv)

# 2. Grant least privilege on the exact resource it uses (not the subscription).
az role assignment create \
  --assignee-object-id "$principalId" \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/payments-rg/providers/Microsoft.Storage/storageAccounts/paymentsdata"

# 3. Only after the code uses DefaultAzureCredential and the new path is verified,
#    delete the stored secret so there is nothing left to leak.
az webapp config appsettings delete \
  --resource-group payments-rg --name payments-api-prod \
  --setting-names StorageConnectionString

# 4. Ratchet it shut: audit any future app created without a managed identity.
az policy assignment create \
  --name audit-webapp-managed-identity \
  --policy 2b9ad585-36bc-4615-b300-fd4435808332 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Full walkthrough (console steps, edge cases and verification) in the lesson Use managed identities instead of stored secrets.

Is "Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity" a false positive?

A VM you have deliberately set up with a user-assigned managed identity for Guest Configuration may still be flagged, because this specific recommendation looks only for a system-assigned identity. Note that Microsoft's prerequisite documentation treats a system-assigned identity as the standard path and the user-assigned route is still in preview, so the cleanest fix is usually to enable the system-assigned identity. If you have a deliberate reason to stay on the preview user-assigned prerequisite policy instead, exempt the machine from this control with that rationale rather than adding a second identity just to silence it.