Compliance

Keep Azure machines patched

One capability across every VM and Arc-enabled server: make sure each machine is reporting its update state, is actually installing the operating-system patches it is missing, and carries the agent that lets you audit what is running inside it.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-aks-upgrade-system-pods-vulnerabilities azure-machines-periodic-update-check azure-system-updates-installed azure-system-updates-update-center azure-vm-guest-config-agent

Patching Azure machines: the basics

What does an unpatched, unmonitored Azure machine actually look like?

A virtual machine is the place where unpatched code turns into an exploited host, and the exposure shows up in two distinct shapes rather than one setting. The first is the patches themselves: a machine can be missing operating-system updates that close known, published vulnerabilities, and it stays missing them until something installs them. The second is visibility: a machine can lack the Guest Configuration extension and a managed identity, which is the agent that lets Azure read the configuration inside the guest, so you cannot even audit whether it is patched or hardened. Defender for Cloud turns each into its own recommendation, but the underlying risk is the same: a host running code that more attackers can exploit, or that you can no longer see inside, than you meant.

Microsoft Defender for Cloud expresses this as 'System updates should be installed on your machines', which maps to the Microsoft Cloud Security Benchmark control PV-6 (Rapidly and automatically remediate vulnerabilities), and 'Guest Configuration extension should be installed on machines', which maps to PV-2 (Audit and enforce secure configurations). The first is powered by Azure Update Manager and fires when a supported machine is missing an update. The second fires when a machine has no machine configuration agent, so its in-guest posture is a blind spot. They read as two separate problems on the report, but they are one job: keep every machine current on patches, and keep every machine visible enough to prove it.

Most of this exposure is drift, not intent. A VM built from an image that was current at the time and never re-assessed, a fleet that was onboarded before periodic assessment was switched on, an Arc-enabled server that joined without the machine configuration extension. The work is to get every machine reporting its update state through Update Manager, install what is missing, deploy the Guest Configuration extension with a system-assigned managed identity so the audit can run, and then enforce assessment so a machine cannot quietly fall behind again.

In this lesson you will learn how Azure expresses machine patch state and in-guest visibility, how to find every machine that is missing updates or missing the configuration agent across a subscription, and how to bring them current without breaking the few that need careful reboot scheduling. 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 patch that shipped before the breach

Some of the most damaging cyber incidents on record exploited vulnerabilities that already had a patch available, sometimes for months. WannaCry tore through unpatched Windows machines in 2017 using a flaw Microsoft had fixed almost two months earlier; the Equifax breach the same year traced back to a known component vulnerability with a patch that had been out for weeks. The pattern is always the same: the fix existed, the machine did not install it, and an automated scanner found the gap before anyone closed it. Azure can now assess and install operating-system updates automatically through Azure Update Manager, but every machine onboarded before that was switched on still needs to be brought into the loop explicitly.

Finding unpatched and unmonitored machines across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows patch findings spread across two dozen machines in two subscriptions, plus a cluster of machines that have no Guest Configuration extension at all, so their in-guest state is unknown.

Rather than work the findings one by one, Sam starts by listing which machines are even reporting their patch state to Azure Update Manager, because a machine with no periodic assessment is not 'patched', it is simply unmeasured, and that is the gap to close before anything else.

Start by listing each machine's patch assessment mode. A machine on 'ImageDefault' is not being assessed on a schedule, so its update state is stale or unknown.

$ az vm list --query "[].{name:name, assess:osProfile.windowsConfiguration.patchSettings.assessmentMode, patch:osProfile.windowsConfiguration.patchSettings.patchMode}" -o table

Name Assess Patch

---------------- ------------------ -------------------

web-prod-01 ImageDefault ImageDefault

batch-internal AutomaticByPlatform AutomaticByPlatform

# web-prod-01 is internet-facing AND not on periodic assessment. Onboard it first.

An internet-facing machine that is not even being assessed for missing updates is the highest-value target in this group. Bring it into Update Manager first, then patch.

How Defender for Cloud decides a machine is unpatched or unmonitoreddeep dive

The patch recommendation resolves to data that Azure Update Manager gathers. Update Manager performs a periodic assessment, by default once every 24 hours, comparing the installed packages on the machine against the available updates from its update source, and reports any that are missing. For that to happen the machine must be on periodic assessment: the 'assessmentMode' property set to 'AutomaticByPlatform' rather than 'ImageDefault'. A machine left on 'ImageDefault' is never assessed on a schedule, so it can be badly behind while showing no recent finding at all. Installation can then be handled by 'patchMode' set to 'AutomaticByPlatform', which lets the platform install patches on a maintenance schedule, or by a one-time Fix from the recommendation.

The configuration recommendation resolves to the Guest Configuration extension, now branded Azure Machine Configuration. The extension (AzurePolicyforWindows or AzurePolicyforLinux) is the agent that reads settings inside the guest, and it has a hard prerequisite: a system-assigned managed identity. A machine that has the extension installed but no system-assigned identity is still non-compliant, because the identity is what authorises the in-guest audit. Without that pairing, Azure cannot read the machine's configuration, so the entire family of in-guest baseline checks is blind on that host.

Defender for Cloud evaluates both against the Microsoft Cloud Security Benchmark on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly. The control-plane change and the agent install are immediate, but the posture catches up on the next assessment. This matters when you are gathering audit evidence against a deadline. The strongest position pairs the per-machine settings with an Azure Policy backstop: built-in DeployIfNotExists policies that enable periodic assessment and deploy the configuration extension with a managed identity to every new machine, so no host can be created outside the loop again.

What is the impact of leaving machines unpatched?

The direct impact is compromise through a known vulnerability. An unpatched, internet-reachable machine is exploitable by anyone who finds it, and internet-facing hosts are found and scanned quickly by automated tooling. The overwhelming majority of machine compromises run through a flaw that already had a patch available: the fix existed, the host did not install it. A machine missing the configuration agent compounds this, because you cannot even see whether it is patched or hardened, so the host is both exposed and invisible.

The second-order impact is blast radius. Every unpatched machine is a foothold that, once taken, lets an attacker move laterally into the rest of the estate. Keeping machines current shrinks that surface to the few hosts you are actively maintaining behind a known schedule, which are the ones you can monitor and reason about. A fleet on automatic assessment and patching is one where a new critical vulnerability is installed everywhere within a known, bounded window rather than whenever someone gets to it.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA, PCI DSS and the UK and EU data-protection regimes, expects evidence of a working patch management process: that machines are assessed, that updates are installed on a defined cadence, and that configuration is audited. A passing set of system-update and configuration-extension recommendations across every subscription is the cheapest and most defensible artefact you can hand an auditor.

How do you keep machines patched safely?

Work the capability as one loop rather than chasing individual findings. The order matters: get every machine reporting its state and deploy the audit agent before you start installing, so you patch from a complete and visible inventory rather than a partial one.

1. Inventory every machine by assessment state

List the machines that are on periodic assessment and the ones still on 'ImageDefault', and the machines that have the Guest Configuration extension with a managed identity versus those that do not. Treat this inventory as the source of truth, not the Defender finding count, because a machine that is not being assessed shows no recent patch finding while being badly behind.

2. Bring every machine into Azure Update Manager

Set 'assessmentMode' to 'AutomaticByPlatform' so each machine is assessed daily, and deploy the Guest Configuration extension with a system-assigned managed identity so its in-guest configuration can be audited. For Arc-enabled and multicloud machines, onboard them through Azure Arc first. This is the step that turns 'unmeasured' into 'measured'.

3. Install missing updates, highest risk first

Patch internet-facing and high-severity machines first using a one-time Fix or a scheduled patch run, then work down to internal and non-production hosts. Schedule the reboots that some updates require into a maintenance window rather than installing blind in production. Prioritise by exposure and severity, not by machine name.

4. Ratchet it shut with Azure Policy

Assign the built-in DeployIfNotExists policies that enable periodic assessment, set automatic patching to 'AutomaticByPlatform', and deploy the configuration extension with a managed identity to every new machine. Back this with a maintenance configuration that defines the patch schedule, so a newly created host is current and visible by default rather than by someone remembering to onboard it.

# Bring machines into Azure Update Manager: switch on periodic assessment
# and platform-orchestrated patching, then deploy the audit agent.
for vm in $(az vm list -g rg-workloads --query "[].name" -o tsv); do
  az vm update -g rg-workloads -n "$vm" \
    --set osProfile.windowsConfiguration.patchSettings.assessmentMode=AutomaticByPlatform \
    --set osProfile.windowsConfiguration.patchSettings.patchMode=AutomaticByPlatform
  # Guest Configuration extension requires a system-assigned identity.
  az vm identity assign -g rg-workloads -n "$vm"
  az vm extension set -g rg-workloads --vm-name "$vm" \
    --name AzurePolicyforWindows \
    --publisher Microsoft.GuestConfiguration
  echo "$vm: periodic assessment on, auto-patch on, config extension deployed"
done

# Ratchet it shut: assign the built-in policy that enables periodic
# assessment on every machine in the subscription.
az policy assignment create \
  --name enable-periodic-assessment \
  --policy 59efceea-0c96-497e-a4a1-4eb2290dac15 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000" \
  --location uksouth --mi-system-assigned

Quick quiz

Question 1 of 5

Defender for Cloud shows 'System updates should be installed' and 'Guest Configuration extension should be installed' across several machines. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure assesses and installs updates and audits in-guest configuration across the settings in this capability.

You can now treat Azure patching as one capability rather than a scatter of findings: inventory which machines are even being assessed, onboard the whole fleet to Azure Update Manager and deploy the configuration extension so every host is visible, install missing updates highest-risk first into proper maintenance windows, and ratchet the estate shut with Azure Policy so nothing can quietly fall behind. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Patching Azure machines: the cost and risk view

A near-zero-cost capability that removes the largest class of preventable Azure compromise

Unpatched machines are the most common entry point in cloud compromises, and the controls in this group cost almost nothing in Azure spend to fix. Azure Update Manager assessment and patching is included at no extra charge for supported Azure and Arc-enabled VMs under Defender for Servers Plan 2, and the Guest Configuration extension itself is free. The cost sits entirely in two narrow places: the Defender for Servers plan you are likely already paying for, and the engineering and maintenance-window time to schedule reboots for the patches that need them.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A public-facing web server missing a critical remote-code-execution patch carries a far higher expected loss than an isolated batch host two updates behind, yet both surface as a single red finding. Map the failures to the exposure behind them, internet reachability and the severity of what is missing, and prioritise by risk, not by recommendation count.

The insurance arithmetic is one-sided. The remediation is engineering time plus scheduled maintenance windows. The downside of leaving it is the documented cost of a breach through an unpatched host: ransomware, regulatory fines, breach notification, forensics, legal fees and reputational damage, almost always traced back to a vulnerability that had a patch available.

This lesson is for the finance partner who sees a cluster of patch and configuration findings on the security report and wants to know what the right response is and what it costs. It covers why most of these controls are free to fix under a plan you likely already pay for, where the real cost sits (maintenance-window time, not Azure spend), and how to turn a list of red findings into a risk-ordered remediation plan.

Fun fact

The patch that shipped before the breach

How a finance partner frames the patching decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with twenty-two patch findings spread across two dozen machines in two older subscriptions, plus a set of machines missing the configuration agent entirely. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Azure Update Manager assessment and patching is already covered by the Defender for Servers Plan 2 the team holds, and the Guest Configuration extension is free, so the spend question is narrow: there is essentially no incremental Azure cost, only engineering time and the maintenance windows needed to reboot the machines whose patches require it.

Sam asks the team to map each failing machine to its exposure. Three are internet-facing production hosts missing critical updates, several are internal services a couple of patches behind, and a dozen are non-production machines that were simply never put on periodic assessment. The list is reframed on the risk register: the three internet-facing hosts are high expected-loss items to schedule into the next maintenance window today at no Azure cost, the internal services are a routine catch-up, and the non-production fleet is low-value drift to onboard in bulk. The finance pack reads: 'Every finding closes at no incremental Azure spend; the only real cost is engineering time and a few scheduled reboots; the thing standing between us and a clean posture is a maintenance window, not budget.'

Why unpatched machines belong on the risk register

The cost model here is asymmetric in a way that is rare for security work. Keeping machines patched costs nothing in incremental Azure spend for the great majority of the fleet, because assessment and patching are included with the Defender for Servers plan you are likely already paying for, and the configuration extension is free. Leaving machines unpatched creates an unbounded tail risk. Each failing recommendation is a host where a future scan could find an exploitable flaw, and while the probability per machine per event is low, the probability across the whole fleet over years is not.

The documented cost of a breach through an unpatched host includes ransomware recovery, mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and customer churn. Against that, the remediation is engineering time plus scheduled maintenance windows for the reboots. The finance role is to attach expected loss to each failing machine, weighting by internet exposure and patch severity, so the work is prioritised by risk, not by the order the report lists it.

What finance can do about the patching gap

Finance cannot install a patch, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with no incremental Azure spend and a clearly bounded set of maintenance windows. Three levers.

1. Separate the zero-cost closures from the real cost: maintenance time

Make explicit that patching findings cost nothing in incremental Azure spend to fix: assessment and patching are included with the Defender for Servers plan you already hold, and the configuration extension is free. The only real cost is engineering time and the maintenance windows needed to reboot the machines whose patches require it. Budget those as scheduled effort, not as Azure spend, so nobody can claim the whole capability is a new spending decision.

2. Order the work by expected loss, not by finding count

An internet-facing production host missing a critical remote-code-execution patch and an isolated batch host two minor updates behind both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to weight each failing machine by internet exposure and the severity of what is missing, and patch the high-exposure hosts first. The metric that belongs on the cost-and-security review is the count of findings weighted by exposure and severity, not the raw total.

3. Require documented exceptions for machines that cannot auto-patch

A small number of machines genuinely cannot take automatic patching, a legacy host with a fragile application or a strict change-control window, and those should carry a recorded, finance-visible reason and a defined manual cadence instead. The distinction between 'we reviewed this and patch it on a controlled manual schedule' and 'we never noticed it was unassessed' is exactly what makes the posture defensible at audit and in the aftermath of any incident.

Quick quiz

Question 1 of 5

A security report shows twenty-two patch findings plus several machines missing the configuration agent. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure assesses and installs updates and audits in-guest configuration across the settings in this capability.

You have finished the finance view of keeping machines patched. You know the cost model is one-sided: closing these findings carries no incremental Azure spend because assessment and patching come with a plan you already hold, the only real cost is engineering time and maintenance windows, and the downside of leaving machines unpatched is the documented and unbounded cost of a breach. Next time a cluster of patch findings lands, you will order them by exposure and severity, ring-fence the hosts that cannot auto-patch as documented exceptions, and ask for a maintenance window rather than asking how much remediation will cost.

Back to the library

Patching Azure machines: the headline

Whether any machine in the estate is running known-vulnerable code, or is invisible enough that you cannot tell

Patching is the category of risk that turns a published vulnerability into an incident. A machine missing a critical update is one scan away from being exploited, and a machine without the configuration agent is one you cannot even assess, so the report shows this as a scatter of separate findings across the estate.

The leadership question is not 'are we fully patched today?' It is 'when the next critical vulnerability is published, will every machine install it on a schedule, and can we prove which ones have?' The defensible end state is that every machine reports its update state to Azure Update Manager, patches are assessed and installed automatically, and every machine carries the agent that lets you audit it.

None of this is a meaningful cost decision. Patching machines is essentially free in Azure terms under a plan you likely already hold. It is a governance decision about whether falling behind on patches is prevented by design or only by everyone remembering to run the updates.

A short read for the leader who needs to know what an unpatched or unmonitored machine reveals, why keeping the estate patched is a governance decision rather than a budget one, and what a defensible end state looks like across the fleet.

Fun fact

The patch that shipped before the breach

What it looks like when patching is prevented from slipping by design, not luck

After a peer company was hit by ransomware that got in through a server missing a patch that had been available for months, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on whether anyone had remembered to run the updates, because patching across the estate was governed by habit rather than policy, and several machines were not even being assessed.

The team's response was to stop treating patching as a per-machine cleanup and start treating it as a guardrail. They listed every machine that was not on periodic assessment, onboarded the whole fleet to Azure Update Manager, installed the missing updates highest-risk first, deployed the Guest Configuration extension so every machine could be audited, and then set Azure Policy to enable periodic assessment and automatic patching on any new machine by default. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, every machine assesses itself daily and patches on a schedule, and we can show you which ones installed the last critical update.' That shift, from relying on everyone remembering to run the updates to making falling behind structurally hard, is the one-line confidence signal this capability delivers, and it costs essentially nothing in Azure spend to reach.

Why this is a board-level risk

Nearly every major ransomware and intrusion event that ran through cloud or hybrid machines came back to the same root cause: a host running code with a known, patchable vulnerability that nobody had installed. Keeping the fleet patched is the capability that makes that root cause structurally difficult, and an Azure Policy backstop that enables automatic assessment and patching on every machine makes it close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time and maintenance windows under a plan you likely already hold. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on patching

The executive handle is not to approve each patch individually; it is to require that falling behind on patches is prevented by policy and that every machine is both assessed and auditable, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the fleet is inventoried, every machine is on periodic assessment with the configuration extension deployed, the missing updates are installed, and Azure Policy enables automatic assessment and patching on any new machine by default. A backstop that no individual machine can fall outside is the difference between checking nothing is unpatched today and guaranteeing nothing can quietly fall behind tomorrow.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we are on it.' It is a passing set of system-update and configuration-extension recommendations across every subscription plus evidence that the assessment and configuration policies are assigned. Because Defender for Cloud assesses on a periodic cycle and Update Manager assesses daily, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

3. Treat the machines that cannot auto-patch as named, owned exceptions

A small number of hosts cannot take automatic patching because of fragile applications or strict change control, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner and a defined manual patch cadence, not a host left silently unassessed. The goal is not zero exceptions; it is zero machines that are behind by accident.

Quick quiz

Question 1 of 5

At a board review you ask whether a ransomware incident like a competitor's, which got in through an unpatched server, could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure assesses and installs updates and audits in-guest configuration across the settings in this capability.

Two takeaways. Patching is the rare control where the risk of inaction is severe and the cost of action is essentially engineering time under a plan you likely already hold, so it is the trade you should be quickest to approve. And the defensible end state is not 'we checked and nothing is unpatched today'; it is Azure Policy that enables periodic assessment and automatic patching on every machine and deploys the audit agent, making falling behind structurally hard, with the few hosts that cannot auto-patch documented and owned on a manual cadence.

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.

Azure Kubernetes Service

Upgrade Azure Kubernetes Service to remove vulnerabilities from AKS system pods (Preview) High Out-of-date AKS-managed system pods carry known CVEs that an attacker can exploit until the cluster is upgraded.

Compute

Virtual Machines

Part of the learning path Manage Azure posture and patching

Keep Azure machines patched

Patching Azure machines: the basics

The patch that shipped before the breach

Finding unpatched and unmonitored machines across a subscription

How Defender for Cloud decides a machine is unpatched or unmonitoreddeep dive

What is the impact of leaving machines unpatched?

How do you keep machines patched safely?

1. Inventory every machine by assessment state

2. Bring every machine into Azure Update Manager

3. Install missing updates, highest risk first

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Patching Azure machines: the cost and risk view

The patch that shipped before the breach

How a finance partner frames the patching decision

Why unpatched machines belong on the risk register

What finance can do about the patching gap

1. Separate the zero-cost closures from the real cost: maintenance time

2. Order the work by expected loss, not by finding count

3. Require documented exceptions for machines that cannot auto-patch

Quick quiz

Keep learning

Patching Azure machines: the headline

The patch that shipped before the breach

What it looks like when patching is prevented from slipping by design, not luck

Why this is a board-level risk

The leadership move on patching

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat the machines that cannot auto-patch as named, owned exceptions

Quick quiz

Keep learning

Controls this lesson covers

Azure Kubernetes Service

Compute

Virtual Machines

Related compliance lessons