Compliance

Put Azure Key Vault behind a private network

One capability across every vault in the estate: make sure the store that holds your secrets, keys and certificates is not reachable from the public internet, and that the only paths to it are a private endpoint or a tightly scoped firewall, unless you genuinely intend otherwise.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-keyvault-firewall-enabled azure-keyvault-private-link

Key Vault network hardening: the basics

What does a publicly reachable Key Vault actually look like?

Key Vault is the most concentrated trust object in an Azure subscription: it holds the secrets, keys and certificates that unlock everything else. By default a vault has a public endpoint that answers from anywhere on the internet, and the protection sitting in front of it shows up as two distinct shapes rather than one setting. The first is network access control: the vault firewall can be left open so its 'networkAcls.defaultAction' is Allow and any address can reach the data plane, instead of Deny with a private endpoint or a known set of addresses. The second is whether the public endpoint exists at all: 'publicNetworkAccess' can be left Enabled when the workload only ever needs private connectivity. Each is its own Defender for Cloud recommendation, but the underlying risk is the same: the store of your secrets is reachable by more of the internet than you meant.

Microsoft Defender for Cloud turns each of these into its own recommendation, which is why one secret-heavy subscription can fail several Key Vault network checks at once. 'Azure Key Vaults should use private link' wants every vault fronted by a private endpoint so traffic never leaves the Microsoft backbone, and 'Azure Key Vault should have firewall enabled or public network access disabled' wants the public door either firewalled down to allowed sources or closed entirely. They read as separate problems on the report, but they are one job: take the vault off the open internet and put the only paths to it under your control.

Most of this exposure is drift, not intent. A vault created from a quickstart that never set a firewall, a module that left 'publicNetworkAccess' on its Enabled default, a 'defaultAction' of Allow that a quick test needed and nobody tightened again. The work is to find every vault that is reachable more widely than intended, decide which handful genuinely need a controlled public path, route the rest through a private endpoint, and switch the public endpoint to Deny or Disabled so the secret store stops answering the open internet.

In this lesson you will learn how Azure Key Vault expresses public reachability through its firewall and public-network-access settings, how to find every over-exposed vault in a subscription, and how to lock them down with a private endpoint without breaking the services that legitimately read from them. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The vault is the skeleton key

In real-world cloud breaches the secret store is rarely the first thing an attacker touches, but it is almost always the thing they want. A leaked deployment token or an over-permissive identity is the way in; the vault is the prize, because one reachable vault can hand over the credentials for databases, storage and partner integrations in a single read. That is why network hardening matters even when access policies look tight: a vault that still answers the public internet leaves the door reachable for any credential that leaks later. Putting the vault behind a private endpoint means a stolen secret is not enough on its own, because the attacker also has to be inside your network to use it.

Finding exposed vaults across a subscription

Priya is the security lead at a fintech preparing for a SOC 2 Type II audit. Defender for Cloud shows Key Vault network findings spread across nine vaults in three subscriptions that pre-date the team's current platform guardrails.

Rather than work the findings one by one, Priya starts by listing which vaults still have an open firewall and which still expose a public endpoint, so the vaults that genuinely need a controlled public path can be separated from drift before anything changes.

Start by listing every vault with its firewall default action and whether its public endpoint is still on. Allow plus Enabled is the widest-open shape.

$ az keyvault list --query "[].{name:name, default:properties.networkAcls.defaultAction, public:properties.publicNetworkAccess}" -o table

Name Default Public

---------------- --------- --------

kv-payments-prod Allow Enabled

kv-shared-build Deny Enabled

# kv-payments-prod has an open firewall AND a live public endpoint. Close it first.

A production vault whose firewall defaults to Allow and whose public endpoint is still Enabled is the highest-value target in this group. Fix these first.

How Defender for Cloud decides a vault is exposeddeep dive

The Key Vault network recommendations resolve to two related properties on the vault. The first is the network rule set, 'properties.networkAcls': when its 'defaultAction' is Allow, the public endpoint answers from any network rather than only from the IP ranges and virtual-network subnets you list. Set it to Deny, add the sources that need in, and optionally set 'bypass' to AzureServices so trusted first-party services can still reach the vault. The second is 'properties.publicNetworkAccess': when it is Enabled, a public endpoint exists at all; set it to Disabled and the vault answers only over a private endpoint, regardless of any firewall rule. The 'Azure Key Vault should have firewall enabled or public network access disabled' recommendation passes when either of those doors is shut, and 'Azure Key Vaults should use private link' passes when an approved private endpoint connection exists.

It is worth being precise about how these two settings interact, because it is a common source of confusion. 'publicNetworkAccess' takes precedence over the firewall: if it is Disabled, the vault ignores the network ACL rules entirely and is reachable only through private endpoints. If it is Enabled, the public endpoint exists and the 'defaultAction' decides who that endpoint answers. The strongest posture for a vault that does not need any public reachability is private endpoint plus 'publicNetworkAccess' Disabled; for a vault that genuinely needs a scoped public path it is 'defaultAction' Deny with an explicit allow list and 'bypass' set to AzureServices. Note that disabling public access does not remove the vault's public DNS record, which stays resolvable by design; the data-plane connection is what is blocked.

Defender for Cloud evaluates these against the Microsoft Cloud Security Benchmark, where both recommendations sit under control NS-2, on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly. The control-plane change itself is immediate, but the posture catches up on the next assessment. The strongest position pairs the per-vault setting with an Azure Policy backstop: the built-in 'Azure Key Vaults should use private link' definition and the firewall-or-public-access definition can be assigned in audit or deny mode so no new vault can be created on the open internet again. Turning those on is the difference between checking that nothing is exposed today and guaranteeing that nothing can be exposed tomorrow.

What is the impact of leaving a vault on the open internet?

The direct impact is the worst kind of data exposure, because the data in a vault is the credentials for other data. A vault reachable on an open public endpoint is one leaked token, one over-permissive identity or one stolen access policy away from handing an attacker the connection strings, signing keys and certificates it holds. Network access policy is not the only line of defence, but it is the one that decides whether a credential that leaks elsewhere can be used at all: a stolen secret is far less dangerous when the vault that issued it answers only inside your network. The majority of these exposures were accidents, a firewall left at its Allow default or a public endpoint a module never closed.

The second-order impact is blast radius and recovery cost. A compromised vault does not just leak its own contents; it forces rotation of every secret, key and certificate it held, across every service that trusted them, which is a slow and error-prone scramble under incident pressure. Putting vaults behind a private endpoint shrinks the attack surface to the network you already defend, so a leaked credential has to be paired with network access before it is worth anything.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA, PCI DSS and the UK and EU data-protection regimes, expects evidence that key material is held in a hardware-backed store with controlled access, and a vault answering the open internet undercuts that story regardless of how tight the access policies look. A passing set of Key Vault network recommendations across every subscription, backed by private link, is one of the cheapest and most defensible artefacts you can hand an auditor.

How do you put a vault behind a private network safely?

Work the capability as one loop rather than chasing individual findings. The order matters: stand up the private endpoint and confirm services can still reach the vault through it before you close the public door, so you do not lock out a live workload.

1. Inventory every vault by exposure

List the vaults whose firewall default action is Allow, whose public network access is still Enabled, and which have no private endpoint connection. Treat this inventory as the source of truth, not the Defender finding count, because one vault can trigger several recommendations at once.

2. Separate vaults that need a public path from drift

Most exposure is unintended. For each vault, decide whether anything genuinely needs to reach it from outside your virtual networks, such as a hosted CI runner or a SaaS integration on a fixed address range. Those become firewalled exceptions scoped to the smallest allow list possible. Everything else is drift and can move fully private.

3. Stand up the private endpoint, then close the public door

Create a private endpoint with group id 'vault' in the subnet your services use, link the 'privatelink.vaultcore.azure.net' private DNS zone to the virtual network so the vault name resolves to the private IP, and confirm a dependent service can still read a secret. Only then set the firewall default action to Deny, set bypass to AzureServices for trusted first-party callers, and for vaults that need no public path at all set public network access to Disabled. Each change is a single command per vault and takes effect immediately.

4. Ratchet it shut with Azure Policy

Assign the built-in 'Azure Key Vaults should use private link' definition and the firewall-or-public-access definition in audit, then deny, so no new vault can be created on the open internet again. This makes the safe configuration enforced rather than merely encouraged, and turns the next over-exposed vault into a deployment that simply will not provision.

# 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"

Quick quiz

Question 1 of 5

Defender for Cloud shows Key Vault findings across private link, firewall and public network access on several vaults. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure Key Vault expresses network reachability and how private link, the firewall and public network access fit together.

You can now treat Key Vault network hardening as one capability rather than a scatter of findings: inventory which vaults are reachable too widely, separate the few that genuinely need a public path and firewall them down, move the rest onto a private endpoint and close the public door, and ratchet the estate shut with Azure Policy. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Key Vault network hardening: the cost and risk view

A near-zero-cost capability that removes the most concentrated breach liability in the estate

A vault is the highest-leverage object an attacker can reach: one exposed secret store can hand over the keys to databases, storage and downstream services. Almost every control in this group costs nothing in Azure spend to fix. Setting the vault firewall to Deny, adding allowed sources, or disabling public network access does not change your bill. The cost sits entirely in the private-link path: each private endpoint carries a small hourly charge plus data-processing pennies, and you need the virtual network and private DNS zone to land it in, which most estates that run vaults privately already have.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A production vault holding the connection strings for a customer database, reachable on an open public endpoint, carries a far higher expected loss than an empty vault a developer span up to test a deployment, yet both surface as a single red finding. Map the failures to the secrets behind them and prioritise by blast radius, not by recommendation count.

The insurance arithmetic is one-sided. The remediation is engineering time plus a small, bounded per-endpoint charge for the vaults you move onto private link. The downside of leaving it is the documented cost of a credential breach that starts at the vault: regulatory fines, breach notification, forensics, mandatory secret rotation across everything the vault unlocked, legal fees and reputational damage.

This lesson is for the finance partner who sees a cluster of Key Vault findings on the security report and wants to know what the right response is and what it costs. It covers why most of these controls are free to fix, why the private-endpoint path carries only a small bounded charge, and how to turn a list of red findings into a risk-ordered plan led by the vaults that hold the most dangerous secrets.

Fun fact

The vault is the skeleton key

How a finance partner frames the Key Vault decision

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with fourteen Key Vault network findings spread across nine vaults in three older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Setting a vault firewall to Deny or disabling its public endpoint changes nothing on the Azure bill, so the spend question is narrow: only the private-endpoint path carries a real cost, and that is a few pounds a month per endpoint plus fractions of a penny per gigabyte of data processed, landed in virtual networks the team already runs.

Priya asks the team to map each failing vault to the secrets sitting behind it. Two vaults hold the connection strings and signing keys for the payments platform, one is a shared build vault that genuinely needs reachability from a hosted CI runner, and the rest are empty or developer scratch vaults with a firewall simply never set. The list is reframed on the risk register: the two payments vaults are high blast-radius items to put on private link and close to the public internet this sprint, the shared build vault is a documented exception that keeps a firewalled public path scoped to the runner's address range, and the scratch vaults are low-value drift to sweep up at no incremental spend. The finance pack reads: 'Twelve findings close at no meaningful spend; two production vaults move onto private link for a few pounds a month each; the only thing standing between us and a clean posture is engineering time, not budget.'

Why an exposed vault belongs at the top of the risk register

The cost model here is asymmetric in a way that is rare even for security work, because of what a vault concentrates. Putting vaults behind a private network costs nothing in Azure spend for the firewall and public-access settings and only a few pounds a month per private endpoint, and leaving a vault open creates a tail risk whose worst case is a full estate compromise. Each failing recommendation is a vault where a future accident could expose not one dataset but the keys to many, and while the probability per event is low, the consequence is the highest in the estate.

The documented cost of a credential breach that starts at the vault includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and the operational cost of rotating every secret the vault held across every dependent service. Against that, the remediation is engineering time plus a small, bounded per-endpoint charge for the vaults that move onto private link. The finance role is to attach expected loss to each failing vault, weighted by what its secrets unlock, so the work is prioritised by blast radius, not by the order the report lists it.

What finance can do about the vault gap

Finance cannot create a private endpoint, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with almost no incremental Azure spend and a clearly bounded set of exceptions. Three levers.

1. Separate the zero-cost closures from the small private-link charge

Make explicit that most Key Vault network findings cost nothing in Azure spend to fix: setting the firewall to Deny or disabling public network access does not move the bill. The only real cost sits in the private-endpoint path, a few pounds a month per endpoint plus fractions of a penny per gigabyte processed, landed in virtual networks the team already runs. Budget those endpoints as discrete lines and treat everything else as engineering time, so nobody can claim the whole capability is a spending decision.

2. Order the work by blast radius, not by finding count

A production vault holding the payments platform's signing keys and an empty developer scratch vault both show up as a single red finding, but a breach of the first is a different category of event from a breach of the second. Ask the team to map each failing vault to what its secrets unlock and prioritise the high-blast-radius vaults first. The metric that belongs on the cost-and-security review is the count of Key Vault findings weighted by the sensitivity of what each vault holds, not the raw total.

3. Require documented exceptions for any public path

Any vault left reachable from outside the virtual networks on purpose, the shared build vault a hosted runner needs, a SaaS integration on a fixed address range, should carry a recorded, finance-visible reason and the scoped allow list it sits behind. The distinction between 'we reviewed this and firewalled it down to one address range deliberately' and 'we never noticed the public endpoint was open' is exactly what makes the posture defensible at audit and in the aftermath of any breach.

Quick quiz

Question 1 of 5

A security report shows fourteen Key Vault network findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure Key Vault expresses network reachability and how private link, the firewall and public network access fit together.

You have finished the finance view of putting vaults behind a private network. You know the cost model is one-sided: closing the great majority of findings is free in Azure spend, only the private-endpoint path carries a small bounded charge, and the downside of leaving a vault open is the documented and outsized cost of a credential breach that forces rotation across everything the vault unlocked. Next time a cluster of Key Vault findings lands, you will order them by blast radius, ring-fence the real exceptions, and ask for them on the record rather than asking how much remediation will cost.

Back to the library

Key Vault network hardening: the headline

Whether the store that holds the keys to the estate is reachable from the internet by accident

A vault is where the estate keeps the credentials that unlock everything else, so a vault on the open internet is the single point at which a configuration mistake becomes a full compromise. A vault whose firewall is open, or whose public endpoint was never closed, is one stolen credential or one leaked token away from handing over far more than itself, and the report shows this as a scatter of separate findings across the estate.

The leadership question is not 'are we compliant today?' It is 'if the keys to one vault leak tomorrow, can someone on the internet walk straight up to it?' The defensible end state is that vaults answer only over a private endpoint, the public path is closed or firewalled to known sources, and the small number of vaults that genuinely need a controlled public route are documented exceptions.

None of this is a meaningful cost decision. Putting vaults behind a private network is essentially free, give or take a few pounds a month per private endpoint. It is a governance decision about whether the most sensitive object in the estate is protected by design or only by everyone remembering not to leave the door open.

A short read for the leader who needs to know why a vault on the open internet is the most concentrated risk in the estate, why putting it behind a private network is a governance decision rather than a budget one, and what a defensible end state looks like across every subscription.

Fun fact

The vault is the skeleton key

What it looks like when the vault is protected by design, not luck

After a peer firm disclosed that an attacker had pivoted from a leaked CI token straight into an internet-facing secret store and pulled every production credential at once, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on whether anyone had remembered to firewall each vault, because the network posture of vaults across the estate was governed by habit rather than policy.

The team's response was to stop treating Key Vault as a per-vault cleanup and start treating it as a guardrail. They listed every vault with an open firewall or a live public endpoint, moved the production vaults onto a private endpoint, scoped the one vault that genuinely needed a public path down to a single runner address range, disabled public network access on the rest, and then set an Azure Policy that audits for private link and denies the creation of any new vault that leaves the public endpoint wide open. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, the vaults answer only inside our network, and the one exception is documented and scoped.' That shift, from relying on everyone remembering to firewall a vault to making an open vault structurally hard, is the one-line confidence signal this capability delivers, and it costs almost nothing in Azure spend to reach.

Why this is a board-level risk

Many of the most damaging cloud breaches did not end at the first system the attacker touched; they ended at a secret store that handed over the credentials for everything else. A vault on the open internet is the object that turns a contained incident into a full compromise. Putting vaults behind a private network is the capability that breaks that chain, and an Azure Policy backstop makes leaving a vault open close to impossible.

The cost of getting this wrong is among the largest in the estate and well documented, while the cost of fixing it is essentially engineering time plus a rounding-error charge per private endpoint. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on Key Vault

The executive handle is not to approve each private endpoint individually; it is to require that vaults answer only over a private network by default and that the small number of vaults needing a public path are firewalled and documented, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, the production vaults are on private link with the public endpoint closed, the genuine exceptions are firewalled to known sources, and Azure Policy audits for private link and denies the creation of any new vault on the open internet. A backstop that no individual vault can override is the difference between checking nothing is exposed today and guaranteeing nothing can be exposed tomorrow.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we are on it.' It is a passing set of Key Vault network recommendations across every subscription plus evidence that the private-link and firewall policies are assigned. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

3. Treat the vaults with a public path as named, owned exceptions

A small number of vaults need a controlled public route, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner and a firewall scoped to the smallest possible allow list, not an accident left open. The goal is not zero public paths; it is zero unintended ones.

Quick quiz

Question 1 of 5

At a board review you ask whether a credential breach that pivots into a secret store, like a competitor's, could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure Key Vault expresses network reachability and how private link, the firewall and public network access fit together.

Two takeaways. A vault on the open internet is the most concentrated risk in the estate, because it holds the keys to everything else, and yet the cost of fixing it is essentially engineering time plus a rounding-error charge per private endpoint, so it is the trade you should be quickest to approve. And the defensible end state is not 'we checked and every vault was firewalled today'; it is private link plus an Azure Policy backstop that denies new open vaults, making accidental exposure structurally hard, with the few deliberate public paths documented and owned.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Key Vault

Part of the learning path Close Azure network exposure

Put Azure Key Vault behind a private network

Key Vault network hardening: the basics

The vault is the skeleton key

Finding exposed vaults across a subscription

How Defender for Cloud decides a vault is exposeddeep dive

What is the impact of leaving a vault on the open internet?

How do you put a vault behind a private network safely?

1. Inventory every vault by exposure

2. Separate vaults that need a public path from drift

3. Stand up the private endpoint, then close the public door

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Key Vault network hardening: the cost and risk view

The vault is the skeleton key

How a finance partner frames the Key Vault decision

Why an exposed vault belongs at the top of the risk register

What finance can do about the vault gap

1. Separate the zero-cost closures from the small private-link charge

2. Order the work by blast radius, not by finding count

3. Require documented exceptions for any public path

Quick quiz

Keep learning

Key Vault network hardening: the headline

The vault is the skeleton key

What it looks like when the vault is protected by design, not luck

Why this is a board-level risk

The leadership move on Key Vault

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat the vaults with a public path as named, owned exceptions

Quick quiz

Keep learning

Controls this lesson covers

Key Vault

Related compliance lessons