Azure Security Contact Has No Phone Number: Why It Matters and How to Fix It

Defender for Cloud is constantly scanning your Azure subscriptions for suspicious activity: brute-force attempts against a VM, a storage account suddenly being accessed from an anonymizing network, a Kubernetes API server being probed. When it spots something serious, it sends an alert. The question is whether anyone sees that alert in time.

Security contacts are how Defender for Cloud knows who to reach. Email is the default, but phone numbers matter for the alerts that cannot wait until someone checks their inbox the next morning. This check, securitycenter_nophone, fires when a security contact exists but has no phone number attached.

---

What this check detects

The check inspects the security contact configuration on your Azure subscription and reports any contact entry that has notification settings but a blank phone field. In Defender for Cloud, a security contact holds:

• One or more email addresses for alert notifications
• A phone number for high-severity alerts
• Notification rules that control which alert severities trigger a contact and whether subscription owners get notified

When the phone number is empty, Defender for Cloud still sends email, but it loses the ability to reach you through a faster channel during a real incident.

---

Why it matters

Most cloud breaches are not loud at the moment they begin. They are quiet, and the window between initial compromise and real damage can be short. The difference between catching an attacker during lateral movement and finding out after they have exfiltrated a database often comes down to how fast the first responder reacts.

Email alone has a few weak spots:

• Inbox noise. Security alerts compete with hundreds of other messages, and high-severity Defender alerts can get buried or filtered.
• Off-hours gaps. An alert that lands at 2 a.m. may sit unread until the morning. Attackers know this and time activity accordingly.
• Single channel failure. If a mailbox is misconfigured, full, or the alias points to someone who left the company, the alert effectively vanishes.

A phone number gives Defender for Cloud a second, harder-to-ignore channel for the alerts that matter most. Consider a scenario: Defender detects a successful brute-force login against an internet-facing VM, followed by a suspicious download. With email only, this might wait in a shared mailbox over a weekend. With a phone contact, the on-call engineer gets a call and can isolate the VM before the attacker pivots to your internal network.

There is also a compliance angle. Frameworks like the Azure Security Benchmark and CIS Microsoft Azure Foundations Benchmark expect security contact details, including a phone number, to be set. An empty phone field shows up as a finding in audits and lowers your secure score.

---

How to fix it

You can set the phone number through the Azure portal, the REST API, or infrastructure as code. Pick whichever matches how you manage the rest of your environment.

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 in the settings menu.
5. Under Notification types, enter a phone number in the Phone number field, including the country code.
6. Confirm an email address is also set and that you have selected the alert severities that should trigger notifications.
7. Click Save.

Option 2: REST API

Security contacts are managed through the Microsoft.Security/securityContacts resource. There is no direct az security contact command for setting the phone in current CLI versions, so the REST API is the reliable scriptable path. Use the Azure CLI to call it:

First, read the current contact so you do not lose existing settings:

SUBSCRIPTION_ID=$(az account show --query id -o tsv)

az rest \
  --method get \
  --uri "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/providers/Microsoft.Security/securityContacts/default?api-version=2020-01-01-preview"

Then write back the full configuration with the phone number added:

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

Option 3: Terraform

If you manage Defender for Cloud with Terraform, the azurerm_security_center_contact resource handles this:

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

  alert_notifications = true
  alerts_to_admins    = true
}

---

How to prevent it from happening again

Fixing one subscription by hand is fine. Keeping it fixed across dozens of subscriptions, as people spin up new ones, requires automation.

Enforce with Azure Policy

Azure ships built-in policies for security contact configuration. Assign them at the management group level so every current and future subscription inherits them:

• 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

These run in AuditIfNotExists mode, so they flag non-compliant subscriptions on your compliance dashboard. Combine them with a deployment template that provisions the full contact, phone included, whenever a new subscription is created.

Gate it in CI/CD

If subscriptions and their Defender settings are provisioned through pipelines, treat the security contact as a required input. A simple pre-deploy check can reject any plan where the phone field is empty:

# Fail the pipeline if the Terraform plan leaves phone unset
PHONE=$(jq -r '.resource_changes[]
  | select(.type == "azurerm_security_center_contact")
  | .change.after.phone' tfplan.json)

if [ -z "$PHONE" ] || [ "$PHONE" == "null" ]; then
  echo "ERROR: security center contact has no phone number set"
  exit 1
fi

Continuously monitor with Lensix

Policy assignments tell you the state at audit time, but configurations drift. Lensix runs the securitycenter_nophone check on a schedule across all your connected Azure subscriptions and surfaces any contact that loses its phone number, so a manual change or a Terraform override does not quietly leave you exposed.

---

Best practices

A phone number is one piece of a working notification setup. To make the whole thing reliable:

• Set both email and phone. They are complementary channels, not alternatives. Email gives you detail and a paper trail, phone gives you speed.
• Use distribution lists and routed numbers. Avoid tying alerts to a single person. A team alias and a paging line both outlast individual staff.
• Tune the minimum severity. Set high-severity notifications to reach the phone, and let lower-severity alerts flow to email or your SIEM so you do not train people to ignore calls.
• Notify subscription owners. Enable owner notifications so the accountable party is in the loop, not just the security team.
• Test the path. Trigger a sample alert or simulate one during an incident response drill. A contact you never test is a contact you cannot trust.
• Apply it everywhere. Every subscription needs its own contact. A perfectly configured production subscription does not help if the sandbox where an attacker gained a foothold has no contact at all.

Alerting is only as good as its last successful delivery. The most expensive detection capability in the world is worthless if the page never reaches a person who can act on it.

Adding a phone number takes a minute. It is one of the cheapest improvements you can make to your incident response readiness, and it closes a gap that shows up in nearly every Azure security audit.