EN 40000-1-3: Vulnerability Handling Requirements

In this page we’re going to go over what the EN 40000-1-3 standard actually requires (an SBOM process, a disclosure policy, ongoing monitoring), how it fits alongside EN 40000-1-2 and prEN 40000-1-4, and a legal reporting deadline that lands weeks before the standard itself is expected to publish. 

By the end, you’ll know what to build, in what order, and by when, starting with the date that matters most: 11 September 2026.

Time-sensitive: the reporting obligation starts 11 September 2026

Separately from when EN 40000-1-3 itself gets published, Article 14 of the CRA becomes legally binding from 11 September 2026. From that date, manufacturers must report actively exploited vulnerabilities and severe incidents to their coordinating CSIRT and ENISA on a strict timeline: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a fix becoming available. This applies whether or not EN 40000-1-3 has been formally published, the standard will make it easier to build the process, but the legal deadline doesn’t wait for it.

What is EN 40000-1-3?

EN 40000-1-3 is the third project (PT3) in the EN 40000 series, officially “Cybersecurity requirements for products with digital elements, Part 1-3: Vulnerability handling.” 

Where EN 40000-1-2 covers the principles and risk-assessment process, and prEN 40000-1-4 covers technical security controls, EN 40000-1-3 covers what happens after a product ships: finding, fixing, disclosing, and reporting vulnerabilities for as long as the product is supported.

If you’re still getting oriented on the Cyber Resilience Act as a whole, that’s worth a detour before this page gets more specific.

How it links to the CRA (Annex I, Part II)

EN 40000-1-3 turns Annex I, Part II of the regulation into a working process. The regulation requires manufacturers to:

1. Identify and document vulnerabilities and components, including a software bill of materials (SBOM) in a commonly used, machine-readable format, covering at least top-level dependencies.
2. Address and remediate vulnerabilities without delay, providing security updates, separately from feature updates where technically feasible.
3. Apply effective and regular tests and reviews of product security.
4. Once a fix is available, publicly disclose information about the vulnerability, its impact, severity, and how to remediate it (delay is allowed in justified cases, until users can patch).
5. Put in place and enforce a coordinated vulnerability disclosure policy.
6. Facilitate information sharing about potential vulnerabilities, including a standing reporting contact address.
7. Provide secure update-distribution mechanisms, automatic where applicable for security updates.
8. Disseminate available security updates without delay and, in most cases, free of charge.

Main requirements in practice

Two things on that list are worth calling out because they’re the ones that require infrastructure you can’t build overnight: the SBOM and the coordinated disclosure policy. An SBOM means you need a process that actually tracks your dependencies, not a document someone assembles by hand after the fact. A coordinated vulnerability disclosure policy means having a public contact point and a defined process before anyone reports something to you, not improvising a response when the first report arrives.

The reporting deadlines described above, 24 hours, 72 hours, 14 days, sit on top of this. In practice, that means your internal vulnerability-handling process needs a clock built into it: the moment your team becomes aware of active exploitation, the 24-hour window has already started.

A worked example: the reporting clock in practice

Say a security researcher emails your published disclosure contact on a Tuesday afternoon, reporting that a vulnerability in your product is being actively exploited. 

That email starts the clock defined in Article 14, not your internal triage meeting, not your patch release. Within 24 hours, someone at your organization needs to have filed an early warning notification to your coordinating CSIRT and ENISA, even if all you know at that point is that exploitation is happening. 

Within 72 hours, a fuller notification follows: what’s affected, what you know about the exploit, what you’ve done or recommend so far. Once a fix ships, you have 14 days to file a final report describing the vulnerability, its severity, and the corrective measures released.

The organizations this catches out aren’t the ones without a patch process, most manufacturers can build and ship a fix. It’s the ones without a designated owner for that first 24-hour window, because a report that lands in a shared inbox on a Friday evening, with no one responsible for noticing it, has already burned a meaningful chunk of the clock before anyone reads it.

How it differs from -1-2 and -1-4

• EN 40000-1-2 is the process for assessing risk before and during development.
• EN 40000-1-3 (this page) is the process for handling vulnerabilities after the product is on the market, and for the entire support period, at least five years under Article 13.
• prEN 40000-1-4 is the catalogue of technical controls you implement to satisfy the essential requirements in the first place.

You need all three, plus the reporting obligation above, which exists independently of any of them.

Status

EN 40000-1-3 is designated prEN 40000-1-3 on the official CEN standards portal, status Under Approval, with no confirmed publication date yet. That puts it one stage behind EN 40000-1-2, which carries the more advanced FprEN (Formal Vote) designation. Whatever the publication timeline, it doesn’t change the Article 14 reporting deadline above, that’s already law regardless of standard status. Track publication progress for this and every other EN 40000 document on our CRA Standards Tracker.

How to comply

1. Build your reporting process now. Know who at your organization owns the 24-hour early warning notification, and make sure they know the single reporting platform exists under Article 16. For the full picture of what’s due when across the whole regulation, not just this one deadline, see our CRA compliance deadlines guide.
2. Stand up an SBOM process, not a one-time document. It needs to reflect what’s actually in your product on an ongoing basis.
3. Publish a coordinated vulnerability disclosure policy with a real, monitored contact point.
4. Plan your update distribution mechanism, including automatic security updates where applicable, separate from feature releases.

Missing the reporting window isn’t just a compliance footnote either, it’s the kind of gap that shows up in an enforcement action. See what’s actually at stake in our breakdown of CRA fines.

Manage and demonstrate CRA compliance with SAMMY. 

Review the requirements, track your evidence as you build toward them, and generate the documentation you’ll need to show conformity, all in one place.

Manage and demonstrate CRA compliance with SAMMY

The EU Cyber Resilience Act is here. SAMMY walks you through the requirements, tracks your evidence as you go, and produces the documentation you need to show conformity.

• Review CRA requirements
• Demonstrate compliance with evidence
• Generate legal documentation