A known open-source vulnerability in your product: does the CRA's 24-hour clock start?

A new CVE lands against an open-source library that ships inside your product. Article 14 of the EU Cyber Resilience Act has applied since 11 September 2026. Does the 24-hour reporting clock start?

Not on its own. A known vulnerability in an open-source component engages two different CRA obligations with two different triggers. Most of the confusion we see comes from treating them as one.

Obligation one: report it upstream and fix it, with no exploitation needed

Article 13(6) is unconditional. Manufacturers shall, “upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I.”

Nothing in that sentence waits for an attacker. The duty is to tell the maintainer and remediate. Recital 34 describes the due diligence that finds these vulnerabilities in the first place, including “verifying that a component is free from vulnerabilities registered in the European vulnerability database … or other publicly accessible vulnerability databases.” Annex I, Part II, point (1) requires you to “identify and document vulnerabilities and components contained in products with digital elements,” including a software bill of materials covering at least the top-level dependencies.

One timing point matters here. Article 13 and Annex I apply from 11 December 2027 (Article 71(2)), not from September 2026. This is the obligation you are building towards, not the one already running.

Obligation two: notify the regulator, only on active exploitation

Article 14(1): “A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator … and to ENISA,” via the single reporting platform established under Article 16. The deadlines under Article 14(2) run from awareness:

• 24 hours: early warning.
• 72 hours: vulnerability notification.
• 14 days after a corrective or mitigating measure is available: final report.

This one is already live. It also reaches the installed base: Article 69(3) applies Article 14 “to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.”

“Known” is not “actively exploited”

The trigger is a defined term. Article 3(42): “‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.”

None of these meets that definition: a published CVE, a critical CVSS score, a proof-of-concept on GitHub, a scanner finding in your own pipeline. Each tells you a vulnerability exists. None is evidence that a malicious actor has used it. The Commission's FAQ gives two examples of zero-days that are not reportable because there is no evidence of malicious exploitation: one reported through a bug bounty, one found by a test lab (FAQ 5.2). Those still go through obligation one.

Two phrases, two different questions

Two phrases in the text answer two different questions, and reading them together is where the real analysis sits.

• “Contained in the product” (Article 14(1)) answers which vulnerabilities you notify: only those in your product.
• “In a system” (Article 3(42)) answers where the evidence of exploitation can come from. The definition does not say “in your product” or “at your customer”.

Read literally, confirmed in-the-wild exploitation of an open-source library, on systems that have nothing to do with you, could make that vulnerability “actively exploited” for every manufacturer that ships the library.

Two sources narrow that reading. Recital 68 describes actively exploited vulnerabilities as instances where a breach “has resulted from a malicious actor making use of a flaw in one of the products with digital elements made available on the market by the manufacturer.” The Commission's FAQ addresses integrated components directly (FAQ 5.4):

“Where the product with digital elements contains an actively exploited vulnerability originating from an integrated component, the manufacturer of the product with digital elements is required to notify that vulnerability. … If the manufacturer of a product with digital elements is aware that an integrated component contains a vulnerability, but that vulnerability cannot be exploited in its product with digital elements, that vulnerability is not actively exploited, and therefore it is not subject to mandatory reporting.”

Our reading, and it is a reading: evidence of exploitation elsewhere is what establishes “actively exploited”. The question that then decides your notification is whether the vulnerability can be exploited in your product, as shipped and as configured. If it can, the clock runs from the moment you become aware. If it cannot, there is no mandatory notification. Article 13(6) still applies, and Article 15 allows voluntary notification.

The consequence is easy to miss. When a Heartbleed-class flaw in a ubiquitous library is exploited at scale, every aware manufacturer whose product exposes it notifies separately. The component's own manufacturer notifies too, if that component was placed on the market (FAQ 5.4). The FAQ says this is by design: it gives CSIRTs and ENISA a view of the “market penetration” of the vulnerability.

The FAQ is guidance from the Commission services. By its own disclaimer it is not the Commission's official position, and it cannot extend the obligations in the Regulation.

Being “aware” is not a monitoring mandate. Vulnerability handling still is

The Commission's FAQ lists ways a manufacturer might learn of exploitation, such as a customer report, threat intelligence or telemetry. It then adds that “this does not imply that the manufacturer is required to carry out such activities or monitor such channels to comply with the reporting obligations” (FAQ 5.1).

Do not read that as permission to look away. Annex I, Part II still requires you to identify and document the components and vulnerabilities in your product. The same FAQ entry notes that Part II also requires a single point of contact for vulnerability reports and a coordinated vulnerability disclosure policy. Article 14 does not require you to hunt for exploitation. Annex I requires you to know what you ship.

One question the guidance leaves open: whether exploitation recorded in a public source you have not read counts as awareness. We would not build a process that depends on the answer.

Your build tools are a separate question

Suppose the CVE is in a compiler, a CI runner or a package manager: something you use to build the product but do not ship. On the text, it is not “contained in the product”, so Article 14(1) does not reach it. That is our interpretation of the wording. We are not aware of guidance that settles it.

A compromised build chain is different. If it puts malicious code into what you ship, it can be a severe incident under Article 14(3). Article 14(5)(b) treats an incident as severe where “it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product.”

The incident track has its own clock. The 24-hour and 72-hour steps match the vulnerability track, but the final report is due within one month after the incident notification (Article 14(4)(c)). The vulnerability track's final report is due 14 days after a fix is available. The two tracks can run side by side for the same event, so do not merge them in your procedure.

Where IEC 62443-4-1 fits, and where it stops

If you run a 62443-4-1 secure development lifecycle, most of obligation one already has a home:

• SM-9 (security requirements for externally provided components) gives as an example “identifying known vulnerabilities in specific versions of open source software components and updating the version of the open source components to the version that fixes the vulnerability.”
• DM-4 (addressing security-related issues) requires you to “inform third parties if problems found in included third-party source code”, which is close to Article 13(6).
• DM-3 (assessing security-related issues) already names “the availability of exploits” as a factor in impact assessment. That makes it the natural place to record the Article 14 decision: is this actively exploited, and is it exploitable in our product?
• DM-5 (disclosing security-related issues) informs product users about issues the supplier decides are reportable. That is related to, but not the same as, Article 14(8), which requires you to inform impacted users after becoming aware of an actively exploited vulnerability. DM-5's guidance also covers telling users “that the product is not susceptible to a highly publicized vulnerability”, which is exactly the message for the not-exploitable-in-our-product case.

What 62443-4-1 does not contain is any equivalent of the Article 14(1) notification to a CSIRT and ENISA on a statutory clock. A 4-1 process, certified or not, does not cover that duty by itself. You have to add it.

A decision rule you can write down

1. Is the vulnerable component in the product as shipped? Check the SBOM. If not, Article 14(1) does not apply. If the problem is in your build chain, run the severe-incident check.
2. Is there reliable evidence that a malicious actor has exploited it, anywhere? If not, it goes through vulnerability handling: tell the maintainer and remediate. No Article 14 clock.
3. Can it be exploited in our product, as shipped and configured? If not, there is no mandatory notification. Record why, report to the maintainer, and consider telling users the product is not affected. If it can: 24-hour early warning, 72-hour notification, final report 14 days after the fix, and inform impacted users (Article 14(8)).
4. Record when you became aware. Every deadline runs from that moment, and it is the first thing anyone will ask you to prove.

What applies when

• Now, since 11 September 2026: Article 14, including user information under Article 14(8), for every in-scope product, including those already on the market (Articles 69(3) and 71(2)).
• From 11 December 2027: Article 13(6), the Annex I vulnerability handling requirements and the SBOM (Article 71(2)). For products placed on the market before that date, the Commission's FAQ says the CRA requires notification but not the other obligations, such as vulnerability handling (FAQ 5.3). The exception is a substantial modification, which brings a product under the Regulation (Article 69(2)).
• From 11 December 2027: reporting obligations for open-source software stewards, under Article 24(3) (FAQ 5.5).

We help manufacturers turn this into a written triage rule, a named decision-maker and an SBOM that can answer “do we ship it, and can it be exploited here?” within the first of those 24 hours. If you would rather work through the CRA with tooling than with a consultant, the CRA Workbench is the same team in a different shape.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act): Article 3(42); Article 13(6); Article 14(1)–(5) and (8); Articles 15, 16, 24(3), 69(2)–(3) and 71(2); Annex I, Part II; Recitals 34 and 68.
• European Commission services, FAQs on the Cyber Resilience Act, version 1.4 (4 September 2026), entries 5.1–5.5. Guidance, not binding law.
• IEC 62443-4-1:2018 (ANSI/ISA-62443-4-1-2018), Secure product development lifecycle requirements: SM-9, DM-3, DM-4, DM-5.

Where this post gives our interpretation rather than the text of the Regulation or the Commission's guidance, it says so. This post is informational and is not legal advice; verify against the Official Journal text.