Vulnerability in a Third-Party Component: Do You Have to Report It Under the CRA?
Updated 20 September 20262 min read
Almost every connected product is built on third-party components: an embedded Linux kernel, an open-source TLS library, a vendor SDK. When a widely used component is found to be vulnerable, hundreds of manufacturers are affected at once. Does each one have to file an Article 14 report?
The European Commission's guidance on the application of the CRA (C(2026) 5252, paragraph 218) answers directly. The test is not whether the component is vulnerable. It is whether the vulnerability has been exploited in your product.
The test
| Situation | Mandatory Article 14 report? |
|---|---|
| Your product contains an actively exploited vulnerability originating from a third-party component | Yes |
| The component is vulnerable, but the vulnerable code cannot be exploited in your product — for example because it is not reachable | No |
| The component is vulnerable and exploitable, but it has not been exploited in your product | No |
In the last two cases the vulnerability does not qualify as an actively exploited vulnerability contained in your product, so it is not subject to mandatory reporting for you.
"No" does not mean "nothing to do"
Where the answer is no, three things still apply:
- You may notify voluntarily under Article 15.
- You must still handle the vulnerability under Annex I, Part II — remediate without delay, provide security updates, where applicable.
- You must report it upstream to whoever manufactures or maintains the component, under Article 13(6).
Reporting upstream: four rules
Paragraph 223 of the guidance sets out how:
- Report only in respect of the version of the component you actually integrate.
- Use the maintainer's security policy, coordinated disclosure process or designated channel where one exists.
- You are not required to report upstream where you can confirm the maintainer is already aware of the vulnerability.
- Check public vulnerability databases, project advisories and issue trackers first, to avoid duplicate reports.
Document the "not reachable" finding
A conclusion that vulnerable code is not reachable in your product is exactly the kind of judgement an authority may ask you to substantiate. Record it with the analysis behind it:
- the component version integrated;
- the build configuration — is the vulnerable module compiled in at all?
- the call-path evidence — can any input reach the vulnerable function?
- who made the assessment, and when.
"We looked and it did not seem relevant" is not a finding.
Sources
- European Commission, Guidance on the application of the CRA, C(2026) 5252, paragraphs 218 and 222–223
- Regulation (EU) 2024/2847, Articles 13(6), 14 and 15; Annex I, Part II
Position as at 20 September 2026. General information, not legal advice.