CRA Art. 13(5): The Due Diligence Obligation Most Teams Overlook

· Yunus Yildiz

Context

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) creates a specific obligation that has received less attention than SBOM requirements or vulnerability reporting deadlines: Article 13(5) due diligence on third-party components.

Every organisation that integrates third-party software components — including open-source container images, libraries, and packages — into a product placed on the EU market is legally required to exercise due diligence so that those components do not compromise the product's cybersecurity. This is not a recommendation. It is an enforceable obligation. Under Article 64(2), non-compliance with the obligations in Article 13 is subject to administrative fines of up to EUR 15 000 000 or 2.5 % of total worldwide annual turnover, whichever is higher.

Article 14 reporting obligations apply from 11 September 2026. Full application of the remaining provisions, including Art. 13(5), takes effect on 11 December 2027.

Reality Check

Common Belief

"We use well-known open-source projects. They have large communities and many eyes on the code. That is sufficient due diligence."

Why That's Incomplete

The CRA does not recognise reputation or community size as due diligence. Recital (34) sets out the actions that constitute appropriate due diligence on integrated components, including FOSS — to be applied as one or more of:

  1. Verify CE marking on the component (where available)
  2. Verify the component receives regular security updates — for example by checking its security updates history
  3. Verify the component is free from vulnerabilities registered in the European vulnerability database established under Article 12(2) of Directive (EU) 2022/2555, or in other publicly accessible vulnerability databases
  4. Carry out additional security tests

In addition, where the manufacturer identifies a vulnerability in a component (including a FOSS component) during due diligence, Recital (34) and Article 13(6) require it to inform the upstream maintainer, address and remediate the vulnerability, and, where applicable, share the applied security fix.

Immediately after the transitional period, manufacturers may not be able to verify CE marking on integrated components (as will be the case for most open-source software while the regulation is still rolling out). Recital (35) provides that "a manufacturer integrating such components should exercise due diligence through other means." But "we trust the project" is not an alternative method. It is the absence of one.

The obligation is on the integrator, not the upstream project. Open-source software stewards have a lighter regime under Article 24. But the organisation that pulls an image from Docker Hub and ships it to customers has the full weight of Art. 13(5).

Engineering Implications

What Due Diligence Looks Like in Practice

For each upstream component integrated into a product, the manufacturer needs evidence of:

Update history verification:

  • When was the last security update published?
  • What is the release cadence? Are security patches released separately from feature updates?
  • Is there a documented support period or end-of-life date?

For container images, this translates to tag history analysis. An image with 200 tags and regular patch releases demonstrates active maintenance. An image whose last update was 18 months ago does not.

Vulnerability status verification:

  • What are the current known vulnerabilities in this component?
  • What is the severity distribution (critical, high, medium, low)?
  • Are there known exploitable vulnerabilities without available patches?

Annex I Part I point (2)(a) requires products with digital elements to be "made available on the market without known exploitable vulnerabilities." Article 6 makes meeting that essential requirement a precondition for placing the product on the market, and Article 13(5) extends manufacturer due diligence to integrated components — so a known exploitable vulnerability in a component is a compliance issue for the integrator, not just for the upstream publisher.

SBOM and dependency awareness:

  • What are this component's own dependencies?
  • Do those transitive dependencies introduce additional vulnerability exposure?

Annex I Part II point (1) requires manufacturers to draw up an SBOM for each product as part of their vulnerability handling. Under Article 13(25) — explained in Recital (22) — ADCO may decide to conduct a Union-wide dependency assessment for specific product categories, and market surveillance authorities may then request the relevant SBOMs from manufacturers. The SBOM is not just a compliance artifact — it is the foundation of due diligence.

The Scale Problem

A typical Kubernetes deployment pulls 30-80 distinct container images. Each image contains an operating system layer, application dependencies, and configuration. A single image can contain 200-500 packages.

Due diligence on each of these components, repeated at every update, is not feasible as a manual process. It requires:

  • Automated vulnerability scanning of every image before it enters the deployment pipeline
  • Tag and version tracking to verify ongoing upstream maintenance
  • SBOM generation to map the dependency tree
  • An audit trail linking each component to its due diligence evidence

This is infrastructure, not a quarterly review.

Failure Modes

Pattern 1: Due Diligence at Procurement, Not at Runtime

An organisation evaluates a container image before adopting it. Six months later, the image has three critical CVEs. No one notices because due diligence was a one-time procurement check.

CRA due diligence is continuous. Article 13(3) requires the cybersecurity risk assessment to be "documented and updated as appropriate during a support period." Article 13(8) requires manufacturers to ensure, for the duration of that support period, that vulnerabilities in the product — including its components — are handled effectively in accordance with Annex I Part II. A component that was safe at adoption can become a compliance failure if its vulnerability status changes and the manufacturer does not re-evaluate.

Pattern 2: Scanning Without Provenance

Teams run Trivy or Grype on container images and record the scan results. But the scan is performed on an image pulled directly from a public registry over the internet. There is no verification that the image received is the image the upstream publisher intended to distribute.

Due diligence includes integrity. If an image is modified in transit or substituted at the registry level, the scan results apply to the wrong artifact. Signature verification (Cosign, Notation) and digest pinning close this gap.

Pattern 3: No Evidence of Upstream Maintenance

A compliance officer asks: "How do we know this component receives regular security updates?" The engineering team points to the project's GitHub repository and says "it's active."

This is not evidence. Evidence is: the image has published 14 security-tagged releases in the past 12 months, the most recent patch was 3 days ago, and the project has a documented security policy. This data must be captured and retained, not observed informally.

What "Good" Looks Like

A system that satisfies Art. 13(5) due diligence has these properties:

  1. Curated component intake: Upstream components enter through a controlled process. Each component is evaluated against due diligence criteria before it is available to product teams. Not every public image is automatically trusted.

  2. Continuous vulnerability monitoring: Every component is scanned at intake and re-scanned on a regular cadence. Results are stored with the component, not in a separate system that can fall out of sync.

  3. Upstream maintenance tracking: Tag history, release cadence, and security patch frequency are recorded as metadata for each component. Components that stop receiving updates are flagged for review or removal.

  4. SBOM per component: Each component has a machine-readable SBOM (CycloneDX or SPDX) documenting its dependencies. This feeds into the product-level SBOM required by Annex I Part II point (1).

  5. Audit trail: Every due diligence action — scan, signature verification, maintenance check — is logged with timestamp, actor, and result. When an auditor asks "what due diligence did you perform on component X?", the answer is a query, not a meeting.

  6. Quarantine-before-trust: New components are isolated until due diligence is complete. They are not available for use in products until scanning and verification pass. This prevents the common pattern of "we'll scan it later" turning into "we shipped it unscanned."

Limits & Trade-offs

This approach does not:

  • Replace upstream responsibility: Due diligence does not make the integrator responsible for fixing upstream vulnerabilities. It requires awareness and timely response — including ceasing to use a component if it becomes a risk.
  • Cover all CRA obligations: Art. 13(5) is one of 25 paragraphs in Article 13. Due diligence on components must be combined with the manufacturer's overall vulnerability handling under Annex I Part II and Article 13(8), upstream reporting and remediation when a vulnerability is identified in a component (Article 13(6)), SBOM generation (Annex I Part II point (1)), and the reporting obligations under Article 14.
  • Provide legal certainty during transition: Until harmonised standards are published and enforcement precedents are established, what constitutes "sufficient" due diligence remains somewhat interpretive. The CRA provides the framework; practice will define the floor.
  • Scale without tooling: Manual due diligence on dozens of upstream components with hundreds of transitive dependencies is not sustainable. Organisations that do not invest in automated component governance will face a resource problem that grows with every dependency they add.

Key Takeaways

  • Art. 13(5) creates a specific, enforceable due diligence obligation for every third-party component integrated into a product — including open-source container images and libraries.
  • Due diligence is not a one-time evaluation. Article 13(3) requires the risk assessment to be updated during the support period, and Article 13(8) requires effective vulnerability handling for the product, including its components, throughout that period.
  • The obligation falls on the integrator (manufacturer), not the upstream project. Open-source software stewards have a lighter regime under Art. 24; their downstream users do not.
  • Recital (34) names the concrete due diligence actions: checking CE marking, verifying security update history, checking the EU vulnerability database (or other public databases) for known vulnerabilities, and carrying out additional security tests. "We checked it" is not evidence — timestamped scan results, version histories, and SBOM records are.
  • Organisations pulling 30-80 container images into Kubernetes deployments need automated component governance infrastructure. Manual processes do not scale to CRA requirements.

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 product or organisation, consult qualified legal counsel.