Azure Key Vault should have firewall enabled or public network access disabled

What does the recommendation "Azure Key Vault should have firewall enabled or public network access disabled" check?

Flags any key vault whose network exposure is wide open: either 'publicNetworkAccess' is Enabled with the firewall left at its default, or 'networkAcls.defaultAction' is still set to Allow, meaning any client on the internet can reach the vault's data plane and attempt to read secrets, keys and certificates. It passes when the firewall is restricting traffic ('defaultAction' is Deny) or when public network access is Disabled entirely. It checks the network reachability of the vault, not whether the access policies or Azure RBAC assignments granting permissions to callers are themselves correct.

Why does "Azure Key Vault should have firewall enabled or public network access disabled" matter?

A vault reachable from anywhere turns one leaked credential or token into a direct path to your most sensitive material: database passwords, signing keys, TLS certificates. With the firewall open, an attacker who obtains a valid identity can pull those secrets from any network, and there is no second perimeter to slow them down or generate suspicious-source telemetry. Restricting the vault to known networks or private endpoints means a stolen credential is far less useful from an unexpected location, and it shrinks the surface that internet-wide scanners and brute-force tooling can even touch.

How do I fix "Azure Key Vault should have firewall enabled or public network access disabled"?

1. Decide the reachability model first. If callers are all inside Azure or your VNets, set 'publicNetworkAccess' to Disabled and use a private endpoint: az keyvault update --name <vault> --resource-group <rg> --public-network-access Disabled. If some trusted public IPs still need access, keep public access on but lock the firewall down in the next step.
2. Switch the firewall to deny-by-default and add only the networks you trust: az keyvault update --name <vault> --resource-group <rg> --default-action Deny, then az keyvault network-rule add for each allowed VNet subnet or IP range. Leave 'bypass' at AzureServices so trusted Microsoft services can still reach the vault. Add your own admin IP before flipping defaultAction to Deny, or you will lock yourself out.
3. Bake the setting into infrastructure as code so new vaults are never born open. In Bicep, set 'properties.networkAcls.defaultAction' to 'Deny' and 'properties.publicNetworkAccess' to 'Disabled' on the Microsoft.KeyVault/vaults resource, and pair it with a private endpoint module.

# Put a production vault behind a private endpoint, then close its public door.
VAULT=kv-payments-prod
RG=rg-payments
SUBNET=/subscriptions/<sub>/resourceGroups/rg-net/providers/Microsoft.Network/virtualNetworks/vnet-prod/subnets/snet-data

# 1. Create the private endpoint (group-id 'vault') in the workload subnet.
az network private-endpoint create \
  --name pe-$VAULT --resource-group $RG \
  --vnet-name vnet-prod --subnet snet-data \
  --private-connection-resource-id $(az keyvault show -n $VAULT --query id -o tsv) \
  --group-id vault --connection-name conn-$VAULT

# 2. Link the private DNS zone so the vault name resolves to the private IP.
#    (privatelink.vaultcore.azure.net linked to vnet-prod, A record from the PE)

# 3. Once a dependent service can still read a secret over the PE, close the door.
az keyvault update --name $VAULT --resource-group $RG \
  --default-action Deny --bypass AzureServices \
  --public-network-access Disabled
echo "$VAULT: private endpoint live, firewall Deny, public network access disabled"

# Ratchet it shut: audit every vault for private link across the subscription.
az policy assignment create \
  --name audit-kv-private-link \
  --policy a6abeaec-4d90-4a02-805f-6b26c4d3fbe9 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"