Microsoft Solutions Partner — Container Supply Chain · 11,000+ engagements

Azure Container Registry & Supply Chain Security (2026)

How enterprises run Azure Container Registry as a hardened software supply chain — geo-replicated Premium, Notation and cosign signing, SLSA provenance, Defender for Containers scanning, and the EPC Group five-phase accelerator. Authored by a 29-year Microsoft Solutions Partner.

Book a Container Supply Chain briefing Call 888-381-9725

What is Azure Container Registry and how do enterprises run it as a hardened supply chain? Azure Container Registry (ACR) is the Microsoft managed OCI v1.1 artifact registry for container images, Helm charts, ARM and Bicep modules, SBOM documents, and ML model artifacts. Enterprises run ACR on the Premium tier with active-active geo-replication across every region of consumption, Private Link endpoints into each consumer VNET, customer-managed-key encryption rooted in Azure Key Vault HSM, image signing through Notation or cosign with verification at admission, Defender for Containers vulnerability scanning on push and continuous, and SLSA provenance attestations through GitHub Actions or Azure DevOps. EPC Group delivers the registry as a hardened software supply chain through a five-phase Assess, Foundation, Platform, Workload, Operate accelerator that produces a production-grade estate in eight to fourteen weeks, fixed-fee between $120K and $400K.

Azure Container Registry is the Microsoft managed OCI v1.1 artifact registry behind every production Microsoft container estate. The 2026 reference architecture pairs the Premium tier with active-active geo-replication across regions of consumption, Private Link into each consumer VNET, customer-managed-key encryption rooted in Azure Key Vault HSM, image signing through Notation or cosign with admission-time verification, SLSA-level-3 provenance through in-toto attestations stored as OCI artifacts, and Defender for Containers vulnerability scanning on push and continuous. ACR is the correct registry for AKS, Container Apps, App Service for Containers, Azure Functions on containers, and any platform-team or ISV scenario that needs a hardened supply chain across multiple workloads and regions. EPC Group delivers a fixed-fee five-phase Container Supply Chain Accelerator between $120K and $400K.

Key Facts

Premium tier is the production baseline — geo-replication, Private Link, signing, customer-managed keys, repository-scoped tokens, content trust
Active-active geo-replication maintains synchronized image copies across every region of consumption with regional endpoint affinity
Notation (Microsoft, CNCF) and cosign (Sigstore, CNCF) both store signatures via the OCI v1.1 referrers API on the same Premium registry
SLSA framework provenance achievable at level 3 through GitHub Actions OIDC, Azure DevOps, or ACR Tasks with Microsoft-signed attestations
Defender for Containers scans every push and continuously rescans the registry against the Microsoft Threat Intelligence database
ACR Tasks base-image-update trigger collapses the patch lag from weeks to hours after Microsoft publishes a security update
OCI v1.1 artifact support stores Helm charts, Bicep modules, ML models, SBOM, and provenance attestations adjacent to the container images
EPC Group five-phase Container Supply Chain Accelerator delivers full activation in 8 to 14 weeks, fixed-fee $120K to $400K — 29-year Microsoft Solutions Partner

ACR Basic, Standard, and Premium — the production decision is Premium

ACR offers three service tiers with materially different feature surfaces. The production decision for any enterprise estate is Premium — every supply-chain control (geo-replication, Private Link, signing, customer-managed keys, repository-scoped tokens) is Premium-only. Basic and Standard are correct only for ephemeral dev, learning, and isolated workloads where supply-chain controls are out of scope.

Capability	Basic	Standard	Premium
Included storage	10 GiB included — overage per-GiB charges apply	100 GiB included — overage per-GiB charges apply	500 GiB included — overage per-GiB charges apply for the long tail
Throughput and read/write performance	Entry-level throughput — fine for dev, training, and isolated workloads	Mid-tier throughput — production-grade for single-region estates	Highest throughput — sized for fleet-scale AKS, Container Apps, and CI build farms
Geo-replication	Not available — single region only	Not available — single region only	Multi-region active-active replication with regional endpoint affinity
Private endpoints + Private Link	Not available — public endpoint only	Not available — public endpoint only	Full Private Link support — private endpoints across multiple VNETs and regions
Content trust + image signing	Not available	Not available	Notation, cosign, and notary-v2 signing surfaces — required for production trust
Customer-managed keys (CMK)	Not available — platform-managed encryption only	Not available — platform-managed encryption only	Customer-managed keys in Azure Key Vault with HSM-backed options
Repository-scoped tokens	Not available — registry-wide credentials only	Not available — registry-wide credentials only	Fine-grained tokens scoped to individual repositories and actions
Best fit	Dev and learning registries, isolated workloads	Single-region production for small estates that do not need geo or Private Link	Every regulated, multi-region, or supply-chain-hardened production estate

ACR is the registry behind every Microsoft container compute surface — AKS, Container Apps, App Service for Containers, and Azure Functions on containers all pull from ACR with Entra-bound workload identity. The broader Azure plane sits at Azure consulting services.

Six ACR enterprise patterns

Every ACR engagement composes from one or more of these six patterns. EPC Group sequences the build against the customer’s regulatory profile and the existing registry footprint, not against the platform feature catalog.

Pattern 1 — Multi-region image cache with geo-replicated Premium ACR

For any production estate running containers in two or more Azure regions, the correct registry pattern is a single Premium ACR with active-active geo-replication across each region of consumption. The platform exposes a single registry URL while the data path resolves to the nearest replica through DNS — removing cross-region pull cost, cold-start latency on scale events, and the single-region availability dependency a non-replicated registry imposes on every consumer. EPC Group sequences replication during the foundation phase and pairs it with regional Private Endpoints so pull traffic never traverses the public internet.

Pattern 2 — Image signing through Notation and cosign — production trust

Image signing proves an image was built by the customer, has not been tampered with, and is authorized to run in production. Premium ACR exposes the OCI v1.1 referrers API that both Notation (Microsoft + CNCF) and cosign (Sigstore) target for storing signatures, SBOM attachments, and SLSA provenance attestations adjacent to the manifest. The pattern: build the image, generate the signature with an identity rooted in Azure Key Vault HSM, push both, and wire the runtime (AKS Image Integrity or Ratify; Container Apps policy) to verify before pulling. Unsigned images fail admission.

Pattern 3 — Vulnerability scanning through Microsoft Defender for Containers

Defender for Containers is the Microsoft-native scanning surface for ACR. Every image pushed to Premium is scanned on push and continuously rescanned against Microsoft Threat Intelligence; findings flow to Defender for Cloud as posture recommendations with CVE detail and onward into Microsoft Sentinel where the SOC consumes them through the unified incident queue. Matches what Wiz, Aqua, and Snyk deliver as standalone scanners, but inside the Microsoft Defender XDR control plane — same identity, same posture engine, same alert pipeline across containers, hosts, identities, and the cloud control plane.

Pattern 4 — ACR Tasks for CI build integration and base-image updates

ACR Tasks is the build surface inside the registry — a managed container build service running Docker, Buildah, or buildpack builds without standing up a separate build farm. Three trigger types — source commit, base-image update, schedule — cover the dominant CI patterns. The base-image-update trigger is the operationally important one: when Microsoft publishes a security update to an Ubuntu, Alpine, .NET, or Java base, every customer image FROM that base rebuilds automatically. The pattern collapses patch lag from weeks to hours. EPC Group pairs Tasks with GitHub Actions or Azure DevOps for source-driven builds.

Pattern 5 — OCI artifacts for Helm charts, ARM templates, and Bicep modules

Modern ACR is an OCI v1.1 artifact registry, not a container-image-only registry. Helm charts, ARM templates, Bicep modules, ML model artifacts, WASM modules, configuration bundles, and SBOM documents store as first-class OCI artifacts in the same registry as container images. The pattern collapses the artifact estate — Helm chart museum, Bicep module library, model registry — into a single trusted plane that already has geo-replication, Private Link, Defender scanning, signing, and Entra identity.

Pattern 6 — Customer-isolated multi-tenant registry for ISV and platform teams

For ISV and platform-team scenarios that host artifacts on behalf of multiple downstream tenants, the correct ACR pattern uses repository-scoped tokens, registry-scoped role assignments, and content-permission policies to enforce tenant boundaries inside a single Premium registry rather than provisioning one registry per tenant. The pattern delivers the operational economy of a shared plane with the security posture of dedicated registries — each tenant pulls only its own repositories, signs with its own identity, and pays for its own storage and bandwidth in the chargeback model.

Image signing & trusted artifacts

Image signing — Notation, cosign, SBOM attachments, and runtime verification

Image signing is the supply-chain control that proves an image is what the producer says it is. ACR Premium exposes the OCI v1.1 referrers API that both Notation (Microsoft and CNCF) and cosign (Sigstore) target, plus SBOM and SLSA provenance attestation attachments. Signing without verification is theater — the runtime side wires AKS Image Integrity, Ratify, or Container Apps registry policy to fail closed on unsigned or untrusted images.

Notation — Microsoft and CNCF signing surface

Notation is the Microsoft-sponsored, CNCF-incubating signing tool targeting the OCI v1.1 referrers API for signature storage. It uses X.509 certificates rooted in a customer-controlled CA (Azure Key Vault as the production root), produces a JSON Web Signature attached to the manifest, and verifies through a trust policy naming the trusted CAs and trust scope. Notation is the Microsoft-canonical path for AKS Image Integrity, ACR built-in policy verification, and Microsoft-managed verification surfaces.

X.509 certificate-rooted signing with Azure Key Vault HSM-backed keys
OCI v1.1 referrers API — signatures travel with the image across replicas
Native AKS Image Integrity admission controller for runtime verification
Trust policy model — name the CA, scope the trust, fail closed by default

Cosign — Sigstore-native signing for hybrid estates

Cosign is the Sigstore-native signing surface organizations adopt when the broader estate is already on Sigstore — keyless signing through Fulcio short-lived certificates, transparency log through Rekor, and verification through Sigstore policy controllers (Kyverno, OPA Gatekeeper, or Ratify on AKS). Premium ACR is a first-class cosign target because cosign uses the same OCI v1.1 referrers API. The right choice for hybrid estates spanning AKS, EKS, and GKE.

Sigstore-native — Fulcio short-lived certificates and Rekor transparency log
OCI v1.1 referrers storage — same surface as Notation, different cryptographic story
Ratify on AKS, OPA Gatekeeper and Kyverno policy controllers on AKS or EKS
Correct choice for cross-cloud estates and Sigstore-aligned platform teams

SBOM and attestation attachments — the supply-chain bill of materials

Beyond the signature itself, ACR stores SBOM (Software Bill of Materials) documents, SLSA provenance attestations, and vulnerability scan reports as separate OCI artifacts attached through the referrers API. SPDX and CycloneDX SBOM formats are both supported. The pattern delivers a complete provenance chain — packages inside the image, who built it, on what infrastructure, from which source commit, signed by which identity — that auditors and downstream consumers verify independently of the producer.

SPDX and CycloneDX SBOM documents stored as OCI artifacts adjacent to the image
SLSA provenance attestations capture build environment, source, and signer
Vulnerability scan reports attached as machine-readable artifacts for downstream consumers
Independent verification — auditors verify the chain, they do not trust the producer

Runtime verification — AKS Image Integrity, Ratify, and Container Apps policy

Signing without verification is theater. The production pattern wires the runtime — AKS through Image Integrity or Ratify (CNCF), Container Apps through built-in registry policy, Azure Functions through the Container Functions admission surface — to verify the signature, the trust chain, and (optionally) the SBOM and attestation chain before pulling. Unsigned images, untrusted signers, or unresolved critical CVEs fail admission. EPC Group ships verification policy as code so the posture is auditable and reproducible.

AKS Image Integrity admission controller — Microsoft-native, Notation-aware
Ratify on AKS — CNCF project, supports Notation and cosign in one flow
Container Apps registry policy — verification at the environment level
Policy-as-code — Bicep + manifests, Resource Graph evidence for auditors

SLSA provenance & in-toto attestations

Provenance — SLSA framework, in-toto, and the production build path

Provenance proves where an image came from — what source code produced it, on which build platform, with which signer identity. The SLSA framework grades build provenance maturity across four levels; the in-toto attestation format is the on-the-wire envelope that carries the provenance. EPC Group targets SLSA level 3 as the production baseline for regulated workloads, achievable through GitHub Actions, Azure DevOps, or ACR Tasks.

SLSA framework — the four levels of build provenance maturity

SLSA (Supply-chain Levels for Software Artifacts) is the OpenSSF-stewarded framework that grades build provenance maturity across four levels — SLSA 1 (documented build process), SLSA 2 (version-controlled source, build service producing authenticated provenance), SLSA 3 (hardened build platform, non-falsifiable provenance), and SLSA 4 (two-party review, hermetic builds, reproducible builds). EPC Group targets SLSA 3 as the production baseline for regulated workloads — GitHub Actions OIDC-attested provenance, Azure DevOps SLSA-compatible attestations, or ACR Tasks with Microsoft-signed build provenance all qualify. Achieving SLSA 4 typically requires hermetic build infrastructure that most enterprises do not justify the cost of; SLSA 3 with continuous CVE remediation is the pragmatic regulated-industry baseline.

in-toto attestations — the on-the-wire provenance format

in-toto is the CNCF-incubating attestation framework that defines the on-the-wire provenance format SLSA references — a signed envelope around a structured statement that names the subject (the image digest), the predicate type (the schema of the attestation), and the predicate (the actual provenance data). SLSA provenance attestations are in-toto attestations with a specific predicate type. The pattern stores the in-toto attestation as an OCI artifact attached to the image through the referrers API, signed with the same signing identity that signs the image itself. Downstream verifiers walk the chain — the image signature, the in-toto attestation signature, the build platform identity inside the attestation — and the verification policy decides whether the chain is acceptable.

GitHub Actions OIDC and artifact attestations — the dominant build path

For estates already on GitHub Enterprise, the dominant build path uses GitHub Actions with OIDC federation to Microsoft Entra, GitHub Artifact Attestations for in-toto SLSA provenance, and a push step that pushes both the image and the attestation to ACR. The pattern is the lowest-friction SLSA 3 implementation because GitHub manages the build platform identity, the attestation signing, and the transparency log. EPC Group documents the reference workflow during the platform phase including the federated credential, the workload identity binding, the Notation or cosign signing step, and the ACR push step. The full GitHub-vs-Azure-DevOps build platform comparison sits at /azure-devops-vs-github-enterprise-microsoft-2026.

Azure DevOps and ACR Tasks — the Microsoft-native build path

For estates standardized on Azure DevOps, the equivalent build path uses Azure Pipelines with workload identity federation to Entra, Microsoft-signed SLSA provenance through the Azure DevOps build service, and a push step to ACR. ACR Tasks is the build-inside-the-registry surface that handles base-image-update-triggered rebuilds the source-driven pipeline does not cover. EPC Group runs hybrid pipelines — Azure DevOps or GitHub Actions for source-driven builds, ACR Tasks for base-image refresh — and ships both paths with the same downstream verification posture so the runtime does not need to know which pipeline produced any given image.

Defender for Containers & ACR hardening

Five controls that make ACR auditor-ready for HIPAA, FedRAMP, and CMMC

Production ACR security stands on five controls that ship natively in the Microsoft stack — Defender for Containers for vulnerability scanning, Private Link for network isolation, customer-managed keys for cryptographic separation, repository-scoped tokens for least-privilege identity, and Azure Policy for management-group-scope enforcement. The broader CNAPP context sits at Defender for Cloud CNAPP guide.

Defender for Containers — push-time and continuous scanning

Defender for Containers scans every image pushed to a Premium ACR on push, surfaces CVE findings with severity and remediation guidance through Defender for Cloud, and continuously rescans images that remain in the registry as the Microsoft Threat Intelligence database updates. Findings flow into Microsoft Sentinel through the unified incident queue so the SOC investigates container CVEs through the same workflow as host, identity, and cloud control-plane findings. EPC Group makes Defender for Containers the non-negotiable baseline for every customer ACR and pairs it with Defender for Cloud regulatory compliance dashboards mapped to HIPAA, NIST, FedRAMP, and CMMC.

Private Link and private endpoints — pulls never traverse the public internet

Premium ACR exposes Private Link endpoints in multiple VNETs and regions; the data path for image pulls resolves to a private IP inside the customer VNET, never traverses the public internet, and never bypasses the Azure Firewall posture the rest of the workload runs behind. The pattern pairs with the multi-region geo-replication story so each region pulls from its in-region replica through its in-region private endpoint. EPC Group ships a hub-and-spoke topology that centralizes the ACR Private Link plane and federates pull access through Entra-aware Private DNS so workload teams consume the registry by canonical name without managing the per-region resolution themselves.

Customer-managed keys and HSM-backed encryption

Premium ACR supports customer-managed key encryption with keys rooted in Azure Key Vault — including Premium Key Vault with HSM-backed keys for regulated workloads. The pattern delivers cryptographic separation between the Microsoft control plane and the customer key material — Microsoft cannot decrypt the registry contents without the customer-controlled key. The control is required by FedRAMP High, several DoD impact levels, and many regulated-industry control matrices. EPC Group ships the Key Vault, the key rotation policy, the disaster-recovery key backup, and the auditor-ready documentation in the foundation phase.

Repository-scoped tokens and Entra-bound identities

Premium ACR supports repository-scoped tokens — Entra-bound identities with permissions scoped to individual repositories and specific actions (pull, push, delete, sign). The pattern delivers least-privilege identity for build pipelines, ISV downstream consumers, and partner integrations. The production access model is exclusively Entra identity (managed identity, Workload ID federation, federated credentials) — admin user, anonymous access, and shared keys are disabled at the registry property level so no static credential is in scope for an attacker.

Azure Policy for ACR — guardrails at management-group scope

Azure Policy initiatives apply at management-group scope to enforce the production-grade ACR baseline across every subscription — Premium tier required, Private Link required, Defender for Containers enabled, customer-managed keys enabled, repository-scoped tokens for non-platform identities, admin user disabled, public network access disabled. The pattern delivers continuous compliance evidence through Resource Graph queries auditors consume as the evidence package without bespoke documentation.

HIPAA

SOC 2

FedRAMP

FINRA

CMMC

GxP

Cost model

Tier fee, storage overage, replication, and Tasks — the ACR cost model

The ACR cost model has four components — per-day tier base fee, per-GiB-per-month storage overage above the included allocation, per-region geo-replication replica charges with cross-region replication bandwidth, and ACR Tasks build minutes plus Defender for Containers per-image scanning. EPC Group ships a per-engagement cost model during the assessment phase and tunes the mix quarterly during the operate phase.

Tier base fee — Basic, Standard, Premium per-day flat charge

Every ACR carries a per-day flat tier charge — Basic is the lowest, Premium the highest with the largest included storage allocation. The headline economic story is that for any production estate the Premium tier base fee is rounding-error compared with the engineering cost of working around the missing Premium-only features (geo-replication, Private Link, signing, customer-managed keys, repository-scoped tokens). EPC Group standardizes Premium for every production registry and reserves Basic for ephemeral dev and learning workloads.

Storage overage — per-GiB per-month for the long tail

Storage usage beyond the included allocation bills per-GiB per-month. For large image estates the long tail (untagged manifests, historical versions, ML model artifacts, Helm charts) accumulates quickly. EPC Group ships an ACR lifecycle management policy in the platform phase — automatic untagged-manifest purge, time-based retention for tagged versions, and manual-tag protection for production releases — so the storage bill tracks active artifacts rather than indefinite retention.

Geo-replication egress — per-region replica plus replication bandwidth

Premium geo-replication adds a per-region per-day charge per replica and a bandwidth charge for the replication data path between regions. The bandwidth cost is dominated by the initial replication of the existing image set and the steady-state cost of newly pushed images. The economic comparison: the replication bandwidth is materially cheaper than the cross-region image-pull bandwidth that a non-replicated registry would incur each time a regional workload pulls from a foreign region. EPC Group models the comparison during the assessment phase to land on the replica count that minimizes the combined cost.

ACR Tasks build minutes and Defender for Containers per-image

ACR Tasks bills per build-minute on the managed build agents. Defender for Containers bills per-image scanned. Both are dominant secondary cost drivers for high-velocity build estates. EPC Group caps Tasks build concurrency, applies image scanning policy to focus Defender on production registries rather than dev sandboxes, and routes high-velocity dev builds to GitHub Actions or Azure DevOps native runners where the per-minute economics are different. The result is a predictable monthly registry bill that the FinOps team can model accurately.

The EPC Group Container Supply Chain Accelerator — five phases, fixed fee

The accelerator anchors on The EPC Group Lifecycle — Assess, Foundation, Platform, Workload, Operate. Fixed-scope between $120,000 and $400,000 depending on registry consolidation count, regional replica footprint, regulatory scope, signing toolchain selection (Notation, cosign, or both), and the depth of pipeline integration across GitHub Actions and Azure DevOps. Senior-architect led, no offshore handoff.

Phase 1 — Assess

Registry footprint, supply-chain posture, and signing model baseline

Phase one inventories every container image in scope, every existing registry (ACR, Docker Hub, AWS ECR, GCP Artifact Registry, self-hosted Harbor or Nexus), and every consumer (AKS, Container Apps, App Service, Azure Functions, virtual machines). EPC Group profiles the supply-chain posture against the SLSA framework, identifies the signing model gap, and produces a costed Premium ACR consolidation plan. Deliverables: image and registry inventory, supply-chain maturity baseline, costed target topology, accelerator scope.

Image and registry inventory across every existing registry surface
Consumer mapping — which workloads pull from which registry and at what frequency
SLSA maturity baseline and gap analysis against the production target level
Costed Premium ACR target topology with regional replica plan and Private Link footprint

Phase 2 — Foundation

Premium ACR plane, Private Link, geo-replication, and identity foundation

Phase two stands up the production ACR plane — Premium tier registries deployed into the hub VNET with regional Private Link endpoints, geo-replication enabled across every region of consumption, customer-managed keys rooted in Azure Key Vault HSM, and admin user / anonymous pulls disabled at the property level. Entra-bound identities replace every static credential. Azure Policy initiatives apply at management-group scope to enforce the baseline against drift.

Premium ACR provisioned in the hub VNET with Private Link across every consumer VNET
Geo-replication enabled across every region of consumption with regional endpoint affinity
Customer-managed keys, HSM-backed key options, and key rotation policy configured
Azure Policy initiatives applied at management-group scope to enforce the production baseline

Phase 3 — Platform — supply chain

Signing identity, Defender scanning, SLSA provenance, and SBOM toolchain

Phase three engineers the supply-chain surface itself — Notation or cosign signing identity rooted in Key Vault HSM, Defender for Containers enabled with policy that fails admission on unresolved critical CVEs, GitHub Actions or Azure DevOps reference workflows with OIDC federation, in-toto SLSA provenance attestations, and SPDX or CycloneDX SBOM generation through Syft attached to every image as an OCI artifact. The platform team productizes the signing-and-attestation surface so application teams consume it as a managed capability.

Notation or cosign signing identity with Azure Key Vault HSM-backed key material
Defender for Containers enabled with CVE policy and Sentinel incident streaming
Reference GitHub Actions / Azure DevOps workflows with OIDC federation and SLSA attestation
SBOM generation through Syft and runtime verification through AKS Image Integrity or Ratify

Phase 4 — Workload

Workload onboarding, base-image refresh, and verification rollout

Phase four onboards the first tranche of workloads to the signed-and-verified registry plane. EPC Group documents the per-workload onboarding pattern — Dockerfile review for hardened base images, ACR Tasks base-image-update triggers wired to every production image, pipeline integration with the signing step, and admission-controller rollout in AKS clusters or registry policy in Container Apps environments. The base-image-refresh rate moves from monthly or quarterly to within hours of upstream Microsoft updates.

First wave of workloads onboarded with documented per-workload onboarding pattern
ACR Tasks base-image-update triggers wired to every production image
Signing step integrated into every production pipeline with signing identity rotation policy
AKS Image Integrity / Ratify or Container Apps registry policy enforced — unsigned images fail closed

Phase 5 — Operate

Lifecycle management, FinOps, and continuous supply-chain compliance

Phase five operationalizes the registry estate. Lifecycle management policy purges untagged manifests and time-expires old tagged versions so the storage bill tracks active artifacts. Quarterly FinOps reviews tune the replica count, the Tasks build concurrency, and the Defender for Containers scan scope. The supply-chain posture is reviewed monthly through Defender for Cloud and Resource Graph against the SLSA, NIST, FedRAMP, and CMMC control matrices the customer is regulated against. Platform upgrades to the signing toolchain, the SBOM toolchain, and the admission-controller surface are scheduled into documented maintenance windows.

ACR lifecycle management policy purges untagged manifests and time-expires old tagged versions
Quarterly FinOps review across tier, geo-replication, Tasks, and Defender scope
Monthly supply-chain posture review against SLSA, NIST, FedRAMP, and CMMC control matrices
Documented upgrade cadence for signing toolchain, SBOM toolchain, and verification controllers

Why EPC Group leads enterprise Azure Container Registry and supply-chain engagements

Years Microsoft consulting

70+

Fortune 500 clients

216+

M&A tenant consolidations

1.83 million

Users migrated

Microsoft Solutions Partner — Infrastructure & Digital App Innovation

Microsoft Solutions Partner with the Infrastructure (Azure) and Digital & App Innovation (Azure) designations covering Azure Container Registry and the broader container supply-chain plane end-to-end, plus four additional designations across Security, Data & AI, Modern Work, and Business Applications.

Four-time Microsoft Press author

Founder Errin O’Connor has nearly three decades of Microsoft consulting leadership and is a four-time Microsoft Press author across Power BI, SharePoint, Azure, and large-scale migrations.

Fixed-fee accelerators

Every Container Supply Chain engagement is fixed-fee with a costed roadmap and a named senior architect on-record from kickoff through go-live. No T&M overruns, no offshore handoff, no junior-analyst-led production cutover.

Compliance-native

EPC Group is compliance-native across HIPAA, SOC 2, FedRAMP-aligned, FINRA, CMMC, and GxP. ACR deployments ship with auditor-ready control matrices, Defender for Cloud regulatory dashboards, and Resource Graph evidence queries.

Frequently asked questions — Azure Container Registry

How does Azure Container Registry compare with Docker Hub for enterprise workloads?

Docker Hub is the public, community-default registry — fine for distributing open-source images, dev-tier workloads, and learning, but materially inadequate for any production enterprise estate. Docker Hub does not offer Private Link, customer-managed keys, regional replication inside the customer cloud perimeter, repository-scoped Entra-bound tokens, or native integration with Defender for Cloud and Microsoft Sentinel. ACR Premium is the registry surface that production-grade Microsoft estates run on — geo-replicated, Private Link-only, Defender-scanned, Notation- or cosign-signed, customer-managed-key encrypted, and Entra-identity-bound end to end. Many enterprises continue to pull from Docker Hub for upstream open-source base images, but mirror those images into ACR through pull-through cache or scheduled ACR Tasks so the production pull path never reaches the public internet and the production image set is fully scanned, signed, and policy-controlled. EPC Group standardizes on ACR for every production registry and treats Docker Hub strictly as an upstream mirror source.

When should an enterprise pick ACR over AWS Elastic Container Registry (ECR) or Google Artifact Registry?

For estates standardized on Microsoft — AKS, Container Apps, App Service for Containers, Azure Functions on containers, Defender for Cloud, Microsoft Sentinel, Entra ID — ACR is the registry that integrates with the rest of the stack without translation. The signing surface (Notation), the scanning surface (Defender for Containers), the identity surface (Entra workload identity), and the policy surface (Azure Policy, Defender for Cloud regulatory compliance dashboards) are all native to ACR; on AWS ECR the equivalent paths involve cosign with Sigstore Fulcio, Inspector or third-party scanners, IAM identity translation, and AWS Config or third-party policy engines. For genuinely multi-cloud estates EPC Group designs hybrid topologies — ACR as the primary signing-and-scanning registry, replicated to ECR or Artifact Registry through scheduled mirror jobs — so the production posture is uniform across clouds without doubling the supply-chain toolchain. Most enterprise estates concentrate on one cloud-native registry; the multi-registry pattern is reserved for genuine multi-cloud production.

How does ACR geo-replication actually work, and when is it required?

Premium ACR active-active geo-replication maintains a synchronized copy of every image in every configured region. The platform exposes a single registry URL — myregistry.azurecr.io — and the data path resolves to the nearest replica through Microsoft DNS using the customer-region affinity. A workload in East US pulls from the East US replica; a workload in West Europe pulls from the West Europe replica; both see the same image set with the same digests. Replication is event-driven — a push to one replica replicates to the others within seconds for steady-state operation. Geo-replication is required when (a) workloads run in two or more Azure regions, (b) any region is critical to recovery time objectives, (c) the cross-region image-pull bandwidth would dominate the registry bill, or (d) any single region is a single point of failure the business cannot tolerate. For any production estate that meets one of those conditions — which is most regulated-industry production estates — geo-replication is mandatory rather than optional. EPC Group enables geo-replication during the foundation phase before workload onboarding begins.

What is cosign signing, and how does it compare with Notation for ACR?

Cosign is the Sigstore-native image signing tool — keyless signing through Fulcio short-lived certificates with transparency log entries in Rekor, alongside the traditional key-based mode. Cosign stores signatures in ACR through the same OCI v1.1 referrers API that Notation uses, so a single Premium ACR is a first-class target for both signing tools. The choice between cosign and Notation comes down to (a) tooling alignment — Notation is Microsoft-and-CNCF, cosign is Sigstore-and-CNCF; (b) the verification surface — AKS Image Integrity is Notation-native, Ratify on AKS supports both, OPA Gatekeeper and Kyverno work with both; and (c) the cryptographic story — Notation uses customer-controlled X.509 with Azure Key Vault HSM-backed keys, cosign keyless uses Fulcio-issued short-lived certificates with Rekor transparency log entries. EPC Group runs both tools depending on customer estate; the verification policy fails closed in either case, so the choice is operational rather than security-determining. For estates already on Sigstore (cross-cloud, GitHub-Actions-heavy, hybrid Kubernetes) cosign is the lower-friction choice; for Microsoft-pure estates that already operate Key Vault HSM and X.509 PKI, Notation is the lower-friction choice.

Is Azure Container Registry HIPAA, FedRAMP, and CMMC compliant?

Azure Container Registry in Azure commercial regions is covered by the Microsoft HIPAA BAA, HITRUST CSF, ISO 27001, SOC 1, SOC 2, SOC 3, FedRAMP-authorized at Moderate, and PCI DSS attestations as part of the Azure platform service compliance scope. ACR in Azure Government regions extends the authorization to FedRAMP High and the applicable DoD Impact Levels; the current GCC High and IL5 scope should be confirmed against the Microsoft Trust Center service-level listing at the time of design. CMMC 2.0 controls map through Azure Policy initiatives that EPC Group ships at management-group scope — Premium tier required, Private Link required, customer-managed keys required, Defender for Containers enabled, public network access disabled, admin user disabled. Every regulated EPC Group ACR engagement is FedRAMP-aligned by design and ships with a documented control matrix, Defender for Cloud regulatory compliance dashboards, and Resource Graph evidence queries auditors will accept. The broader Defender posture is detailed at /microsoft-defender-for-cloud-cnapp-enterprise-2026.

Does ACR support FIPS 140-2 / 140-3 validated cryptography?

Yes. Customer-managed key encryption on Premium ACR is rooted in Azure Key Vault, which supports FIPS 140-2 Level 2 validated software-protected keys (Standard tier) and FIPS 140-2 Level 3 validated HSM-protected keys (Premium tier with managed HSM or Key Vault Premium). For workloads under FIPS-mandated control matrices — federal civilian, DoD, FedRAMP High, certain CMMC profiles — EPC Group provisions Key Vault Premium with HSM-backed keys, configures ACR customer-managed-key encryption against the HSM-backed key, and ships the FIPS attestation documentation as part of the engagement compliance package. The signing identity rooted in the same HSM-backed key inherits the same FIPS attestation. Network controls (Private Link, TLS 1.2+ enforcement) and identity controls (Entra workload identity, federated credentials) operate independently of the cryptographic posture and apply uniformly across both FIPS and non-FIPS deployments.

How do ACR Tasks compare with GitHub Actions or Azure DevOps for building images?

ACR Tasks is a managed build service inside the registry — three trigger types (source-code commit, base-image update, schedule), Docker / Buildah / buildpack build engines, and integration with Defender for Containers scanning on push. ACR Tasks shines for the base-image-update scenario: when Microsoft publishes a security update to mcr.microsoft.com/dotnet/aspnet, every customer image FROM that base auto-rebuilds and is pushed with a new tag within hours. GitHub Actions and Azure DevOps Pipelines are the dominant surfaces for source-driven builds — richer build environments, broader toolchain, deeper integration with branch protection and PR review, and native SLSA provenance through GitHub Artifact Attestations or the equivalent Azure DevOps surface. EPC Group recommends the hybrid pattern: GitHub Actions or Azure DevOps for source-driven builds with full SLSA provenance, ACR Tasks for base-image-refresh and scheduled rebuilds, both pushing to the same Premium ACR with the same signing identity. The runtime verification posture does not care which builder produced the image as long as the signature and provenance chain validate. The full build-platform comparison is at /azure-devops-vs-github-enterprise-microsoft-2026.

What does ACR actually cost — Premium tier, geo-replication, and storage overage?

ACR Premium has a per-day flat tier charge that scales to a modest monthly figure for the registry itself. Geo-replication adds a per-region per-day charge for each additional replica beyond the home region — so a three-region production estate carries three replica charges plus the home registry charge. Storage usage beyond the 500-GiB Premium included allocation bills per-GiB per-month; for large estates the long tail accumulates quickly without lifecycle management. ACR Tasks bills per build-minute; Defender for Containers bills per-image scanned; geo-replication adds replication bandwidth on the data path between regions. The total monthly registry bill for a typical Fortune 500 production estate with three regional replicas, a few TB of total storage, and steady-state build velocity lands in the low-to-mid four figures. EPC Group ships a per-engagement registry cost model during the assessment phase and reviews the Consumption-vs-build-volume tradeoff quarterly during the operate phase. Compared with the engineering cost of working around the missing Premium features — multi-cloud-mirror pipelines, self-managed signing infrastructure, third-party scanning surfaces — Premium ACR is the cheapest path to the production posture every regulated enterprise needs.

Continue exploring the EPC Group enterprise Microsoft library

Azure Container Registry is one plane inside a broader Microsoft cloud orchestration story. These hubs and analyses cover adjacent and complementary territory.

Microsoft Cloud Orchestrator

The end-to-end Microsoft cloud orchestration model under which ACR sits as the registry plane behind every container compute surface.

Azure consulting services

EPC Group Azure consulting service line — landing zones, migrations, governance, and ACR-anchored supply chains at enterprise scale.

Azure Kubernetes Service (AKS) enterprise guide

AKS is the dominant ACR consumer — Image Integrity admission control, Ratify, and signed image enforcement live here.

Azure Container Apps enterprise guide

Container Apps consumes ACR for every workload — registry policy enforces signed-image-only pulls at the environment level.

Microsoft Defender for Cloud CNAPP

Defender for Containers is the Microsoft-native vulnerability scanning surface inside ACR — posture, runtime, and Sentinel streaming.

Azure DevOps vs GitHub Enterprise (Microsoft 2026)

The two production build platforms that push to ACR with SLSA provenance — comparison and decision rules for Microsoft estates.

Digital transformation — Microsoft enterprise 2026

The five-stage EPC Group Lifecycle inside which the Container Supply Chain Accelerator is the registry-and-provenance workstream.

Standards alignment library

NIST CSF 2.0, ISO 27001, HIPAA, FedRAMP, FINRA, CMMC, and GxP control mappings for ACR and the broader Microsoft platform.

Production container supply chains, designed and operated by senior Microsoft architects

Book a Container Supply Chain briefing with an EPC Group senior architect. Two-hour working session — registry inventory, signing-toolchain decision, SLSA target level, costed Premium ACR topology, accelerator scoping. Zero obligation, board-ready output.

Book the briefing 888-381-9725

‌
‌
‌

‌
‌