Container Supply Chains and EU Sovereignty Under the CRA

· Eurtifact Platform Team

Context

Two provisions in the Cyber Resilience Act have direct implications for how organisations architect their container image supply chains:

  1. Annex III Class II classifies “hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments” as Important Class II products — requiring mandatory third-party conformity assessment.

  2. Article 19(3) makes it a binding obligation for importers to consider non-technical supply chain risk factors from NIS2 Article 22 coordinated risk assessments. Article 54(2) extends this obligation to market surveillance authorities evaluating products.

Together, these provisions mean that container infrastructure is now a regulated product category, and the jurisdiction from which you source it is a compliance-relevant decision.

Reality Check

Common Belief

“We pull official images from Docker Hub. They are maintained by reputable organisations. Where they are hosted is an operational detail, not a compliance concern.”

Why That’s Incomplete

The CRA treats the supply chain as a regulated surface, not just an operational one. Recital (58) is explicit:

Dependencies on high-risk suppliers from countries that engage in economic espionage, allow arbitrary government access to data, lack democratic oversight, or impose intelligence obligations without judicial review — are a strategic risk.

This is not vague guidance. Article 19(3) translates it into a binding obligation: importers “shall take into account” the results of NIS2 Article 22 coordinated supply chain risk assessments. Article 54(2) requires market surveillance authorities to do the same when evaluating whether a product presents a significant cybersecurity risk.

For container images, this creates a specific problem. Most public registries are operated by US-headquartered companies, hosted on US infrastructure, and subject to US legal jurisdiction — including the CLOUD Act, which enables cross-border data access requests. Whether this constitutes a “high-risk” dependency under CRA Recital (58) depends on the evolving EU coordinated risk assessments under NIS2, but the obligation to consider the question is already binding.

Separately, the Annex III Class II classification of container runtimes means that the runtime images your Kubernetes clusters depend on (containerd, CRI-O, or Docker) will need mandatory third-party conformity assessment by December 2027. Organisations consuming these images need to verify that the upstream publisher has completed this assessment — or document their alternative due diligence during the transitional period.

Engineering Implications

Container Runtimes as Class II Products

Annex III Class II item 1 lists “hypervisors and container runtime systems.” This classification means:

  • Module A self-assessment is not sufficient. Container runtime publishers must use Module B+C (EU-type examination + production control) or Module H (full quality assurance), both involving a notified body.
  • This applies to the runtime itself, not to application containers running on top of it.
  • Organisations using these runtimes must verify the upstream publisher’s conformity status as part of their Art. 13(5) due diligence.

In practice, most container runtime projects are open-source and developed by foundations (CNCF, Docker Inc.). Whether they will obtain Class II conformity assessment by December 2027 is an open question. During the transitional period (Art. 69), alternative due diligence is acceptable. After full application, the absence of third-party conformity assessment on a Class II product creates a compliance gap for every organisation that depends on it.

The Jurisdiction Question

When an organisation pulls a container image from a US-hosted registry, several jurisdiction-relevant events occur:

  1. Data transit: The image (and any metadata requests) traverse non-EU infrastructure
  2. Integrity dependency: The organisation trusts the registry operator to serve unmodified images
  3. Availability dependency: The organisation depends on a service outside EU legal control
  4. Metadata exposure: Pull events reveal what software the organisation uses, at what frequency, from which IP addresses

None of these are new technical risks. What is new is that the CRA makes them compliance-relevant. An auditor can now ask: “What supply chain risk assessment did you perform on your container image sources?” and the answer must address jurisdiction, not just vulnerability scanning.

What Architecture Needs to Account For

A container supply chain architecture that addresses both CRA provisions has these requirements:

Image sourcing:

  • Upstream images pulled into an EU-hosted, EU-operated mirror before distribution to production clusters
  • Cryptographic verification (signature + digest) at the mirror boundary — images are verified against upstream publisher signatures, then re-signed with an organisational key
  • Mirror operates as a quarantine: images are scanned and verified before being available to clusters

Audit evidence per image:

  • Source registry and original digest (provenance)
  • Signature verification result
  • Vulnerability scan results at time of intake
  • SBOM generated at intake
  • Upstream publisher conformity status (CE marking, if available)
  • Timestamp and actor for each operation

Jurisdiction documentation:

  • Where is the mirror hosted? (Must be EU for sovereignty claims)
  • What legal jurisdiction governs the mirror operator?
  • Are there cross-border data access risks?
  • What happens if the upstream registry becomes unavailable?

This is not a proxy cache. A proxy cache forwards requests to the upstream registry and caches responses. It does not provide isolation, independent scanning, or jurisdiction separation. A compliance-relevant mirror is a separate system that takes custody of artifacts and provides its own integrity guarantees.

Failure Modes

Pattern 1: Mirror Without Sovereignty

An organisation deploys a pull-through cache (Harbor proxy, Artifactory remote repository) pointing to Docker Hub. The cache is hosted in an EU data centre.

This looks like sovereignty but is not. Pull-through caches still depend on the upstream registry for cache misses, metadata updates, and tag resolution. If the upstream registry modifies or removes an image, the cache follows. The organisation has not taken independent custody of the artifact.

A compliance-relevant mirror pushes images into its own storage, verifies them independently, and serves them from that storage without runtime dependency on the upstream registry.

Pattern 2: Scanning at Deployment, Not at Intake

Vulnerability scanning is configured as a Kubernetes admission webhook. Images are scanned when pods are created.

This is too late for CRA due diligence. By the time an image reaches the admission controller, it has already entered the organisation’s infrastructure from an external source. If the image was modified in transit, the scan results apply to the modified image. If the image is rejected, the deployment fails — but the due diligence gap (using unvetted images) has already been exposed.

Scanning at intake — when the image enters the mirror — provides due diligence evidence before the image is available for use.

Pattern 3: Sovereignty Claims Without Evidence

An organisation states in compliance documentation: “All container images are sourced through our EU-hosted registry.” But there are no logs showing where images originated, when they were verified, or whether any images were pulled directly from public registries by developers or CI/CD pipelines.

Sovereignty is an auditable claim. It requires evidence: network policies preventing direct pulls from external registries, pull logs showing all images served from the mirror, and configuration preventing fallback to public registries.

What “Good” Looks Like

A container supply chain architecture that addresses CRA sovereignty and Class II concerns has these properties:

  1. EU-hosted, EU-operated mirror: All container images consumed by production systems are served from infrastructure within EU jurisdiction. The mirror operator is subject to EU law, not third-country legal orders.

  2. Quarantine-before-distribution: Images enter the mirror in a quarantine state. They are scanned, verified, and have SBOMs generated before being promoted to a distribution state available to clusters.

  3. Signature chain: Upstream publisher signatures are verified at intake. The mirror re-signs promoted images with an organisational key. Downstream consumers verify the organisational signature, creating a chain of custody from upstream publisher to production deployment.

  4. Per-consumer policy: Different teams or environments may have different risk tolerances. The mirror supports per-consumer distribution policies — one team may accept images with medium-severity findings while another blocks them. The CRA (Art. 5(2)) explicitly allows entities to impose requirements beyond the regulatory minimum for procurement.

  5. Upstream conformity tracking: For Class II products (container runtimes), the mirror tracks whether the upstream publisher has obtained third-party conformity assessment. During the transitional period, it records what alternative due diligence was performed.

  6. Complete audit trail: Every image intake, scan, verification, promotion, and distribution event is logged immutably. The audit trail answers: where did this image come from, when was it verified, what was its vulnerability status, and who approved its use?

Limits & Trade-offs

This approach does not:

  • Eliminate upstream dependency: A mirror reduces runtime dependency on external registries but does not eliminate the need for upstream images. When upstream publishes a security patch, the mirror must pull and process it. The dependency shifts from “operational availability” to “update sourcing.”
  • Solve the Class II conformity gap: If upstream container runtime publishers do not obtain Class II conformity assessment, organisations using those runtimes face a compliance gap regardless of their mirror architecture. The mirror provides evidence of alternative due diligence during the transitional period, but this is a temporary measure.
  • Remove all jurisdiction risk: An EU-hosted mirror mitigates registry-side jurisdiction risk but does not address risks in the software itself (e.g., backdoors, supply chain attacks at the source code level). Sovereignty of hosting is one layer; trust in the software requires additional controls (scanning, SBOM analysis, provenance verification).
  • Apply to all organisations equally: Smaller organisations may not need a full sovereign mirror. The CRA applies proportionally — the risk assessment determines the appropriate controls. For an organisation deploying 5 container images, a documented manual review process may suffice.

Key Takeaways

  • CRA Annex III Class II classifies container runtimes (containerd, CRI-O, Docker) as Important Class II products requiring mandatory third-party conformity assessment. Organisations using these runtimes must track upstream conformity status.
  • Article 19(3) and Article 54(2) make third-country supply chain risk a binding legal consideration, not an optional security best practice. Where you source container images from is now a compliance question.
  • A pull-through cache is not a sovereign mirror. Compliance-relevant mirrors take independent custody of artifacts, verify them, and serve them without runtime dependency on upstream registries.
  • Scanning must happen at intake (when the image enters the mirror), not at deployment (when it reaches Kubernetes). Due diligence evidence must exist before the image is available for use.
  • Per-consumer distribution policies are explicitly supported by CRA Art. 5(2), which allows entities to impose requirements beyond the CRA minimum for procurement. Different teams operating under different risk profiles can apply different thresholds to the same mirror.

This article reflects the Eurtifact platform team’s reading of CRA (EU) 2024/2847 as of February 2026. It is not legal advice. For compliance questions specific to your organisation’s supply chain architecture or CRA obligations, consult qualified legal counsel.