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

· Eurtifact Platform Team

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 verify that those components do not compromise the product’s cybersecurity. This is not a recommendation. It is an enforceable obligation with penalties up to EUR 15 million or 2.5% of global annual turnover.

Article 14 reporting obligations apply from September 2026. Full application of all remaining provisions, including Art. 13(5), takes effect in 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. Recitals (34)–(35) specify five concrete actions manufacturers must take when integrating third-party components, including FOSS:

  1. Verify CE marking on the component (where available)
  2. Verify the component receives regular security updates — check actual update history, not project activity
  3. Verify the component is free from known vulnerabilities — check the EU vulnerability database or public vulnerability databases
  4. Carry out additional security tests
  5. If the manufacturer discovers a vulnerability in a FOSS component, inform the maintainer and provide the fix

During the transitional period before full application, if CE marking is unavailable for a component (as it will be for most open-source software), alternative due diligence methods are acceptable. 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 (Art. 24) have a light-touch regime. 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?

CRA Article 6 states products may only be placed on the market if there are no known exploitable vulnerabilities at time of placement. This applies to components, not just the final product.

SBOM and dependency awareness:

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

Recital (22) notes that ADCO (the Administrative Cooperation Group) can request SBOMs from manufacturers. Market surveillance authorities can conduct Union-wide dependency assessments. 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(2) requires updating the risk assessment “throughout the support period.” 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(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 own vulnerability handling (Art. 13(6)), SBOM disclosure (Art. 13(24)), and reporting obligations (Art. 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

  • CRA 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. It requires continuous monitoring of vulnerability status, upstream maintenance activity, and dependency changes.
  • The obligation falls on the integrator (manufacturer), not the upstream project. Open-source projects have a lighter regime under Art. 24, but their users do not.
  • Evidence must be retained and queryable. “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. It is not legal advice. For compliance questions specific to your product or organisation, consult qualified legal counsel.