Security Center Auto-Provisioning Disabled in Microsoft Defender for Cloud

Defender for Cloud is only as useful as the data it collects. When auto-provisioning is disabled, Azure stops automatically installing the monitoring agent on your virtual machines. That sounds like a minor toggle, but the downstream effect is real: machines spin up, run workloads, and never report a single security signal back to Defender. Your dashboard looks clean because half your fleet is invisible.

This Lensix check, securitycenter_autoprovisioning, looks at the auto-provisioning setting for the Log Analytics monitoring agent on each subscription and raises a finding when it is set to Off.

---

What this check detects

Microsoft Defender for Cloud (formerly Azure Security Center) relies on agents and extensions running on your compute resources to gather telemetry. The classic agent is the Log Analytics agent (also called the Microsoft Monitoring Agent, or MMA), which feeds data into a Log Analytics workspace where Defender analyzes it for threats, missing patches, and misconfigurations.

Auto-provisioning controls whether Azure installs that agent for you when a new VM is created. The check inspects the auto-provisioning policy at the subscription level and reports a failure when the setting equals Off rather than On.

---

Why it matters

The gap created by disabled auto-provisioning is quiet and easy to miss, which is exactly what makes it dangerous. Consider what you lose when a VM has no monitoring agent:

• No threat detection on the host. Defender cannot alert on suspicious process execution, brute-force RDP/SSH attempts, or known malware behavior if it never sees the host's activity.
• No vulnerability and patch insight. Missing system updates and misconfigured OS settings go unreported, so a server can drift months behind on critical patches with no one the wiser.
• Blind spots in your secure score. Defender's recommendations and secure score are computed from collected data. Unmonitored machines skew your score upward and give a false sense of safety.
• Compliance failures. CIS Azure Foundations Benchmark, PCI DSS, and most internal standards expect continuous monitoring across all hosts. An auditor who finds unmonitored production VMs will write you up.

Here is a realistic scenario. Your platform team disables auto-provisioning months ago to avoid an agent conflict during a migration, then forgets to re-enable it. Over the next quarter, the team scales out a workload and forty new VMs join the subscription. An attacker compromises one of those VMs through an exposed management port and starts lateral movement. Defender for Cloud raises nothing, because none of those forty machines ever installed an agent. The first sign of trouble is a billing anomaly or a ransom note.

---

How to fix it

You can re-enable auto-provisioning through the Azure portal, the CLI, or infrastructure as code. Pick the path that fits how you manage your subscriptions.

Option 1: Azure portal

1. Open Microsoft Defender for Cloud in the Azure portal.
2. Go to Environment settings and select the subscription you want to fix.
3. Select Settings & monitoring (older portals call this Auto provisioning).
4. Find Log Analytics agent / Azure Monitor Agent and switch it to On.
5. Choose the target workspace (the default Defender workspace or your own), then click Apply and Save.

Option 2: Azure CLI

The classic Log Analytics auto-provisioning setting can be toggled with the security command group:

# Confirm current state across the subscription
az security auto-provisioning-setting show --name default

# Enable auto-provisioning of the monitoring agent
az security auto-provisioning-setting update \
  --name default \
  --auto-provision On

Verify the change took effect:

az security auto-provisioning-setting show \
  --name default \
  --query autoProvision -o tsv
# expected output: On

Option 3: Migrate to the Azure Monitor Agent (recommended long term)

Since the Log Analytics agent is being deprecated, the durable fix is to enable the Azure Monitor Agent and Defender's agentless scanning where supported. AMA is provisioned through Defender plan settings and data collection rules rather than the legacy auto-provisioning toggle. Enable the relevant Defender plans (for example Defender for Servers Plan 2) and confirm AMA provisioning is on in Settings & monitoring.

Option 4: Terraform

If you provision subscriptions with Terraform, codify the setting so it never drifts:

resource "azurerm_security_center_auto_provisioning" "this" {
  auto_provision = "On"
}

---

How to prevent it from happening again

Fixing the toggle once does not stop someone from flipping it back next quarter. Bake the correct state into policy and pipeline.

Azure Policy

Use the built-in policy definitions that deploy and enforce monitoring agents. Assign them at the management group level so every subscription inherits the requirement:

• Configure Log Analytics agent / Azure Monitor Agent auto-provisioning (deployIfNotExists)
• Auto provisioning of the Log Analytics agent should be enabled on your subscription (audit)

Assigning the audit policy alongside a deployIfNotExists policy gives you both visibility and remediation. The audit version surfaces non-compliant subscriptions in the Policy compliance blade, while the deployIfNotExists version creates remediation tasks to fix them.

Policy as code in CI/CD

If your Terraform or Bicep defines subscription settings, add a check in your pipeline that fails the build when auto-provisioning is anything but On. A simple guard with Open Policy Agent's Conftest against a Terraform plan works well:

# Generate a plan and convert to JSON
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json

# Evaluate against your policy
conftest test tfplan.json --policy ./policy

Your Rego rule denies any plan that sets auto_provision to Off, so the misconfiguration can never reach production.

---

Best practices

• Enable across every subscription, not just production. Dev and test subscriptions are common entry points for attackers and frequently host stale, unpatched VMs. Monitor them too.
• Centralize your Log Analytics workspaces. Send agent data to a small number of well-governed workspaces rather than letting each subscription spin up its own. This simplifies retention, access control, and cross-resource queries.
• Plan your AMA migration now. The Log Analytics agent reaches end of support, so build your data collection rules and move to the Azure Monitor Agent before the deadline forces a rushed cutover.
• Turn on the Defender plans that match your workloads. Auto-provisioning gives you the agent, but detections require the relevant Defender for Cloud plans (Servers, SQL, Storage, and so on) to be enabled.
• Review data collection scope. Tune what the agent collects so you capture security-relevant events without ingesting noise that inflates cost.
• Track secure score over time. A sudden jump in secure score with no remediation work often means machines stopped reporting, not that things got safer.

Auto-provisioning is one of those settings that is invisible when it works and catastrophic when it silently fails. Turn it on, enforce it with policy, and let continuous monitoring confirm it stays that way.