Compliance

Harden Azure Cosmos DB

One capability across every Cosmos DB API: make sure no database account is reachable from the public internet, by routing access through a private endpoint and shutting public network access off, unless you genuinely intend a store to be public.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-cosmos-private-link azure-cosmos-public-network-access-disabled

Hardening Cosmos DB: the basics

What does a publicly reachable Cosmos DB account actually look like?

An Azure Cosmos DB account is one of the most data-dense objects in a subscription, and its exposure shows up as network reachability rather than a single switch. By default a new account is reachable from any network: its endpoint resolves on public DNS and accepts connections from the whole internet, with access gated only by keys or tokens. There are two distinct ways to close that door, and Defender for Cloud raises each as its own recommendation. The first is whether the account is mapped to an Azure Private Link private endpoint, so a virtual network can reach it over a private IP. The second is whether the account's 'publicNetworkAccess' property is set to Disabled, so the public route is shut even before, or independently of, any private endpoint.

These two read as separate findings, 'Cosmos DB accounts should use private link' and 'Azure Cosmos DB should disable public network access', but they are one job. A private endpoint gives you a private path in; disabling public network access removes the public path entirely. You want both, because a private endpoint alone does not close the public route. As Microsoft's own documentation notes, once approved private endpoints are removed or rejected, an account is open to the entire network again unless 'publicNetworkAccess' is set to Disabled. The two recommendations are the front and back of the same lock.

Most of this exposure is drift, not intent. An account created before private endpoints were wired into the landing zone, a module that never set 'publicNetworkAccess', a quick proof of concept that was left reachable because restricting it needed a virtual network nobody had time to build. The work is to find every account reachable from the public internet, decide which handful are genuinely meant to be, give the rest a private endpoint, and then disable public network access so the public route cannot reopen by accident.

In this lesson you will learn how Azure Cosmos DB expresses public reachability, why a private endpoint and disabling public network access are two halves of the same lock, how to find every publicly reachable account in a subscription, and how to lock them down without cutting off the applications that depend on 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 database that answered the whole internet

A recurring pattern in cloud data exposures is a database that was reachable from the public internet with access resting on a single key or token, found by an automated scanner long before the owner noticed. Cosmos DB endpoints resolve on public DNS by default, which is exactly why Microsoft built two separate guards: a private endpoint to give the database a private path in, and a 'publicNetworkAccess' flag to shut the public path entirely. The detail that catches teams out is that the two are independent. Remove the last private endpoint and an account reopens to the whole network unless public network access was explicitly disabled. Belt and braces is the design, not an overreaction.

Finding publicly reachable Cosmos DB accounts

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows Cosmos DB findings across several accounts in two subscriptions that pre-date the team's private-endpoint guardrails.

Rather than work the findings one by one, Sam starts by listing which accounts still have public network access enabled, so the genuinely public stores can be separated from drift before anything changes.

List every Cosmos DB account with its public-network-access state. 'Enabled' means the account answers the public internet.

$ az cosmosdb list --query "[].{name:name, rg:resourceGroup, publicAccess:publicNetworkAccess}" -o table

Name Rg PublicAccess

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

custprofiles-prod data-prod Enabled

sessions-prod data-prod Disabled

scratch-dev sandbox Enabled

# custprofiles-prod holds customer data AND answers the public internet. Close it first.

An account that holds real data and still has public network access enabled is the highest-value target in this group. Fix these first, after giving each a private path in.

How Defender for Cloud decides a Cosmos DB account is exposeddeep dive

Both recommendations in this capability resolve to network reachability, evaluated on the account's properties. 'Cosmos DB accounts should use private link' checks whether the account has an approved private endpoint connection mapping it into a virtual network over a private IP. 'Azure Cosmos DB should disable public network access' checks the 'publicNetworkAccess' property: when it is Enabled, the account's endpoint accepts connections from the public internet subject only to any IP or virtual-network firewall rules, and when it is Disabled, the public route is shut entirely.

The interaction between the two matters and is easy to get wrong. Adding a private endpoint does not, on its own, disable the public route. Microsoft's documentation is explicit that if no public-traffic or service-endpoint firewall rules are configured, an account is reachable only through its private endpoints, but the moment all approved private endpoints are rejected or deleted the account is open to the entire network again, unless 'publicNetworkAccess' is set to Disabled. Setting that flag takes precedence over any IP or virtual-network rule: all public and virtual-network traffic is blocked when it is Disabled, even if a source address is allowed in the firewall. That is why the two recommendations pair: the private endpoint provides the way in, and disabling public network access removes the way the public can still get in.

Defender for Cloud evaluates these against the Microsoft Cloud Security Benchmark on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly. The control-plane change is immediate, but the posture catches up on the next assessment. The strongest position combines the account settings with an Azure Policy backstop that audits for private link and for disabled public network access, so a misconfigured account is surfaced rather than silently left open.

What is the impact of leaving Cosmos DB on the public internet?

The direct impact is data exposure. A Cosmos DB account reachable from the public internet is gated by keys and tokens alone, and a leaked primary key, a connection string committed to a repository, or an over-broad resource token is enough to read or write the entire account from anywhere. Endpoints resolve on public DNS by default, so a reachable account is discoverable, and internet-facing data stores are found quickly by automated scanners. Taking the account off the public internet means a leaked credential is no longer sufficient on its own: an attacker also needs a foothold inside your network.

The second-order impact is blast radius and data exfiltration. An account on the public internet is attack surface that must be defended continuously, and it is also an exfiltration path: data can be pushed out to the open internet from a compromised application. Routing access through a private endpoint, combined with restrictive network security group rules, is exactly the configuration Microsoft recommends to reduce the risk of data exfiltration, because traffic to the account stays on private IPs inside the network.

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 data stores are not reachable from untrusted networks. Both recommendations in this capability map to the Microsoft Cloud Security Benchmark control NS-2, secure cloud services with network controls, which is the control auditors look to for private access points. A Cosmos DB estate that uses private link and has public network access disabled is among the cheapest and most defensible artefacts you can hand an auditor.

How do you take Cosmos DB off the public internet safely?

Work the capability as one loop rather than chasing the two findings separately. The order matters: give an account a private path in before you shut the public one, so you do not cut off the applications that depend on it.

1. Inventory every account by reachability

List every Cosmos DB account with its 'publicNetworkAccess' state and whether it has an approved private endpoint. Treat this inventory as the source of truth, not the Defender finding count, because the two recommendations describe the front and back of the same lock and an account can trip both at once.

2. Separate genuine public stores from drift

Decide for each account whether anything legitimately needs to reach it from outside your network. The great majority do not: production data accounts should be reachable only from inside the network. The rare account that must accept outside traffic should still be reached through a controlled front door rather than left directly open.

3. Add the private path, then shut the public one

Create a private endpoint for each account that an application reaches over the network, mapping the correct API sub-resource (Sql, MongoDB, Cassandra, Gremlin or Table) and integrating it with a private DNS zone. Wait for the connection to be approved and DNS to resolve privately, then set 'publicNetworkAccess' to Disabled. Doing it in this order means the application keeps a working path throughout. To avoid the short reconfiguration downtime on an existing account, allow your client through a temporary firewall rule, wait ten minutes, add the private endpoint, then remove the rule.

4. Backstop it with Azure Policy

Assign the built-in policies that audit for private link and for disabled public network access, so any new account left reachable from the public internet is surfaced on the next assessment rather than discovered in an incident. Both policies map to the Microsoft Cloud Security Benchmark control NS-2.

# 1. Give the account a private path IN before shutting the public one.
#    --group-ids is the API sub-resource: Sql, MongoDB, Cassandra, Gremlin or Table.
RG=data-prod
ACCT=custprofiles-prod
VNET=spoke-data-vnet
SUBNET=db-subnet
SUB=$(az account show --query id -o tsv)

az network private-endpoint create \
  --name "${ACCT}-pe" \
  --resource-group "$RG" \
  --vnet-name "$VNET" \
  --subnet "$SUBNET" \
  --private-connection-resource-id \
    "/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.DocumentDB/databaseAccounts/$ACCT" \
  --group-ids Sql \
  --connection-name "${ACCT}-conn"

# 2. Once the endpoint is approved and private DNS resolves, shut the public route.
#    --public-network-access Disabled takes precedence over any IP/VNet firewall rule.
az cosmosdb update \
  --name "$ACCT" \
  --resource-group "$RG" \
  --public-network-access Disabled

# 3. Backstop: audit any future account that lacks private link or stays public.
#    Look the built-in policies up by display name; never hardcode a definition GUID.
for disp in \
  "CosmosDB accounts should use private link" \
  "Azure Cosmos DB should disable public network access"; do
  pid=$(az policy definition list \
    --query "[?displayName=='$disp'].name | [0]" -o tsv)
  az policy assignment create \
    --name "audit-$(echo "$disp" | tr ' A-Z' '-a-z' | cut -c1-40)" \
    --policy "$pid" \
    --scope "/subscriptions/$SUB"
done

Quick quiz

Question 1 of 5

Defender for Cloud shows both 'Cosmos DB accounts should use private link' and 'Azure Cosmos DB should disable public network access' on the same account. How should you think about them?

Keep learning

Go deeper on how Azure Cosmos DB expresses reachability and how the private path and the public-access switch fit together.

You can now treat Azure Cosmos DB as one capability rather than two separate findings: inventory which accounts answer the public internet, give each production account a private endpoint as a private path in, disable public network access so the public route cannot reopen by accident, and back it with an Azure Policy audit. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Hardening Cosmos DB: the cost and risk view

A near-zero-cost capability that removes a database account from the public internet

Disabling public network access on a Cosmos DB account costs nothing in Azure spend. Setting the 'publicNetworkAccess' property to Disabled does not change the bill. The only real cost in this capability is the network plumbing for the private path: a private endpoint carries a small hourly charge plus data-processing fees, and reaching the account privately assumes the workload already sits in, or can peer to, a virtual network. For estates that already run a hub-and-spoke landing zone, that plumbing is mostly in place, so the incremental cost is minimal.

Frame each failing account by the data behind it rather than the recommendation count. A Cosmos DB account holding customer profiles or transaction records that is reachable from the public internet carries a far higher expected loss than an empty development account, yet both surface as a single red finding. Map the failures to the data they hold and prioritise by exposure, not by tidy count.

The arithmetic is one-sided. The remediation is engineering time plus a small, bounded private-endpoint charge for the accounts that need a private path. The downside of leaving an account on the public internet is the documented cost of a database breach: regulatory fines, breach notification, forensics, legal fees and the reputational damage of customer records taken from a store nobody meant to leave reachable.

This lesson is for the finance partner who sees Cosmos DB private-link and public-access findings on the security report and wants to know the right response and what it costs. It covers why disabling public access is free, why the private path carries a small bounded charge, and how to turn a list of red findings into a risk-ordered plan led by the data each account holds.

Fun fact

The database that answered the whole internet

How a finance partner frames the Cosmos DB decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with Cosmos DB findings across several accounts in two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Disabling public network access changes nothing on the Azure bill, so the spend question is narrow: the only cost is the private endpoint each production account needs for a private path in, which is a small hourly charge plus data-processing fees, and that assumes the workload already sits in a virtual network it can reach the account from.

Sam asks the team to map each failing account to the data sitting behind it. One account holds customer profiles, another holds production session state, and the rest are sandbox or development accounts spun up for experiments. The list is reframed on the risk register: the two production data accounts are high expected-loss items to give a private endpoint and lock down this week, at the cost of two small private-endpoint charges; the sandbox accounts hold nothing sensitive and can simply have public network access disabled at zero cost, or be deleted. The finance pack reads: 'Two production accounts need a bounded private-endpoint charge to gain a private path; the rest close at no incremental spend; the gap is engineering time and a small, named network line, not a budget event.'

Why a publicly reachable database belongs on the risk register

The cost model here is asymmetric. Disabling public network access costs nothing, and the private path for the accounts that need it is a small, bounded private-endpoint charge. Leaving an account on the public internet creates an unbounded tail risk: a single leaked key turns a reachable database into a full read of customer data, and while the probability per event is low, the probability across every public account over years is not.

The documented cost of a database breach includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and customer churn when the exposed data is personal. Against that, the remediation is engineering time plus a handful of small private-endpoint charges. The finance role is to attach expected loss to each failing account, weighted by the sensitivity of the data it holds, so the work is prioritised by risk rather than by the order the report lists it.

What finance can do about the Cosmos DB gap

Finance cannot create a private endpoint, but it owns the framing that turns two scattered findings into a risk-ordered plan with a small, named network cost and clearly bounded exceptions. Three levers.

1. Separate the zero-cost closures from the bounded network charge

Make explicit that disabling public network access costs nothing in Azure spend, and that the only real cost is one private endpoint per production account that needs a private path, a small hourly charge plus data-processing fees. Sandbox and empty accounts can simply have public access disabled or be deleted at zero cost. Budget the private endpoints as a discrete, countable line so nobody can claim the whole capability is a spending decision.

2. Order the work by expected loss, not by finding count

An account holding customer profiles and a throwaway sandbox both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each failing account to the data behind it and prioritise the production data stores first. The metric that belongs on the cost-and-security review is the count of publicly reachable accounts weighted by the sensitivity of what they hold, not the raw total.

3. Require documented exceptions for anything left reachable

Any account that genuinely needs to accept traffic from outside the network should carry a recorded, finance-visible reason and the controlled front door it sits behind. The distinction between 'we reviewed this and accepted the exposure deliberately' and 'we never noticed it was public' 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 Cosmos DB private-link and public-access findings on several accounts. As the finance partner, what is the right starting assumption about the Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure Cosmos DB expresses reachability and how the private path and the public-access switch fit together.

You have finished the finance view of hardening Cosmos DB. You know the cost model is one-sided: disabling public access is free, the private path is a small, bounded private-endpoint charge for the accounts that need it, and the downside of leaving an account public is the documented and unbounded cost of a breach. Next time Cosmos DB findings land, you will order them by expected loss led by the data each account holds, budget the private endpoints as a named line, and ask for any exception on the record rather than asking how much remediation will cost.

Back to the library

Hardening Cosmos DB: the headline

Whether a production database is reachable from the internet by accident

Cosmos DB often holds the operational data a business runs on: customer records, sessions, catalogues, telemetry. An account reachable from the public internet, with access gated only by a key, is one leaked credential away from exposure, and the report shows this as separate private-link and public-access findings rather than one clear statement.

The leadership question is not 'are we compliant today?' It is 'can our production database be reached from the open internet at all?' The defensible end state is that every account holding real data is reachable only through a private endpoint inside the network, and that public network access is disabled so the public route cannot reopen through a careless change.

This is not a cost decision. Shutting the public route is free in Azure terms, and the private path is a small, bounded network charge. It is a governance decision about whether your databases are off the public internet by design or only because nobody has yet made the change that puts one back on it.

A short read for the leader who needs to know what a publicly reachable production database means, why taking it off the public internet is a governance decision rather than a budget one, and what a defensible end state looks like across the estate.

Fun fact

The database that answered the whole internet

What it looks like when a database is off the public internet by design, not luck

After a peer company made the news for a customer database that turned out to be reachable from the open internet, 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 restrict each account, because reachability across the estate was governed by habit rather than by the landing zone.

The team's response was to stop treating Cosmos DB as a per-account cleanup and start treating it as a guardrail. They listed every account that still answered the public internet, gave each production account a private endpoint inside the network, disabled public network access on all of them, and then set an Azure Policy that audits any account left without private link and flags any account whose public network access is still enabled. The next time the CEO asked, the answer had changed from 'we believe so' to 'no, every production database is reachable only from inside the network, and the platform flags any new account that is left public.' That shift, from relying on everyone remembering to restrict each account to making the open state visible and rare, is the one-line confidence signal this capability delivers, and the only cost is a handful of small private-endpoint charges.

Why this is a board-level risk

Nearly every major cloud data breach that involved a database came back to the same root cause: a store reachable from more of the internet than intended, with access resting on a credential that leaked. Taking Cosmos DB off the public internet is the capability that makes that root cause structurally harder, because a leaked key is no longer sufficient on its own, and an Azure Policy backstop keeps any new public account visible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is engineering time plus a small, bounded network charge. This is the class of control where the risk of inaction is severe and the cost of action is modest and predictable, which is exactly the trade leadership should be quickest to approve.

The leadership move on Cosmos DB

The executive handle is not to approve each private endpoint individually; it is to require that production databases are reachable only from inside the network and that any account left public is a named, owned exception, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, every production account has a private endpoint, public network access is disabled across the board, and Azure Policy audits any new account that lacks private link or stays public. A backstop that surfaces the open state is the difference between checking nothing is reachable today and being told the moment something becomes reachable 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 private-link and public-network-access recommendations across every subscription plus evidence that the NS-2 audit 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 anything still reachable as a named, owned exception

If a database genuinely must accept traffic from outside the network, that can be acceptable, but only as a deliberate, documented decision with an owner and a controlled front door, not an account quietly left on the public internet. The goal is not zero public accounts in the abstract; it is zero unintended ones.

Quick quiz

Question 1 of 5

At a board review you ask whether a publicly reachable-database incident 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 Cosmos DB expresses reachability and how the private path and the public-access switch fit together.

Two takeaways. Taking a database off the public internet is the rare control where the risk of inaction is severe and the cost of action is engineering time plus a small, predictable network charge, so it is the trade you should be quickest to approve. And the defensible end state is not 'we checked and nothing is public today'; it is every production account behind a private endpoint with public network access disabled, backed by Azure Policy that flags anything left reachable, with the few deliberate exceptions 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.

Azure Cosmos DB

Part of the learning path Harden Azure workloads

Harden Azure Cosmos DB

Hardening Cosmos DB: the basics

The database that answered the whole internet

Finding publicly reachable Cosmos DB accounts

How Defender for Cloud decides a Cosmos DB account is exposeddeep dive

What is the impact of leaving Cosmos DB on the public internet?

How do you take Cosmos DB off the public internet safely?

1. Inventory every account by reachability

2. Separate genuine public stores from drift

3. Add the private path, then shut the public one

4. Backstop it with Azure Policy

Quick quiz

Keep learning

Hardening Cosmos DB: the cost and risk view

The database that answered the whole internet

How a finance partner frames the Cosmos DB decision

Why a publicly reachable database belongs on the risk register

What finance can do about the Cosmos DB gap

1. Separate the zero-cost closures from the bounded network charge

2. Order the work by expected loss, not by finding count

3. Require documented exceptions for anything left reachable

Quick quiz

Keep learning

Hardening Cosmos DB: the headline

The database that answered the whole internet

What it looks like when a database is off the public internet by design, not luck

Why this is a board-level risk

The leadership move on Cosmos DB

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat anything still reachable as a named, owned exception

Quick quiz

Keep learning

Controls this lesson covers

Azure Cosmos DB

Related compliance lessons