Security Center High Severity Alerts Disabled: Why Your Azure Threat Alerts Need Notifications

Microsoft Defender for Cloud watches your Azure subscriptions for threats, generates alerts when it spots something suspicious, and ranks each one by severity. That whole pipeline only works if a human actually sees the alert. The Security Center High Severity Alerts Disabled check catches the gap between detection and response: a security contact that exists but never receives notifications for the alerts that matter most.

---

What this check detects

Defender for Cloud lets you register one or more security contacts per subscription. A security contact is an email address (and optionally a phone number) that Azure uses to send security notifications. Each contact has a toggle that controls whether it receives notifications for alerts at or above a chosen severity level.

This check (securitycenter_nohighseverityalerts) inspects your security contact configuration and fails when notifications for high severity alerts are not enabled. In practice that means one of two things:

• A security contact exists, but its alert notification setting is turned off entirely.
• The notification minimum severity is set higher than "High" (which is not possible in the standard tiers, but legacy or partial configs can leave the toggle disabled).

---

Why it matters

An alert nobody reads is the same as no alert at all. Defender for Cloud can flag a compromised VM within minutes, but if that signal lands only in a portal blade that your team checks once a week, the attacker has a multi-day head start.

Consider a realistic scenario. An exposed management port on a Linux VM gets brute forced overnight. Defender for Cloud raises a high severity alert: "Successful RDP brute force attack." If high severity notifications were enabled, the on-call engineer gets an email at 2am and can isolate the host before the attacker pivots. If notifications are disabled, the alert sits quietly in the portal until someone happens to log in. By then the credentials have been used to enumerate storage accounts, exfiltrate data, and spin up mining workloads on your dime.

The business impact stacks up fast:

• Slower mean time to respond. Without push notifications, your response window depends on how often someone manually checks the console.
• Compliance gaps. Frameworks like CIS Azure Foundations, ISO 27001, and SOC 2 expect documented alerting on security events. A disabled notification is a clean audit finding.
• Cost exposure. Cryptomining and resource abuse can run up large bills before anyone notices.

---

How to fix it

You can enable high severity alert notifications in the portal, via the Azure CLI, or with 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.
3. Choose Email notifications from the left menu.
4. Under Notification types, check Notify about alerts with the following severity (or higher) and set it to High.
5. Add at least one email address under All users with the following roles or in the Additional email addresses field.
6. Click Save.

Option 2: Azure CLI

The security contact configuration lives in the az security contact command group. Create or update a contact with high severity alerts enabled:

az security contact create \
  --name "default" \
  --email "[email protected]" \
  --phone "+15555550100" \
  --alert-notifications "On" \
  --alerts-admins "On"

The --alert-notifications "On" flag is the key setting. It enables email notifications for high severity alerts. The --alerts-admins "On" flag additionally notifies all subscription owners.

Verify the result:

az security contact list --output table

Option 3: Terraform

If you manage Azure with Terraform, use the azurerm_security_center_contact resource:

resource "azurerm_security_center_contact" "secops" {
  name  = "default"
  email = "[email protected]"
  phone = "+15555550100"

  alert_notifications = true
  alerts_to_admins    = true
}

For the newer per-subscription notifications resource, use azurerm_security_center_subscription_pricing alongside the contact, and ensure the minimal severity is set to High:

resource "azurerm_security_center_contact" "secops" {
  name                = "default"
  email               = "[email protected]"
  alert_notifications = true
  alerts_to_admins    = true
}

---

How to prevent it from happening again

Manually fixing one subscription does not stop the next one from drifting. Bake the control into your platform so every subscription gets it by default.

Azure Policy

Microsoft ships built-in policies that audit and enforce this exact setting. Assign these to your management group so they apply to every subscription, including new ones:

• Subscriptions should have a contact email address for security issues
• Email notification for high severity alerts should be enabled
• Email notification to subscription owner for high severity alerts should be enabled

Assign the policy with the CLI:

az policy assignment create \
  --name "require-high-sev-alert-email" \
  --display-name "Email notification for high severity alerts should be enabled" \
  --policy "6e2593d9-add6-4083-9c9b-4b7d2188c899" \
  --scope "/providers/Microsoft.Management/managementGroups/your-mg-id"

These are audit policies by default. They will not auto-remediate, but they surface non-compliant subscriptions in the Defender for Cloud compliance dashboard so you can catch drift before an auditor does.

CI/CD gate

If subscriptions are provisioned through Terraform or Bicep in a pipeline, treat the security contact as a required module. Add a check in your pipeline that fails the build if the contact configuration is missing:

# Fail if no security contact has alert notifications enabled
contacts=$(az security contact list --query "[?alertNotifications=='On'] | length(@)")
if [ "$contacts" -eq 0 ]; then
  echo "No security contact with high severity alerts enabled. Failing pipeline."
  exit 1
fi

---

Best practices

• Enable notifications at every subscription, not just production. Dev and staging subscriptions get attacked too, often because they have weaker controls. An exposed test VM is still a foothold into your tenant.
• Use a monitored distribution list, not a personal inbox. People change roles and leave companies. Point the contact at a team alias that survives staff turnover.
• Set the minimum severity to High, then revisit. Start with high severity so you avoid alert fatigue, then add medium severity routing for teams that can absorb the volume.
• Connect Defender for Cloud to your SIEM. Stream alerts to Microsoft Sentinel or your existing SIEM so they are correlated, retained, and searchable alongside everything else.
• Test the path end to end. Trigger a sample alert and confirm it actually reaches the right person. Configuration that looks correct in the portal is worthless if the email bounces or gets filtered.
• Review contacts quarterly. Make security contact verification part of your access review cadence so stale addresses get caught.

Enabling high severity alert notifications takes about two minutes and closes one of the most common gaps between detection and response in Azure. The hard part is keeping it enabled across every subscription as your estate grows, which is exactly where policy enforcement and continuous monitoring earn their keep.