No Security Contact Configured in Microsoft Defender for Cloud

Microsoft Defender for Cloud watches your Azure subscriptions for suspicious activity, misconfigurations, and active attacks. When it spots something serious, like a brute-force attempt against a VM or anomalous activity in a storage account, it raises an alert. But an alert is only useful if someone sees it. The No Security Contact Configured check flags subscriptions where Defender for Cloud has no security contact email set, which is the difference between catching an intrusion in real time and reading about it in a breach report weeks later.

---

What this check detects

The securitycenter_nocontact check inspects the Defender for Cloud security contact settings on each Azure subscription. It fails when no security contact email address is configured to receive notifications.

In Azure, a security contact is the mailbox (or set of mailboxes) that Defender for Cloud uses to send alert emails. You can also configure whether subscription owners and admins get notified and which alert severity levels trigger an email. When this configuration is empty, Defender keeps generating alerts in the portal, but nobody is pinged. The alerts pile up silently.

---

Why it matters

Detection without notification is not detection. It is logging. The whole point of a threat detection product is to shorten the time between compromise and response, and a missing security contact reopens that gap.

Consider a realistic scenario. An attacker obtains leaked credentials for a service principal and starts enumerating resources in your subscription. Defender for Cloud notices the unusual access pattern and raises a high-severity alert. With a security contact configured, your on-call engineer gets an email within minutes and can disable the principal before lateral movement begins. Without one, that alert sits in the portal until someone happens to log in and scroll through the security dashboard, which on a busy team might be days.

The business impact is straightforward:

• Longer dwell time. The longer an attacker operates undetected, the more data they exfiltrate and the more systems they touch.
• Missed brute-force and exploit attempts. Defender flags things like SQL injection attempts, suspicious RDP/SSH logins, and crypto-mining activity. These are time-sensitive.
• Compliance gaps. Frameworks like CIS Microsoft Azure Foundations Benchmark, ISO 27001, and SOC 2 expect documented alerting and incident response paths. A missing contact is an audit finding.
• Wasted spend. If you pay for Defender for Cloud plans, you are paying for detection you are not acting on.

This is one of those low-effort, high-leverage fixes. It takes a few minutes to set and pays off the first time something fires.

---

How to fix it

You need to set a security contact email and turn on alert notifications. Do this for every subscription, since the setting is scoped per subscription.

Option 1: Azure Portal

1. Go to Microsoft Defender for Cloud in the Azure portal.
2. Open Environment settings from the left menu.
3. Select the subscription you want to configure.
4. Click Email notifications.
5. Enter one or more email addresses under Additional email addresses. Use a distribution list or shared mailbox, not a single person.
6. Under Notification types, enable email notifications for alerts and set the minimum severity to at least High (Medium if your team has the capacity).
7. Optionally enable Notify all users with the following roles and select Owner.
8. Click Save.

Option 2: Azure CLI

The CLI lets you script this across many subscriptions. First, set the contact:

az security contact create \
  --name "default" \
  --emails "[email protected]" \
  --notifications-by-role Owner \
  --notifications-sources '[{"sourceType":"Alert","minimalSeverity":"High"}]'

To verify it took effect:

az security contact list --output table

Option 3: REST API

For automation pipelines that do not have the Azure CLI extension installed, call the API directly:

SUB_ID="00000000-0000-0000-0000-000000000000"
TOKEN=$(az account get-access-token --query accessToken -o tsv)

curl -X PUT \
  "https://management.azure.com/subscriptions/${SUB_ID}/providers/Microsoft.Security/securityContacts/default?api-version=2020-01-01-preview" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "properties": {
      "emails": "[email protected]",
      "notificationsByRole": {
        "state": "On",
        "roles": ["Owner"]
      },
      "alertNotifications": {
        "state": "On",
        "minimalSeverity": "High"
      }
    }
  }'

Option 4: Terraform

If you manage Azure with Terraform, declare the contact as code so it survives subscription rebuilds:

resource "azurerm_security_center_contact" "main" {
  name  = "default"
  email = "[email protected]"

  alert_notifications = true
  alerts_to_admins    = true
}

---

How to prevent it from happening again

Setting the contact once is fine until someone spins up a new subscription. Make the configuration the default state, not a manual step.

Azure Policy

Azure ships built-in policy definitions to flag subscriptions missing a security contact. Assign this one at the management group level so it covers existing and future subscriptions:

# Built-in: "Subscriptions should have a contact email address for security issues"
az policy assignment create \
  --name "require-security-contact" \
  --display-name "Require security contact email" \
  --scope "/providers/Microsoft.Management/managementGroups/your-mg-id" \
  --policy "4f4f78b8-e367-4b10-a341-d9a4ad5cf1c7"

This policy audits rather than enforces, since you cannot auto-populate an email address that only a human knows. Pair it with a notification so the gap gets closed quickly.

Subscription vending and landing zones

If you use the Azure landing zone model or a subscription vending pipeline, bake the security contact into the deployment template. Every new subscription should arrive with Defender for Cloud configured and a contact set before any workload lands. The Terraform resource above belongs in your baseline module.

CI/CD gate

Add a check to your infrastructure pipeline that fails the build if the security contact is empty. A small script in your deploy stage works:

CONTACTS=$(az security contact list --query "length([?properties.emails != null])" -o tsv)
if [ "$CONTACTS" -eq 0 ]; then
  echo "ERROR: No security contact configured for this subscription."
  exit 1
fi

---

Best practices

• Use a monitored mailbox or integration. Route alerts into a system humans actually watch. An unread inbox is no better than an unread portal.
• Set severity to High at minimum. Start with High to avoid alert fatigue, then drop to Medium once your triage process handles the volume.
• Configure contacts per subscription, consistently. Defender settings are subscription-scoped. A contact on one subscription does nothing for the others.
• Enable role-based notifications too. Notifying subscription Owners adds a backstop if the shared mailbox integration breaks.
• Wire alerts into an incident response flow. A notification that does not create a ticket or page someone tends to get ignored. Connect Defender alerts to your SOAR or on-call tooling.
• Review the contact regularly. Confirm the email still routes correctly during periodic security reviews. Mailboxes get deprecated, integrations break.
• Pair detection with a Defender plan. The free tier covers foundational recommendations, but the paid Defender plans generate the threat alerts that make a security contact worth having.

This check costs you a few minutes to resolve and removes a real blind spot. Set the contact, enforce it with policy, and let your alerting do what you are paying it to do.