Security Center Admin Alerts Disabled: Wiring Defender for Cloud to Page Your Team

Microsoft Defender for Cloud spends a lot of effort detecting threats across your Azure subscriptions: brute-force attempts against VMs, suspicious sign-ins, crypto-mining behavior, and resource hijacking, among others. But detection only helps if someone is told. This check looks at whether your Defender for Cloud security contact has alert notifications turned on. If it does not, the alerts pile up silently in the portal while nobody is watching.

It is one of those settings that looks fine until the day you need it. A misconfiguration here turns Defender for Cloud from an early-warning system into an audit log you read after the breach.

---

What this check detects

The securitycenter_noadminalerts check inspects the notification configuration of your Defender for Cloud security contact. Specifically, it verifies that the contact is configured to receive email notifications for security alerts, including those flagged at the highest severity.

In Azure, a security contact is the email address (and optional phone number) that Defender for Cloud uses to send security and threat notifications. Each subscription can define contacts and set:

• Whether alert notifications are sent at all, and the minimum severity threshold (Low, Medium, or High)
• Whether the subscription's Owner and other privileged roles also get notified automatically

This check fails when alert notifications are effectively disabled, meaning Defender raises alerts but no email goes out to the people who need to act on them.

---

Why it matters

Detection without notification is a gap that attackers benefit from directly. Consider a typical scenario:

1. An attacker brute-forces an exposed RDP or SSH port on a VM and succeeds.
2. Defender for Cloud raises a "Successful brute force attack" alert with high severity.
3. Nobody receives an email. The alert sits in the portal.
4. The attacker installs a crypto-miner or pivots to other resources over the next several hours.
5. The team finds out when the bill spikes or a customer reports an outage.

The detection worked. The response never started. That gap between "the platform knows" and "a human knows" is where most of the damage happens.

There is a compliance angle too. Frameworks like CIS Microsoft Azure Foundations Benchmark, SOC 2, and ISO 27001 expect that security events generate timely notifications to responsible parties. An auditor who sees alerting disabled will treat it as a finding, regardless of how good your detection coverage looks on paper.

---

How to fix it

You can fix this through the Azure portal, the CLI, or infrastructure as code. Pick whichever fits your workflow, but standardize on one so the setting stays consistent across subscriptions.

Option 1: Azure portal

1. Open the Azure portal and go to Microsoft Defender for Cloud.
2. In the left menu, select Environment settings.
3. Choose the subscription you want to configure.
4. Select Email notifications.
5. Under Notification types, enable Notify about alerts with the following severity (or higher) and set it to High at minimum.
6. Add recipient email addresses, and optionally enable notifications to subscription Owners and other privileged roles.
7. Click Save.

Option 2: Azure CLI

Set the security contact with alert notifications enabled and a minimal severity of High:

az security contact create \
  --name default \
  --emails "[email protected];[email protected]" \
  --alert-notifications "{state:On,minimalSeverity:High}" \
  --notifications-by-role "{state:On,roles:[Owner,Contributor]}"

To inspect the current setting first:

az security contact list --output json

Option 3: REST API

az rest --method put \
  --uri "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Security/securityContacts/default?api-version=2020-01-01-preview" \
  --body '{
    "properties": {
      "emails": "[email protected];[email protected]",
      "notificationsByRole": { "state": "On", "roles": ["Owner"] },
      "alertNotifications": { "state": "On", "minimalSeverity": "High" }
    }
  }'

Option 4: Terraform

resource "azurerm_security_center_contact" "main" {
  name  = "default"
  email = "[email protected]"
  phone = "+1-555-0100"

  alert_notifications = true
  alerts_to_admins    = true
}

---

How to prevent it from happening again

Fixing one subscription is easy. Keeping every subscription configured as your estate grows is the real work. Bake the setting into policy and pipelines so drift gets caught automatically.

Azure Policy

Microsoft ships a built-in policy that audits this exact condition: "Subscriptions should have a contact email address for security issues" and related Defender for Cloud notification policies. Assign them at the management group level so new subscriptions inherit the check.

az policy assignment create \
  --name "require-security-contact-alerts" \
  --scope "/providers/Microsoft.Management/managementGroups/{mgId}" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/4f4f78b8-e367-4b10-a341-d9a4ad5cf1c7"

CI/CD gate for Terraform

If you provision subscriptions with IaC, fail the pipeline when the security contact resource is missing or has alerts disabled. A simple Open Policy Agent check against the Terraform plan works well:

package terraform.security

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "azurerm_security_center_contact"
  resource.change.after.alert_notifications == false
  msg := "Security contact must have alert_notifications enabled"
}

---

Best practices

• Set the minimum severity to High, not higher. High is the floor for "wake someone up" events. You can add Medium for teams that triage during business hours, but High alerts should always notify.
• Use multiple recipients. A single point of contact is a single point of failure. List at least two addresses, ideally a shared inbox plus an on-call alias.
• Connect Defender to your incident pipeline. Email is the baseline. For real response speed, export alerts to Microsoft Sentinel or stream them to your SIEM and route to PagerDuty, Opsgenie, or Slack via the Defender for Cloud connector.
• Enable role-based notifications. Notifying Owners means accountability stays with the people who can actually authorize remediation.
• Test it. Generate a sample alert and confirm the email arrives. An untested alerting path is a hope, not a control.
• Apply at scale. Configure contacts at the management group level through policy so every subscription is covered by default rather than one at a time.

Detection answers "did something bad happen." Notification answers "does anyone know." Both have to be true for the control to mean anything.

Turning on admin alert notifications takes a few minutes and removes one of the quietest, most dangerous gaps in an Azure security posture. Fix it once, enforce it with policy, and verify it on a schedule.