Container Supply Chains and EU Sovereignty Under the CRA

· Updated · Yunus Yildiz

Corrected 17 September 2026. An earlier version said the importer obligation in Article 19(3) was already binding. It applies from 11 December 2027 under Article 71(2). The post also now notes the Article 32(5) route for free and open-source container runtimes.

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 — placing them within the scope of mandatory third-party conformity assessment under Article 32.

  2. Article 19(3) requires importers to inform market surveillance authorities where they have reason to believe a product presents a significant cybersecurity risk in light of non-technical risk factors. The authorities then follow the procedure in Article 54(2), which explicitly requires them to consider non-technical risk factors — in particular those established by Union-level coordinated security risk assessments under Article 22 of Directive (EU) 2022/2555 (NIS2).

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 of products with digital elements may pose a strategic risk that needs to be addressed at Union level, especially where the products with digital elements are intended for the use by essential entities ... Such risks may be linked, but not limited, to the jurisdiction applicable to the manufacturer, the characteristics of its corporate ownership and the links of control to a third-country government where it is established, in particular where a third country engages in economic espionage or irresponsible state behaviour in cyberspace and its legislation allows arbitrary access to any kind of company operations or data ... and can impose obligations for intelligence purposes without democratic checks and balances, oversight mechanisms, due process or the right to appeal to an independent court or tribunal.

This is not vague guidance. Article 54(2) requires market surveillance authorities, when determining the significance of a cybersecurity risk, to "also consider non-technical risk factors, in particular those established as a result of Union level coordinated security risk assessments of critical supply chains carried out in accordance with Article 22 of Directive (EU) 2022/2555." Article 19(3) is the importer-side trigger: where an importer has reason to believe a product presents a significant cybersecurity risk in light of non-technical risk factors, the importer shall inform the market surveillance authorities, which then apply the Art. 54(2) procedure.

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 any specific registry constitutes a "high-risk" dependency in the sense of Recital (58) depends on the evolving EU coordinated risk assessments under NIS2, and the obligation on importers to flag non-technical risk concerns to authorities applies from 11 December 2027, with the rest of the Regulation (Article 71(2)).

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) fall into the category requiring third-party conformity assessment under Article 32 once full application takes effect on 11 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 transition, as contemplated in Recital (35).

Engineering Implications

Container Runtimes as Class II Products

Annex III Class II item 1 lists "hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments." This classification means:

  • Self-assessment (Module A) under Annex VIII is not available for Class II products. Container runtime publishers must use Module B+C (EU-type examination + conformity to type) or Module H (full quality assurance), both involving a notified body — see Article 32 and Annex VIII.
  • This applies to the runtime itself, not to application containers running on top of it.
  • Organisations integrating these runtimes into their own products must exercise Article 13(5) due diligence on the component.

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 11 December 2027 is an open question. Recital (35) acknowledges that immediately after the transitional period a manufacturer may not be able to verify CE marking on integrated components and provides that "a manufacturer integrating such components should exercise due diligence through other means." After full application, the absence of third-party conformity assessment on a Class II product creates a compliance gap for every organisation that integrates it into a product placed on the EU market.

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 sets a regulatory floor; nothing in the regulation prevents an organisation from applying stricter internal procurement criteria. Article 5(2) requires Member States to ensure CRA compliance is taken into consideration when procuring products with digital elements; Article 5(1) further allows Member States to impose additional cybersecurity requirements for specific purposes such as national security or defence.

  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

  • Annex III Class II classifies container runtime systems (containerd, CRI-O, Docker) as Important Class II products. Under Article 32(3), they require EU-type examination + production control (modules B+C), full quality assurance (module H), or a certification scheme at assurance level at least "substantial"; module A self-assessment is not available. The exception is free and open-source software that publishes its technical documentation, which can use any Article 32(1) procedure (Article 32(5)).
  • From 11 December 2027, Article 54(2) makes third-country supply chain risk a binding legal consideration for market surveillance authorities, cross-referencing the Union-level coordinated risk assessments under Article 22 of NIS2. Article 19(3) is the importer-side trigger that brings products under that procedure when non-technical risk factors are suspected.
  • 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). Article 13(5) due diligence evidence must exist before the image is integrated into a product.
  • The CRA sets a floor, not a ceiling. Different internal teams operating under different risk profiles can apply different thresholds to the same mirror; Article 5 makes CRA compliance a procurement consideration for Member States and allows additional requirements for specific purposes such as national security.

This article reflects the Eurtifact platform team's reading of CRA (EU) 2024/2847 as of February 2026. Article and Annex references were verified against the consolidated EUR-Lex text (CELEX 32024R2847) and are linked to the on-site CRA explorer. It is not legal advice. For compliance questions specific to your organisation's supply chain architecture or CRA obligations, consult qualified legal counsel.