Event Grid Domain Has Public Access: Why It Matters and How to Fix It

Event Grid is one of those services that quietly sits in the middle of a lot of Azure architectures. It fans out events from publishers to subscribers, and a domain is the management construct that lets you group thousands of topics under a single endpoint with shared access policies. Because it handles a high volume of event traffic across many tenants or applications, the network posture of that endpoint matters more than people usually assume.

This Lensix check, eventgrid_publicaccess, looks for one specific condition: an Event Grid domain with publicNetworkAccess set to Enabled. When that flag is on, the domain endpoint resolves to a public IP and accepts inbound connections from anywhere, subject only to access key or AAD validation.

---

What this check detects

Every Event Grid domain has a network access property. There are two relevant settings:

• publicNetworkAccess: Enabled — the domain is reachable over the public internet. This is the default when you create a domain without specifying otherwise.
• publicNetworkAccess: Disabled — the domain only accepts traffic through Private Endpoints inside your virtual network.

The check fails when the value is Enabled. It does not care whether you have an IP firewall configured on top of that, though a tight IP allowlist meaningfully reduces the risk. The point is that a publicly reachable domain endpoint is exposed to the entire internet by default, and most teams never tighten it.

---

Why it matters

Public network access on its own is not an automatic breach. Event Grid still requires a valid access key or Azure AD token to publish events. But "still requires auth" has never been a great place to stop your security analysis, and here is why.

Event injection and downstream trust

Event Grid subscribers often trust the events they receive implicitly. A function triggered by an Event Grid event may write to a database, kick off a workflow, or call another API. If an attacker obtains a domain key, perhaps from a leaked config file, a compromised CI runner, or an over-shared secret, a public endpoint means they can publish forged events from anywhere with no network friction. Those events flow straight into your trusted downstream systems.

Keys leak more often than you think

Access keys end up in places they should not: application settings committed to source control, log output, browser local storage, infrastructure templates. When the endpoint is private, a leaked key is far less useful because the attacker also needs network access into your VNet. When the endpoint is public, a leaked key is enough.

Reconnaissance and surface area

A publicly resolvable endpoint shows up in DNS and certificate transparency logs, contributing to the footprint attackers map before an attack. Reducing the number of internet-facing endpoints is a direct, measurable reduction in attack surface, which is exactly the kind of thing your auditors and your CISO want to see.

---

How to fix it

You have two main paths depending on whether your event publishers live inside Azure or need to reach the domain from elsewhere.

Option 1: Disable public access and use Private Endpoints (recommended)

This is the strongest posture. The domain becomes unreachable from the public internet, and all traffic flows through a Private Endpoint attached to your virtual network.

First, find the domains with public access still enabled:

az eventgrid domain list \
  --query "[?publicNetworkAccess=='Enabled'].{name:name, rg:resourceGroup}" \
  --output table

Create a Private Endpoint for the domain:

# Get the domain resource ID
DOMAIN_ID=$(az eventgrid domain show \
  --name my-domain \
  --resource-group my-rg \
  --query id --output tsv)

# Create the private endpoint into your subnet
az network private-endpoint create \
  --name my-domain-pe \
  --resource-group my-rg \
  --vnet-name my-vnet \
  --subnet my-subnet \
  --private-connection-resource-id "$DOMAIN_ID" \
  --group-id domain \
  --connection-name my-domain-connection

Then turn off public network access:

az eventgrid domain update \
  --name my-domain \
  --resource-group my-rg \
  --public-network-access disabled

Do not forget the private DNS zone, otherwise your publishers will resolve the public name and fail. Link privatelink.eventgrid.azure.net to your VNet so the domain hostname resolves to the private IP:

az network private-dns zone create \
  --resource-group my-rg \
  --name "privatelink.eventgrid.azure.net"

az network private-dns link vnet create \
  --resource-group my-rg \
  --zone-name "privatelink.eventgrid.azure.net" \
  --name eventgrid-dns-link \
  --virtual-network my-vnet \
  --registration-enabled false

Option 2: Keep public access but lock down the IP firewall

If you have publishers that genuinely cannot use a Private Endpoint, such as a SaaS platform or an on-prem system without ExpressRoute, restrict inbound traffic to known IP ranges instead of leaving it open.

az eventgrid domain update \
  --name my-domain \
  --resource-group my-rg \
  --public-network-access enabled \
  --inbound-ip-rules 203.0.113.10/32 allow \
  --inbound-ip-rules 198.51.100.0/24 allow

Terraform example

If you manage Event Grid as code, set the access property explicitly so it never drifts back to the default:

resource "azurerm_eventgrid_domain" "this" {
  name                          = "my-domain"
  location                      = azurerm_resource_group.this.location
  resource_group_name           = azurerm_resource_group.this.name
  public_network_access_enabled = false

  # If you must keep public access, scope it:
  # public_network_access_enabled = true
  # inbound_ip_rule {
  #   ip_mask = "203.0.113.10"
  #   action  = "Allow"
  # }
}

---

How to prevent it from happening again

Fixing the domains you have today is the easy part. Stopping new ones from launching with public access takes a guardrail.

Azure Policy

Use a custom policy with a deny effect that blocks any Event Grid domain where public network access is enabled. This stops the misconfiguration at deployment time across every subscription in the assignment scope.

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.EventGrid/domains"
      },
      {
        "field": "Microsoft.EventGrid/domains/publicNetworkAccess",
        "equals": "Enabled"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Assign it at the management group level so it applies to subscriptions you have not even created yet:

az policy assignment create \
  --name deny-eventgrid-public \
  --policy "/providers/Microsoft.Management/managementGroups/my-mg/providers/Microsoft.Authorization/policyDefinitions/deny-eventgrid-public-access" \
  --scope "/providers/Microsoft.Management/managementGroups/my-mg"

CI/CD gates

Catch it before it reaches Azure at all. Run a static check on your Terraform or Bicep in the pipeline. With Checkov, for example, the relevant rule fails any plan that leaves public access on. Add it as a required check on merges to main so nobody can ship a public domain without an explicit override and a reviewer signing off.

---

Best practices

• Default to private. Treat public network access as something you justify, not something you inherit. Most Event Grid traffic in a well-architected Azure environment stays inside the network.
• Prefer Azure AD over keys. Use managed identities and role-based access control for publishing where you can, so you are not relying on long-lived SAS keys that leak.
• Rotate keys on a schedule. If you do use access keys, rotate them regularly and immediately after any suspected exposure. Event Grid gives you two keys precisely so you can rotate without downtime.
• Scope publisher permissions. Grant the EventGrid Data Sender role at the narrowest scope that works, rather than handing out broad contributor access.
• Log and monitor. Enable diagnostic settings on the domain and send delivery and publish metrics to Log Analytics. Unexpected spikes in publish volume are an early signal of abuse.
• Audit continuously. Network settings drift. A domain that was private last quarter can be flipped back during an incident or by a well-meaning script. Continuous scanning catches that drift before an auditor does.

Public access on an Event Grid domain is a small flag with an outsized blast radius. Flip it off where you can, fence it tightly where you cannot, and put a policy in front of it so the question never comes up again.