FAQ (manufacturers): do I need to notify ENISA of every vulnerability? The 24 hour rule - #356
Conversation
Consolidates the answer discussed in orcwg#32 into a manufacturers FAQ entry, placed under faq/manufacturers as suggested in the thread. Covers what actually triggers a mandatory notification (actively exploited vulnerability, severe incident), the 24h/72h/14d cascade running from awareness, the Article 14(8) duty to inform users, and the boundary with ordinary vulnerability handling. Links to the stewards entry for the subset that applies to open-source software stewards. Marked Draft for review. Refs orcwg#32
|
|
||
| # Do I need to notify ENISA of every vulnerability in my product? I have heard about a 24 hour rule. | ||
|
|
||
| No. Only two things trigger a mandatory notification under [[Article 14]]: |
There was a problem hiding this comment.
"Either of two things... " sounds better to my non-native ear.
|
|
||
| No. Only two things trigger a mandatory notification under [[Article 14]]: | ||
|
|
||
| * an _actively exploited vulnerability_ in your product, meaning there is evidence that a malicious actor is using it against real systems, see [[Article 14(1)]]. An internal finding, a researcher report, a proof of concept or a high severity score does not by itself trigger the duty (see [[Recital 66]] to [[Recital 68]]); and |
There was a problem hiding this comment.
perhaps a bit more like
'there is' --> your organisation has either evidence, reason to know or has been informed -- so the next sentence gets body
| * an _actively exploited vulnerability_ in your product, meaning there is evidence that a malicious actor is using it against real systems, see [[Article 14(1)]]. An internal finding, a researcher report, a proof of concept or a high severity score does not by itself trigger the duty (see [[Recital 66]] to [[Recital 68]]); and | ||
| * a _severe incident_ having an impact on the security of your product, see [[Article 14(3)]]. | ||
|
|
||
| The "24 hour rule" is the first stage of a three stage cascade. Every clock runs from the moment you become aware. |
There was a problem hiding this comment.
you -> your organisation --- as in open source this can get quite complex with individuals being on security teams of several and their own company
|
|
||
| * an _actively exploited vulnerability_ in your product, meaning there is evidence that a malicious actor is using it against real systems, see [[Article 14(1)]]. An internal finding, a researcher report, a proof of concept or a high severity score does not by itself trigger the duty (see [[Recital 66]] to [[Recital 68]]); and | ||
| * a _severe incident_ having an impact on the security of your product, see [[Article 14(3)]]. | ||
|
|
There was a problem hiding this comment.
We could give severe incident some body - such as a leak of certain confidential information, compromised keys, downloads/update binaries or archives. But also, for example, your ability to push out a security update in an appropriate time scale (think an attack on your CI/CD chain that builds the software you distribute), or an incident affecting your ability to work on these patches (such as a incident with your version control system or internal communication system (email, slack) that is vital for communication).
| [relevant CSIRT]: ../vulnerability-handling/csirt.md | ||
| [ENISA]: ../vulnerability-handling/enisa.md | ||
| [stewards]: ../stewards/notification-obligations.md | ||
| [srp]: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform |
There was a problem hiding this comment.
Update link: portal.cra-srp.enisa.europa.eu
3 participants
Consolidates the answer discussed in #32 into a manufacturers FAQ entry, placed under
faq/manufacturers/as suggested in that thread.The entry answers the question as asked — do I have to notify ENISA about every vulnerability — by separating the two triggers that actually create the duty from everything that does not:
It also notes that these obligations apply from 11 September 2026 ahead of the rest of the regulation ([[Article 71]]) and cover products already on the market, and links across to
faq/stewards/notification-obligations.mdfor the subset that applies to open-source software stewards.Marked
⚠️ Draftfor review. Link targets (../vulnerability-handling/csirt.md,../vulnerability-handling/enisa.md,../stewards/notification-obligations.md) all exist in the tree, and the entry is added tofaq/manufacturers/README.yml.Happy to adjust the wording, the placement or the level of detail — and to split the timing paragraph out if you would rather keep the entry strictly about the notification question.
Refs #32