Informing users under Article 14(8): what manufacturers must tell them

Under Article 14(8) of Regulation (EU) 2024/2847, once the manufacturer becomes aware of an actively exploited vulnerability or a severe incident, it informs the impacted users and, where appropriate, all users. Where necessary, it also sets out measures users can take to mitigate the impact. There is no deadline in hours; the information must be given in a timely manner, otherwise the coordinating CSIRTs may pass it on to users themselves. The obligation has applied since 11 September 2026. The obligations on security updates and on publishing fixed vulnerabilities under Article 13 and Annex I, by contrast, only apply from 11 December 2027.

What does Article 14(8) say?

After becoming aware of an actively exploited vulnerability or a severe incident ..., the manufacturer shall inform the impacted users of the product with digital elements, and where appropriate all users, of that vulnerability or incident and, where necessary, of any risk mitigation and corrective measures that the users can deploy to mitigate the impact ..., where appropriate in a structured, machine-readable format that is easily automatically processable. Where the manufacturer fails to inform the users ... in a timely manner, the notified CSIRTs designated as coordinators may provide such information to the users when considered to be proportionate and necessary for preventing or mitigating the impact of that vulnerability or incident.

Article 14(8) CRA

The provision has six elements, and each one calls for a decision:

• "After becoming aware." The obligation is tied to the same point in time as the notification to the CSIRT: the end of the immediate initial assessment, with a reasonable degree of certainty. More on this in the guide When does the 24-hour deadline start?.
• "The impacted users." The users of the affected products and versions. The manufacturer has to identify them itself: from licence and customer data, registrations, sales partners or notices in the product.
• "Where appropriate all users." If the users concerned cannot be narrowed down, or the risk justifies it, the information goes to everyone, for example via the website.
• "Where necessary, of any risk mitigation and corrective measures." If there is something users can do (switch off a function, close a port, install an update), it belongs in the notice.
• "In a timely manner." No deadline in hours. The 24 and 72 hours in Article 14(2) and (4) apply only to the notification to the CSIRT. Neither the Regulation nor any established regulatory practice defines what timely means.
• "The CSIRTs ... may provide such information to the users." A manufacturer that does not inform users in time loses control of the communication: the coordinating CSIRT (in Germany, CERT-Bund) may then inform them itself.

Recital 67 adds how this can be done: by publishing the information on the website or, where the manufacturer is able to contact the users and the risk justifies it, by reaching out to them directly. The aim is to let users react quickly.

How does the Commission guidance interpret the provision?

The guidance C(2026) 5252 devotes three paragraphs to it. Paragraph 219 restates the principle. The next two resolve the dilemma every manufacturer faces: informing early and publicly hands attackers a set of instructions before an update is available.

• Paragraph 220: risk-based and proportionate. The obligation does not mean that information must be made public or disclosed indiscriminately. The manufacturer may limit detailed information to the users or customers concerned, particularly for products used in sensitive environments, where details could facilitate further exploitation.
• Paragraph 221: broader disclosure after the fix. Once the vulnerability has been addressed, broader disclosure may be appropriate so that users can check whether they are still affected. The scope and timing remain proportionate. From 11 December 2027, Annex I, Part II, point (4), requires fixed vulnerabilities to be published in any case.

This leads to a two-stage approach: first a targeted notice to those affected, with what they need to protect themselves and without exploit details; after the update, a public notice with a full description.

What is added from 11 December 2027?

Under Article 71(2), Article 14 has applied since 11 September 2026, and the obligations under Article 13 and Annex I apply from 11 December 2027. According to the guidance (paragraph 210), the vulnerability handling obligations also apply only within the support period and not to products placed on the market before 11 December 2027 (Article 69(2) and (3)); Article 14, by contrast, applies to all products.

Recital 56 describes the intended practice for updates: automatic notification, distribution, download and installation, in particular for consumer products, with a clear and easy-to-use way to opt out. This does not apply to components or to professional environments where users would not expect automatic updates. How long the support period runs in an individual case is explained in the guide Support period.

In what form: website, direct contact, CSAF?

The Regulation does not prescribe a form. Article 14(8) refers to a structured, machine-readable format "where appropriate" without specifying one. The state of the art for machine-readable security advisories is CSAF 2.0 (Common Security Advisory Framework), a data format published by OASIS and standardised as ISO/IEC 20153:2025. It contains a product tree, the CVE identifier (the public number of the vulnerability), the CVSS score (the usual figure for severity), the status (affected, fixed) and remediations. The BSI recommends CSAF, provides tools for it and refers to publication in this format in TR-03183-3. Whether CSAF will become the de facto mandatory format through a harmonised standard or an implementing act remains open; there is no such obligation today.

A human-readable version is required in any case: Annex I, Part II, point (4), requires clear and accessible information, and Article 13(18) requires information and instructions that users can easily understand. For a mid-sized manufacturer without its own toolchain, a page of security advisories at a stable address is enough to start with. It lists the product and versions, the CVE identifier if one has been assigned, the severity, a description, the workaround, the fixed version, the date and a change history. Where the advisories can be found belongs in the manufacturer's security.txt.

Model outline for a customer notice

The following outline is not a template with ready-made wording. It is the order of points that a notice to affected customers should cover, and it is meant for the first, targeted stage. Exploit details do not belong in it.

• Subject and classification. Product name, affected versions, date and reference of the advisory, urgency in one sentence.
• What has happened. The type of vulnerability or incident in plain language, without the attack path or sample code. The CVE identifier, if one has been assigned.
• Who is affected. Which products, versions and configurations are affected, and which are not.
• Possible impact and severity. What an attacker could achieve, and a severity rating, for example as a CVSS score.
• Immediate measures. What the customer can do now, before an update is available: switch off a function, restrict access, check logs, together with the limitations this entails.
• Fix. Whether a security update is available and in which version, or when it is expected.
• Next notice. When and where the customer will find the next notice.
• Contact. The security address for questions and a reference to the coordinated vulnerability disclosure policy.

After the update comes the second stage: public disclosure with a full description, the affected products, impact, severity and remediation guidance, in CSAF where appropriate. Annex I, Part II, point (4), requires it from December 2027. Who was informed, when and how belongs in the record; market surveillance authorities can ask for evidence.

Free templatesCRA Reporting KitThe customer notice as a template in German and English, the outline of the public security advisory and a record sheet for sending it out.Request the kit

Common mistakes

• Waiting for the update to inform users, although a workaround is already possible. That misses "in a timely manner", and the CSIRT may inform users itself.
• Full public disclosure with exploit details before the update. Paragraph 220 allows the information to be limited to those affected; use it.
• A notice only in a newsletter, without a stable address, version details or a date. Users cannot check later whether they are still affected.
• Users unknown, so nobody is informed. For this case, recital 67 refers to publication on the website.

For the first stage, what matters most is that someone triggers the notice in time while the deadlines for the notification to the CSIRT are running in parallel. From confirmed awareness onwards, CRA Response Center shows the deadlines for the early warning and the notification and records in the history who was alerted and who took on the case, and when; the content and dispatch of the customer notice are for the manufacturer to decide.

Frequently asked questions

Further reading

• Early warning, notification, final reportThe notification to the CSIRT, which runs in parallel with informing users.
• Support periodHow long security updates are required and how to state the end date.
• Coordinated vulnerability disclosure policyWhat belongs in the CVD policy that the customer notice refers to.
• Glossary: informing users of vulnerabilities and incidentsThe term in two sentences.

Sources

• Regulation (EU) 2024/2847, Article 13(7) to (11), (18) and (19), Article 14(8), Article 71, Annex I, Part I, point (2), and Part II, points (2), (4), (7) and (8), recitals 56 and 67, EUR-Lex, 20 November 2024.
• Commission guidance C(2026) 5252, Annex, paragraphs 210 and 219 to 221, European Commission, 27 July 2026.
• Common Security Advisory Framework (CSAF), BSI, accessed 7 October 2026.
• Common Security Advisory Framework Version 2.0, OASIS, 2022.
• BSI TR-03183-3 Vulnerability Reports and Notifications, Version 1.0.0, BSI, 20 August 2025.