SBOM

CRA and Third-Party Components: You Own the Risk, Even If You Didn't Write the Code

Last updated · July 27, 2026

Most engineering teams already know they need to write secure code. Fewer have absorbed the harder implication of the Cyber Resilience Act: the security of every component you integrate is also your problem. A vulnerability in a library you didn't write, maintained by a community you don't control, can still put your CE marking, your technical file, and your market access at risk.

This post explains what Regulation (EU) 2024/2847 actually requires of manufacturers when it comes to third-party and open-source components - and what to do about it before the deadlines arrive.

General guidance, not legal advice. This post explains the regulation in plain English for engineering and product teams. For advice specific to your situation, consult a qualified legal professional.

Key points

Article 13 makes you responsible for the cybersecurity of every component you integrate, including free and open-source software - not just the code you wrote yourself.
Due diligence is a legal duty, not a best practice. You must exercise it before integration and keep evidence that you did.
An SBOM is mandatory (Annex I, Part II(1)): machine-readable, covering at least top-level dependencies, kept in your technical documentation.
Open-source stewards cannot be fined (Article 24 / Article 64). That means you cannot offload your CRA obligations onto an unpaid maintainer - the responsibility stays with you.
Reporting obligations start 11 September 2026. Without an SBOM and vulnerability monitoring in place, you will not be able to meet the 24-hour early-warning deadline when a component CVE lands.
Penalties reach up to €15 million or 2.5% of global annual turnover, whichever is higher (Article 64).

What Article 13 actually says

The CRA entered into force on 10 December 2024. Reporting obligations under Article 14 apply from 11 September 2026, and the regulation is fully applicable from 11 December 2027.

Article 13 is the core manufacturer obligations article. Paragraph 5 is the one that catches teams off guard. It states that manufacturers must exercise due diligence when integrating components sourced from third parties - including components of free and open-source software - so that those components do not compromise the cybersecurity of the product with digital elements.

That is not a soft expectation. It is a binding obligation, and it applies to every component in your product regardless of where it came from.

Paragraph 6 adds a second duty: if you identify a vulnerability in an integrated component - including an open-source component - you must report it to the person or entity maintaining that component, and address and remediate it in accordance with Annex I, Part II. If you develop a fix yourself, you are expected to share the relevant code or documentation with the maintainer.

The European Commission's CRA summary puts it plainly: if the manufacturer integrates third-party components, it needs to exercise due diligence so that those components do not compromise the cybersecurity of its product.

The manufacturer stays responsible for the whole product

This is the point that most supply-chain conversations miss. The CRA does not let you partition responsibility. You are responsible for the product's essential requirements (Annex I), the Article 13 risk assessment, vulnerability handling across the support period, CE marking, the EU Declaration of Conformity, and the technical documentation - which must be retained for at least 10 years after placing the product on the market.

The CRA presumes a support period of at least five years unless the expected product lifetime is shorter. The third-party components you integrate today need to be supportable for that entire window.

The open-source trap

Open-source software stewards - foundations and organisations that provide sustained support for open-source projects intended for commercial use - have lighter, tailored duties under Article 24. Crucially, open-source software stewards cannot be fined for any infringement of the CRA under Article 64(10).

That sounds like good news for the open-source ecosystem. For you as a manufacturer, it has a sharp implication: you cannot rely on a steward or maintainer to absorb your compliance obligations. The moment you integrate open-source software into a commercial product in CRA scope, you become responsible for ensuring that software meets CRA requirements. There is no contractual mechanism to transfer that liability to an unpaid volunteer or a foundation.

Do not assume a maintainer will patch on your timeline. When a CVE lands in a popular library, the maintainer has no legal obligation to fix it within your support period. You need a plan to patch or replace the component yourself — and that plan needs to exist before you ship.

For more on how the CRA treats open-source integrators versus stewards, see our full open-source guide.

What to do: a practical due-diligence programme

This is the part that matters most. The regulation sets the obligation; the following is how to operationalise it. None of this requires a legal team - it requires a repeatable process.

Step 1 - Screen before you integrate

Due diligence happens before the component goes into your product, not after a CVE lands. A short written questionnaire is the practical evidence that you exercised it. For each significant third-party or open-source component, record answers to:

Does the component have a documented vulnerability handling process and a security contact or CVD path?
Are known vulnerabilities tracked against a public database (NVD, OSV, etc.)?
Is an SBOM available from the supplier, covering transitive dependencies?
What is the declared support period and end-of-life date? Does it cover your own product's support period?
Does the component ship with secure defaults, or does it require hardening on your side?

Keep the completed questionnaire in your technical file. It is your evidence of due diligence.

For open-source components where there is no supplier to ask, the questionnaire becomes a self-assessment. Check the project's security policy (SECURITY.md), its CVE history, its release cadence, and whether it has an active maintainer. Record what you found and when.

Step 2 - Flow obligations down in contracts

For commercial suppliers, the contract is where due diligence becomes enforceable. Consider including:

Clause	What it should require
SBOM provision	Supplier provides a machine-readable SBOM covering transitive dependencies, updated on each release
Vulnerability notification SLA	Timely notification of newly discovered vulnerabilities, with a defined response window
Security updates	Commitment to provide security updates for at least the support period you declare for your product
End-of-life notice	Advance notice (e.g. 12 months) before end of support or end of life
Right to evidence	Right to request audit evidence or attestation of the supplier's own security practices
Cooperation on reporting	Supplier cooperates with your Article 14 reporting obligations if a vulnerability in their component triggers a notification

You do not need all of these in every contract. Calibrate the depth of obligations to the criticality of the component and the risk it introduces.

Step 3 - Handle open source differently

There is often no supplier to contract with. That shifts the full burden of due diligence onto you:

Pin and record versions. Floating dependencies are an audit and vulnerability-management problem. Lock versions and record why you chose them.
Monitor continuously. Subscribe to vulnerability feeds (NVD, OSV, GitHub Advisory Database) for every component in your SBOM. Automate this where possible - manual monitoring does not scale.
Have a replacement plan. If a component reaches end of life during your product's support period, you need a path to patch or replace it. Identify that path before you ship.
Watch for abandoned projects. An unmaintained component with no active security response is a liability. Factor maintenance health into your pre-integration screen.

Step 4 - Keep it all in the technical file

The SBOM, the due-diligence records, and the risk assessment that references component risks all belong in your Annex VII technical documentation. The SBOM must be machine-readable - CycloneDX and SPDX are the widely used formats that satisfy the "commonly used, machine-readable format" requirement of Annex I, Part II(1). It covers at least top-level dependencies and does not need to be made public, but must be available to market surveillance authorities on request.

Your own coordinated vulnerability disclosure process also needs to be able to act on a vulnerability that originates in a component. If a CVE drops in a library you ship, the 24-hour early-warning clock starts when you become aware of it - not when the maintainer patches it.

See our SBOM starter guide for format choices, tooling, and what the technical file needs to contain.

A decision tool: is your component due diligence sufficient?

Use this interactive checklist to assess where your current process has gaps.

Putting it together: what your technical file needs to show

When a market surveillance authority asks for your technical documentation, they will expect to see evidence of a coherent approach to component risk - not just a list of libraries. That means:

An up-to-date, machine-readable SBOM (Annex I, Part II(1))
A risk assessment (Article 13(3)) that explicitly addresses component risks, not just product-level risks
Records of pre-integration due diligence for significant components
Contract terms or equivalent controls for commercial suppliers
A vulnerability monitoring process with documented ownership
Evidence that your CVD process covers component-originated vulnerabilities

None of this is separate from your broader CRA compliance work. The SBOM feeds the risk assessment; the risk assessment informs the vulnerability handling process; the vulnerability handling process feeds Article 14 reporting. It is one connected system, and the component due-diligence layer is what makes it credible.

For a sequenced view of the full compliance programme, see the CRA compliance checklist and readiness roadmap. For key dates, see the CRA deadlines page.

The timeline pressure is real

Article 14 reporting obligations - including the 24-hour early-warning notification to ENISA and the national CSIRT for actively exploited vulnerabilities - apply from 11 September 2026. That deadline applies to products already on the EU market, not just new releases.

Without an SBOM and continuous vulnerability monitoring in place before that date, you will not be able to determine whether a newly disclosed CVE affects your product in time to meet the reporting window. The SBOM is not a compliance artefact you build at the end - it is the operational tool that makes the rest of the system work.

Full conformity assessment, CE marking, and the complete set of essential requirements apply from 11 December 2027. That is the outer deadline, not the starting line.

Stay current on CRA implementation. Harmonised standards and Commission guidance are still being published. Subscribe to The CRA Brief — our free newsletter — to get plain-English updates as implementing acts, delegated regulations, and ENISA guidance land. Sign up here.

Further reading on CRA Facts:

Official sources: