Incident and vulnerability reporting (Art. 14)

Manufacturer reporting under Article 14 of Regulation (EU) 2024/2847 applies from 11 September 2026, including for in-scope products already on the market.

This page is the customer- and operator-facing collection of those rules. Internal triage lives in the Security Incident policy (Notion; may require access).

What must be reported

Only:

• Actively exploited vulnerabilities — reliable evidence that a malicious actor exploited a vulnerability in the product without permission of the system owner.
• Severe incidents having an impact on the security of the product (Art. 14(5)): they negatively affect (or can) the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or they have led (or can lead) to malicious code in the product or in the user’s systems.

Routine bugs and ordinary patches are not Art. 14 events.

How manufacturers file

One notification via the ENISA Single Reporting Platform: https://portal.cra-srp.enisa.europa.eu.

• Addressed to the CSIRT designated as coordinator for the manufacturer’s EU main establishment (where cybersecurity decisions are predominantly taken; otherwise the establishment with the highest number of employees in the Union), and simultaneously available to ENISA (Art. 14(7), Art. 16).
• Assigned Representatives use a personal EU Login with multi-factor authentication. ENISA SRP FAQ (updated 3 Oct 2026): manufacturer association can be validated in parallel with a first notification.
• If the SRP is temporarily unavailable: wait and file when it is back. Direct CSIRT contact does not replace the SRP filing.
• Art. 15 voluntary reporting is not in the initial SRP release.
• Delegated Regulation (EU) 2026/881 only lets the receiving CSIRT delay dissemination to other CSIRTs. It does not pause manufacturer clocks.

The person who is Primary Assigned Representative remains TBD (do not invent a name). The CSIRT row to select remains TBD until legal entity / EU main establishment is confirmed. Member States of availability: all EU-27 (below).

Assigned Representative, EU Login, CSIRT, SRP — what this means

These are four different things. None of them is a Roasthubs product setting.

Term	What it is	What to do
Assigned Representative (AR)	A named natural person who may submit Art. 14 notifications for the manufacturer. ENISA expects a Primary AR and recommends a Secondary for coverage. This is not the Art. 19 authorised representative (legal person, only if the manufacturer has no Union establishment).	Name the people (TBD). Put them on the incident on-call rota as CRA reporter.
EU Login + MFA	The AR’s personal European Commission account (EU Login), with multi-factor authentication. It is not a shared info@ mailbox login.	Each AR creates their own EU Login, enables MFA, then registers on the SRP. Follow ENISA CRA SRP Guidance — AR User Registration.
CSIRT of EU main establishment	The national CSIRT designated as coordinator for the Member State of the manufacturer’s main establishment (Art. 14(7)): the place where cybersecurity decisions for the product are predominantly taken; if that cannot be determined, the Union establishment with the highest headcount. If there is no Union establishment, Art. 14(7) cascades to authorised representative → importer → distributor → Member State with most users.	Pick the row from ENISA’s list of CSIRTs designated as coordinators (published 4 Sep 2026; also the dropdown on the portal). Do not guess Belgium or any other CSIRT until legal entity / main establishment is confirmed. Choosing the wrong coordinator can invalidate the filing while the 24-hour clock still runs.
SRP portal	portal.cra-srp.enisa.europa.eu — the only valid Art. 14 filing path. One notification is visible to the selected CSIRT and ENISA.	Bookmark it in the incident playbook. File even if CSIRT validation of the manufacturer association is still pending (ENISA FAQ 9).

Member States where the product is made available

Working statement (6 Oct 2026): the product is made available in all EU Member States. Use this list on the 24-hour early warning.

Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden.

Clocks (Art. 14(2) and (4))

1. 24 hours from becoming aware — early warning, including Member States where the product has been made available (where applicable).
2. 72 hours — fuller notification: product, nature of the exploit or incident, measures taken, measures users can take, sensitivity of the information.
3. Final report — actively exploited vulnerability: no later than 14 days after a corrective or mitigating measure is available. Severe incident: within one month after the 72-hour notification.

Informing users (Art. 14(8))

After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must inform impacted users (and where appropriate all users) of that vulnerability or incident and, where necessary, of mitigation measures they can deploy.

How Roasthubs does this:

1. Identify impacted placed products and sites.
2. Email known operator/admin contacts of those sites. Do not wait for SRP CSIRT validation.
3. Publish a GitHub Security Advisory on roasthubs-os and a row on security advisories — immediately if users must mitigate before a patch; otherwise when the fix is available (Annex I Part II §4).
4. Take inbound follow-up on the monitored CVD address info@roasthubs.com.
5. Record who was informed, when, and through which channel — that feeds the 72-hour SRP field “measures users can take”.

Feature changelogs are not the Art. 14(8) channel. Ordinary bugs are not Art. 14 events.

Official operator manuals: ENISA SRP and Commission CRA reporting.