Compliance

Harden Azure Container Registry

One capability across the registries that hold your images: make sure no registry is reachable from the public internet by default, that the images it stores are pulled over a private path, and that regulated workloads can prove their layers are encrypted under a key you control.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-container-registry-cmk-encryption azure-container-registry-private-link azure-container-registry-restrict-network-access

Hardening container registries: the basics

What does an exposed Azure Container Registry actually look like?

An Azure Container Registry is the supply-chain root of everything you run: every image your AKS clusters, Container Apps and Container Instances pull starts life here. Exposure shows up in a few distinct shapes rather than one setting. The registry can accept connections over its public endpoint from any network on the internet, so anyone with a credential, or a leaked one, can reach it from anywhere. It can lack a private endpoint, so even your own workloads pull images across the public internet rather than over the Azure backbone. And its image layers can rest under the platform-managed key when a regulated workload needs a customer-managed key it can rotate and revoke. Each is its own Defender for Cloud recommendation, but the underlying risk is the same: the place your trusted images live is reachable, or pullable, more widely than you meant.

Microsoft Defender for Cloud turns each of these into its own recommendation, which is why one registry can fail several container checks at once. 'Container registries should not allow unrestricted network access' and 'Container registries should use private link' close the network doors, and 'Container registries should be encrypted with a customer-managed key' covers encryption at rest for the regulated case. They read as separate problems on the report, but they are one job: make the registry reachable only from your network, pull over a private path, and, where the data class demands it, hold the keys yourself.

Most of this exposure is the default rather than a decision. A new registry accepts public network traffic out of the box, a Basic or Standard SKU was chosen so private link and firewall rules were never an option, a Premium registry was created without a private endpoint because the quickstart did not mention one. The work is to find every registry that is reachable from the public internet, move it to Premium where network controls live, route pulls through a private endpoint, and reserve customer-managed keys for the workloads whose compliance class genuinely requires them.

In this lesson you will learn how Azure Container Registry expresses public reachability, private connectivity and encryption at rest, how to find every over-exposed registry in a subscription, and how to lock them down without breaking the pulls your clusters and pipelines depend on. 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 registry is the keys to the kingdom

Researchers have repeatedly shown that a single over-permissioned or internet-reachable container registry is one of the highest-value targets in a cloud estate: push access to it means push access to what every downstream cluster runs. Public scans regularly turn up registries reachable over their public endpoint, and a leaked pull or push credential against an open registry is far more dangerous than the same credential against one that only answers inside a virtual network. Azure leaves the public endpoint enabled on a new registry by default and only offers firewall rules and private link on the Premium tier, so a registry that is both open and on a lower SKU has no network defence at all until someone changes both.

Finding registry exposure across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows container-registry findings on several registries across two subscriptions, all created from the portal quickstart with default networking.

Rather than work the findings one by one, Sam starts by listing which registries still accept public network traffic and which SKU they are on, because the SKU decides whether private link is even available before anything can be locked down.

Start by listing every registry with its SKU and public-network setting. The Premium registries can be locked down in place; the others need an upgrade first.

$ az acr list --query "[].{name:name, sku:sku.name, publicNet:publicNetworkAccess}" -o table

Name Sku PublicNet

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

prodimagesacr Premium Enabled

sandboxacr Basic Enabled

# prodimagesacr is Premium and public: lock it down in place with a private endpoint.

# sandboxacr is Basic: firewall and private link need a Premium upgrade first.

A Premium registry that still accepts public traffic is the highest-value target: it can be closed in place. A Basic or Standard registry has to be upgraded to Premium before any network control applies.

How Defender for Cloud decides a registry is exposeddeep dive

Most registry recommendations resolve to one of three properties. The first is 'publicNetworkAccess' together with the network rule set's default action: when public access is Enabled and the default action is Allow, the registry answers over its public endpoint from any network, so anyone with a credential can reach it from anywhere. The second is whether the registry has an approved private endpoint connection: with no private endpoint, even your own workloads resolve and pull the registry over the public internet rather than over the Azure backbone, which is what 'Container registries should use private link' checks for. The third is the encryption block: by default image layers rest under a Microsoft-managed key, and the customer-managed-key recommendation looks for an encryption status of enabled with a Key Vault key you supplied.

Two structural facts shape the remediation. Firewall rules, the ability to disable public access, and private link are all Premium-tier features, so a Basic or Standard registry cannot be network-restricted at all until it is upgraded to Premium. And a customer-managed key can only be set when the registry is created, on a Premium registry, using a user-assigned managed identity granted the Key Vault Crypto Service Encryption User role (or get, wrapKey and unwrapKey key permissions); the key must be an RSA or RSA-HSM key, and once CMK is enabled it cannot be disabled. That means CMK is a create-time decision for a registry, not a switch you flip later.

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. One detail saves an outage: when you disable public access, the 'allow trusted services' setting (on by default) lets Defender for Cloud, ACR Tasks and image import keep reaching the registry, so leave it enabled unless you have a specific reason not to.

What is the impact of leaving a registry exposed?

The direct impact is a compromised supply chain. A registry reachable over the public internet is a target for any leaked or sprayed credential, and push access means an attacker can replace a trusted image with a poisoned one that every downstream cluster then pulls and runs. Unlike a single exposed data store, a tampered registry propagates: the damage runs wherever those images are deployed. Pulls that cross the public internet rather than a private endpoint also widen the surface that has to be defended and complicate proving where your images actually travelled.

The second-order impact is blast radius and provenance. When the source of your images is reachable from anywhere, you cannot cleanly assert which images are trustworthy, and an incident turns into a forensic exercise across every image and every workload that pulled one. Routing pulls through a private endpoint and closing the public door shrinks that to the registries you operate inside your own network, which are the ones you can monitor and reason about.

On the compliance and encryption side, regulated workloads frequently require that data at rest, including container image layers, is encrypted under a key the organisation controls and can revoke. A customer-managed key on the registry is how you evidence that for the workloads whose data class demands it. Across frameworks such as ISO 27001, SOC 2, PCI DSS and the UK and EU data-protection regimes, a passing set of registry recommendations is a cheap and defensible artefact that the supply chain is not open to the internet.

How do you lock a registry down safely?

Work the capability as one loop rather than chasing individual findings. The order matters: confirm the SKU and keep the trusted-services bypass on before you close the public door, so you do not cut off Defender's scanning or your own build pipeline.

1. Inventory every registry by SKU and exposure

List every registry with its SKU and its public-network setting, and note which have a private endpoint. The SKU is the gate: firewall rules, disabling public access and private link are Premium-only, so a Basic or Standard registry has to be upgraded before any network control applies. Treat this inventory as the source of truth, not the Defender finding count, because one registry can trigger several recommendations at once.

2. Prioritise by what each registry feeds

Map each registry to the workloads downstream of it. A registry supplying production images to an internet-facing service is the highest blast radius and earns the Premium upgrade and a private endpoint first. Sandbox and throwaway registries are low value and can often be consolidated away rather than hardened. Spend the bounded budget where the supply chain actually matters.

3. Add a private endpoint, then close the public door

Create a private endpoint into your virtual network so workloads pull over the Azure backbone, then set the network default action to Deny and turn public network access off. Leave 'allow trusted services' enabled so Defender for Cloud can keep scanning images and ACR Tasks and image import keep working. Confirm your clusters and pipelines resolve the registry's private IP before you flip the public switch off.

4. Use customer-managed keys for the regulated registries, and audit the rest with policy

For the registries whose data class requires a key the organisation controls, create the registry as Premium with a user-assigned identity and a customer-managed key (this is a create-time decision and cannot be undone). Then assign Azure Policy to audit for unrestricted network access and private-link use across the estate, so a registry created open in future is flagged rather than missed.

# 1. Lock down an existing Premium registry: add a private endpoint, then close the public door.
RG=platform-rg
ACR=prodimagesacr
VNET=hub-vnet
SUBNET=registry-subnet

# Create the private endpoint into your VNet (registry must be Premium).
ACR_ID=$(az acr show --name "$ACR" --query id -o tsv)
az network private-endpoint create \
  --resource-group "$RG" --name "${ACR}-pe" \
  --vnet-name "$VNET" --subnet "$SUBNET" \
  --private-connection-resource-id "$ACR_ID" \
  --group-id registry \
  --connection-name "${ACR}-conn"

# Close the public door but keep trusted services (Defender, ACR Tasks, import) reaching it.
az acr update --name "$ACR" \
  --default-action Deny \
  --public-network-enabled false \
  --allow-trusted-services true

# 2. Create a NEW registry encrypted with a customer-managed key (CMK is create-time only).
#    Prereqs already in place: user-assigned identity granted 'Key Vault Crypto Service
#    Encryption User' on a key vault with soft-delete + purge protection, and an RSA key.
az acr create --resource-group "$RG" --name regulatedacr --sku Premium \
  --identity "$identityID" --key-encryption-key "$keyID"

# 3. Ratchet it shut estate-wide: audit any registry that allows unrestricted network access.
pid=$(az policy definition list \
  --query "[?displayName=='Container registries should not allow unrestricted network access'].name" -o tsv)
az policy assignment create \
  --name audit-acr-network \
  --policy "$pid" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Quick quiz

Question 1 of 5

Defender for Cloud shows findings on a registry across unrestricted network access, missing private link and platform-managed encryption. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure Container Registry expresses network restriction, private connectivity and encryption at rest across the settings in this capability.

You can now treat Azure Container Registry as one capability rather than a scatter of findings: inventory every registry by SKU and exposure, prioritise by what each one feeds, add a private endpoint and close the public door (keeping trusted services on so Defender keeps scanning), reserve customer-managed keys for the regulated registries at create time, and audit the estate 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

Hardening container registries: the cost and risk view

A low-cost capability that protects the supply chain every workload depends on

Registry exposure is a supply-chain risk, because every running container traces back to an image pulled from here, and most of the controls in this group cost little to nothing in Azure spend. Disabling public network access or restricting the firewall does not change your bill. The real cost sits in two places: the network controls and private link only exist on the Premium SKU, so a Basic or Standard registry has to be upgraded to Premium first, and the private endpoint itself carries a small hourly and data-processing charge. Customer-managed keys add a modest Key Vault cost and are needed only for the regulated workloads whose data class requires them.

Frame each failing recommendation by what the registry actually feeds. A registry that supplies production images to an internet-facing service carries a far higher expected loss if its supply chain is tampered with than a registry holding throwaway sandbox images, yet both surface as a single red finding. Map the failures to the workloads downstream of them and prioritise by blast radius, not by recommendation count.

The arithmetic is one-sided. The remediation is a Premium upgrade and a private endpoint per registry that matters, plus a small Key Vault charge for the regulated few. The downside of leaving it open is the cost of a compromised supply chain: a poisoned image pulled into production, the incident response, the forensic effort to prove which images were affected, and the regulatory and reputational fallout.

This lesson is for the finance partner who sees a cluster of container-registry findings on the security report and wants to know what the right response is and what it costs. It covers which controls are essentially free, which carry a real and bounded cost (the Premium SKU upgrade, the private endpoint, and customer-managed keys), and how to turn a list of red findings into a plan ordered by what each registry feeds downstream.

Fun fact

The registry is the keys to the kingdom

How a finance partner frames the registry decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with container-registry findings on several registries across two subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding and what it feeds. Disabling public network access or tightening the firewall changes nothing on the Azure bill, so the spend question is narrow and specific: the network controls and private link only exist on the Premium SKU, so any Basic or Standard registry that needs locking down has to be upgraded to Premium first, the private endpoint carries a small hourly and data-processing charge, and customer-managed keys add a modest Key Vault charge for the regulated few.

Sam asks the team to map each failing registry to the workloads downstream of it. One registry supplies the production images for the customer-facing platform, one feeds an internal tool, and the rest hold sandbox and throwaway images. The list is reframed by blast radius: the production-supplying registry is the priority, it justifies the Premium upgrade and a private endpoint today, the internal-tool registry follows, and the sandbox registries can be left public on a lower SKU or simply consolidated away. The finance pack reads: 'The control is mostly engineering time; the only real spend is a Premium upgrade and a private endpoint for the two registries that actually feed production, plus a small Key Vault charge if a regulated workload needs its own key.'

Why registry exposure belongs on the risk register

The cost model here is asymmetric. Closing the network on a registry is largely engineering time, the only hard spend is the Premium upgrade and the private endpoint for the registries that matter, plus a small Key Vault charge for the regulated few. Against that sits the unbounded tail risk of a supply-chain compromise: a poisoned image is not contained to one resource, it runs everywhere it is deployed, and the cost of unwinding that across an estate is large and hard to forecast.

The documented cost of a supply-chain incident includes the incident response, the forensic effort to identify every affected image and workload, mandatory breach notification within tight windows where customer data is involved, and the reputational damage of having shipped a compromised artefact. The finance role is to attach expected loss to each failing registry, weighted by what it feeds, so the Premium upgrades and private endpoints land on the registries downstream of production first rather than being spread evenly across sandboxes.

What finance can do about the registry gap

Finance cannot add a private endpoint, but it owns the framing that turns a scatter of red findings into a plan ordered by blast radius with a small, clearly bounded set of real costs. Three levers.

1. Separate the engineering time from the real spend

Make explicit that most of this capability costs nothing on the Azure bill: disabling public access and tightening the firewall do not move spend. The real cost is narrow and nameable: the Premium SKU upgrade for any registry that needs network controls, the small hourly and data-processing charge of each private endpoint, and a modest Key Vault charge for customer-managed keys where a regulated workload needs one. Budget those 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 what each registry feeds, not by finding count

A registry supplying production images to a customer-facing service and a sandbox registry of throwaway images both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each failing registry to the workloads downstream of it and fund the Premium upgrades and private endpoints for the production-supplying registries first. The metric that belongs on the cost-and-security review is findings weighted by downstream blast radius, not the raw total.

3. Question whether every registry needs to exist

The cheapest hardening is consolidation. A sprawl of sandbox and team-specific registries multiplies both the attack surface and the Premium-plus-private-endpoint cost of securing them. Before approving an upgrade for each, ask whether low-value registries can be retired or merged into a smaller number of well-governed Premium registries. Fewer registries means fewer doors to close and fewer private endpoints to pay for.

Quick quiz

Question 1 of 5

A security report shows several container-registry 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 Container Registry expresses network restriction, private connectivity and encryption at rest across the settings in this capability.

You have finished the finance view of hardening container registries. You know the cost model is asymmetric but not free: most of it is engineering time, the real spend is a Premium upgrade and a private endpoint for the registries that feed production plus a small Key Vault charge for the regulated few, and the downside of leaving the supply chain open is the unbounded cost of a tampered-image incident. Next time a cluster of registry findings lands, you will order them by downstream blast radius, fund the registries that matter, consolidate the low-value ones, and name the Premium and private-endpoint costs explicitly.

Back to the library

Hardening container registries: the headline

Whether the source of every image you run can be reached from the internet by default

A container registry is the single point that every workload trusts: if an attacker can reach it and push, they can change what runs everywhere downstream. A registry left open to the public internet, which is the default, is the kind of soft target that turns one stolen credential into a supply-chain incident, and the report shows this as a scatter of separate findings.

The leadership question is not 'are we compliant today?' It is 'can the source of our production images be reached from the public internet, and if a credential leaks tomorrow, what is the blast radius?' The defensible end state is that registries are reachable only from your own network over a private endpoint, public network access is off, and the regulated workloads encrypt their image layers under a key the organisation controls.

The cost here is small and bounded: a Premium upgrade and a private endpoint for the registries that matter. It is a governance decision about whether the supply chain is closed by design or left on the default open setting because nobody changed it.

A short read for the leader who needs to know why a container registry is the supply-chain root of every workload, why locking it down is a governance decision with a small bounded cost, and what a defensible end state looks like across the estate.

Fun fact

The registry is the keys to the kingdom

What it looks like when the supply chain is closed by design, not by default

After a peer company traced a production incident back to a tampered image pulled from a registry that had been reachable over the public 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, because the registries had been created from the quickstart with public access on and nobody had revisited the networking.

The team's response was to stop treating the registry as a developer convenience and start treating it as the supply-chain root it is. They listed every registry, upgraded the two that feed production to Premium, gave each a private endpoint, turned public network access off, and left the trusted-services bypass on so Defender for Cloud could still scan the images and the build pipeline could still push. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, our production images come from registries that are only reachable inside our own network, and Defender still scans every image we push.' That shift, from an open default to a closed-by-design supply chain, is the confidence signal this capability delivers, for a small and bounded cost.

Why this is a board-level risk

A container registry is the one resource that every workload trusts implicitly. A supply-chain attack that reaches an open registry does not expose a single store of data, it changes what runs across the estate, which is why an internet-reachable registry is a disproportionately attractive target. Closing the public door and routing pulls through a private endpoint is the capability that makes that attack structurally difficult.

The cost of getting this wrong is a supply-chain incident with estate-wide blast radius, while the cost of fixing it is a Premium upgrade and a private endpoint for the registries that matter. This is the rare class of control where the risk of inaction is severe and the cost of action is small and bounded, which is exactly the trade leadership should be quickest to approve.

The leadership move on container registries

The executive handle is not to approve each lockdown individually; it is to require that the registries feeding production are reachable only from your own network, and that the supply chain is closed by design rather than left on the open default.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, the registries that feed production are Premium with a private endpoint and public access off, the regulated registries use customer-managed keys, and Azure Policy audits for unrestricted network access and private-link use. A policy backstop is the difference between checking nothing is open today and being told whenever a registry is created open 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 registry recommendations across every subscription plus evidence that pulls now resolve over private endpoints and that Defender still scans pushed images. 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. Accept that locking down has a real, small cost and fund it

Unlike some controls, hardening a registry is not entirely free: network controls require the Premium SKU and a private endpoint per registry. The leadership requirement is to accept that bounded cost for the registries that feed production rather than leave the supply chain open to save a modest line item, and to consolidate low-value registries so the bill stays small.

Quick quiz

Question 1 of 5

At a board review you ask whether a supply-chain incident like a competitor's tampered-image event could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure Container Registry expresses network restriction, private connectivity and encryption at rest across the settings in this capability.

Two takeaways. A container registry is the supply-chain root every workload trusts, so an internet-reachable one is a disproportionately high-value target and the lockdown is a trade you should be quick to approve. And the defensible end state is not 'we checked and nothing is open today'; it is that the registries feeding production are reachable only inside your own network over a private endpoint, the regulated ones hold their own keys, and Azure Policy flags any registry created open, all for a small and bounded cost.

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 Container Registry

Part of the learning path Harden Azure workloads

Harden Azure Container Registry

Hardening container registries: the basics

The registry is the keys to the kingdom

Finding registry exposure across a subscription

How Defender for Cloud decides a registry is exposeddeep dive

What is the impact of leaving a registry exposed?

How do you lock a registry down safely?

1. Inventory every registry by SKU and exposure

2. Prioritise by what each registry feeds

3. Add a private endpoint, then close the public door

4. Use customer-managed keys for the regulated registries, and audit the rest with policy

Quick quiz

Keep learning

Hardening container registries: the cost and risk view

The registry is the keys to the kingdom

How a finance partner frames the registry decision

Why registry exposure belongs on the risk register

What finance can do about the registry gap

1. Separate the engineering time from the real spend

2. Order the work by what each registry feeds, not by finding count

3. Question whether every registry needs to exist

Quick quiz

Keep learning

Hardening container registries: the headline

The registry is the keys to the kingdom

What it looks like when the supply chain is closed by design, not by default

Why this is a board-level risk

The leadership move on container registries

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Accept that locking down has a real, small cost and fund it

Quick quiz

Keep learning

Controls this lesson covers

Azure Container Registry

Related compliance lessons