Defender for Key Vault Not Enabled: Why It Matters and How to Fix It

Key Vault is where a lot of your most sensitive material lives: database connection strings, TLS certificates, encryption keys, API tokens, and service principal secrets. If an attacker gets a foothold and starts pulling secrets out of a vault, you want to know about it before the damage spreads. That is exactly what Microsoft Defender for Key Vault provides, and this Lensix check tells you when that protection is missing.

The defender_keyvault check inspects the Microsoft Defender for Cloud plan configuration on your Azure subscription and reports a failure when the Key Vaults plan is set to Free (off) rather than Standard (on).

---

What this check detects

Microsoft Defender for Cloud sells its threat protection as a set of per-resource-type plans. One of those plans covers Key Vault. When the plan is disabled, Azure still runs your vaults, but it does not analyze access telemetry for malicious behavior and it generates no security alerts for vault activity.

Lensix checks the subscription-level pricing configuration and confirms whether the KeyVaults plan is enabled. If it returns Free tier, the check fails. The scope is the subscription, so a single misconfiguration affects every Key Vault inside it.

---

Why it matters

A Key Vault is a high-value target. Compromise one and you often get the keys to everything else. Defender for Key Vault watches for the access patterns that precede or accompany a breach, including:

• Access from a suspicious IP address or a known malicious actor
• Access from a Tor exit node or anomalous geography
• An unusual volume of secret or key operations in a short window, which can indicate bulk exfiltration
• Access by a user or application that has never touched the vault before
• A spike in denied operations, which can signal enumeration or brute force

Consider a realistic scenario. A service principal secret leaks through a misconfigured CI pipeline log. An attacker uses it to authenticate and starts listing and reading every secret in the vault. With Defender for Key Vault off, that activity produces no alert. The first sign you get is when the stolen credentials are used against your databases or external APIs, by which point the incident is already well underway.

With the plan enabled, that burst of SecretGet calls from an unfamiliar identity surfaces as a high-severity alert in Defender for Cloud, and you can route it to your SIEM or on-call channel within minutes.

---

How to fix it

You can enable the plan through the portal, the Azure CLI, PowerShell, or infrastructure as code. Pick whichever fits your workflow.

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 protect.
3. On the Defender plans page, find the Key Vaults row.
4. Toggle the plan to On.
5. Click Save.

Option 2: Azure CLI

This is the fastest way to fix it across one subscription. Set your active subscription first, then update the pricing tier for the KeyVaults resource type.

# Point the CLI at the right subscription
az account set --subscription "<subscription-id>"

# Enable the Defender for Key Vault plan
az security pricing create \
  --name KeyVaults \
  --tier Standard

# Confirm the change
az security pricing show --name KeyVaults --query "pricingTier" -o tsv

A return value of Standard means the plan is now active.

Option 3: PowerShell

Set-AzSecurityPricing -Name "KeyVaults" -PricingTier "Standard"

Get-AzSecurityPricing -Name "KeyVaults" | Select-Object Name, PricingTier

Option 4: Terraform

If you manage Azure with Terraform, the azurerm_security_center_subscription_pricing resource keeps the setting in your state and prevents drift.

resource "azurerm_security_center_subscription_pricing" "key_vault" {
  tier          = "Standard"
  resource_type = "KeyVaults"
}

---

How to prevent it from happening again

Enabling the plan manually fixes today's subscription. It does nothing for the subscription a colleague spins up next week. Policy-as-code closes that gap.

Use Azure Policy with DeployIfNotExists

Microsoft ships a built-in policy that enables Defender for Cloud plans automatically. Assign it at the management group level so every current and future subscription is covered. The built-in initiative Microsoft Defender for Cloud Deployment includes the relevant policies, or you can assign a single plan policy.

# Assign the built-in policy that configures Defender for Key Vault
az policy assignment create \
  --name "enable-defender-keyvault" \
  --display-name "Enable Defender for Key Vault" \
  --scope "/providers/Microsoft.Management/managementGroups/<mg-id>" \
  --policy "1f725891-01c0-420a-9059-4fa46cb770b7" \
  --location "eastus" \
  --mi-system-assigned \
  --role "Owner"

Add a CI/CD gate

If your subscriptions are provisioned through Terraform or Bicep, treat the Defender plan as a required resource and break the build when it is absent. A simple checkov or terraform plan review step catches a removed plan before it merges. You can also run a post-deploy verification:

# Fail the pipeline if Key Vault protection is not Standard
tier=$(az security pricing show --name KeyVaults --query "pricingTier" -o tsv)
if [ "$tier" != "Standard" ]; then
  echo "Defender for Key Vault is not enabled. Failing."
  exit 1
fi

Let Lensix watch for drift

Even with policy in place, someone with the right permissions can disable a plan to cut costs or during an incident. Continuous monitoring catches that. Lensix re-runs the defender_keyvault check on every scan, so a regression shows up as a fresh finding rather than waiting for an annual audit.

---

Best practices

• Enable Defender plans at the management group level, not per subscription. This makes the secure state the default and removes the chance of forgetting a new subscription.
• Route Defender for Key Vault alerts to your SIEM. An alert nobody reads is not protection. Use continuous export to push alerts into Microsoft Sentinel, Splunk, or your tool of choice.
• Pair detection with least privilege. Use Key Vault RBAC (not legacy access policies) and grant the narrowest roles possible. Defender tells you when something goes wrong; tight access control reduces how often it can.
• Enable diagnostic logging on every vault. Send AuditEvent logs to a Log Analytics workspace. This gives you the forensic trail to investigate an alert, and it supports the analytics Defender relies on.
• Turn on purge protection and soft delete. These do not stop an attacker reading secrets, but they prevent destructive deletion of keys and vaults, which is a common follow-on action.
• Rotate anything that touches a vault. If an alert fires, assume the credential that triggered it is compromised and rotate it immediately.

Defender for Key Vault is one of the lowest-effort, highest-value protections you can turn on in Azure. It is a configuration setting, not a project. Enable it through policy, wire the alerts into your existing response workflow, and let Lensix confirm it stays on.