We sell only through channel partners and do not know our users. Does the duty fall away?

No. Article 14(8) contains no limitation to what is feasible for the manufacturer; the phrase “by any means available and to the extent possible” appears only in Article 13(23) and in Articles 19(8) and 20(6), all of which deal with a cessation of operations. A manufacturer that cannot reach users individually informs them publicly, because the provision names the impacted users and, where appropriate, all users. The single point of contact under Article 13(17) does not help here: it receives reports and is not a distribution list. Anyone who has to inform users regularly needs a public channel of their own that can be found without a customer account.

Is an entry in the release notes enough?

For the disclosure required by Annex I, Part II, point 4, usually not. That point calls for a description of the vulnerability, information allowing users to identify the affected product, the impacts and the severity, and accessible guidance on remediation. A single line reading “various security fixes” carries none of that. Article 14(8) adds a further hurdle, because the impacted users have to be reached, not only those who go looking in a changelog of their own accord.

We already report under NIS2 and the GDPR. Does that cover this?

No, the three duties have different triggers and different addressees. Article 23 of the NIS2 Directive requires essential and important entities, where appropriate, to inform the recipients of their services of significant incidents that are likely to adversely affect the provision of those services and, where a significant cyber threat arises, to communicate to the potentially affected recipients the measures they can take in response; the anchor is the entity’s own service. Article 34 GDPR requires communication to the data subject where a personal data breach is likely to result in a high risk to their rights and freedoms. Article 14(8) CRA attaches to the product instead and bites even where no personal data is involved and the company falls outside the NIS2 Directive.

Cyber Resilience Act

Informing users

Practical term

Informing users is the manufacturer’s duty to reach the people and organisations actually running a product once its security position deteriorates. The Cyber Resilience Act (CRA) deals with it in several places, and in each of them it stands on its own beside the notification to the authorities. Having notified is not the same as having informed anyone.

The core: Article 14(8)

The duty arises as soon as the manufacturer becomes aware of an actively exploited vulnerability or of a severe incident affecting product security. Those to be informed are the impacted users of the product and, where appropriate, all users.

The content splits in two. The vulnerability or the incident itself always has to be communicated. Where necessary, the risk mitigation and corrective measures that users can deploy themselves to mitigate the impact come on top. Where appropriate this happens in a structured, machine-readable format that is easily automatically processable.

Article 14(8) sets no deadline. It attaches to becoming aware, and its second sentence merely presupposes that users are informed in a timely manner. That openness has a sharp flipside: where the manufacturer fails to inform in time, the CSIRTs designated as coordinators may put the information out to users themselves, where they consider it proportionate and necessary to prevent or mitigate the impact. The communication then happens without the manufacturer, who learns its wording only afterwards.

Annex I, Part II, point 4: the public disclosure

A second duty sits next to that one, with a different trigger. Once a security update has been made available, manufacturers must share and publicly disclose information about the fixed vulnerability. The minimum content is spelled out:

a description of the vulnerability
information allowing users to identify the affected product
the impacts of the vulnerability and its severity
clear and accessible information helping users to remediate it

Here the trigger is the availability of the fix, not knowledge of the problem. The point also permits a delay: in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may hold back until users have had the possibility to apply the relevant patch. Article 14(8) has no comparable clause.

Further occasions across the product life

Available updates: Annex I, Part I, point 2(c) requires, where applicable and on the basis of the cybersecurity risk assessment, notification of available updates to users and the option to postpone them temporarily in the case of automatic security updates.
End of the support period: under Article 13(19), manufacturers display a notification to users that this point has been reached, where technically feasible in light of the nature of the product.
Historical versions: a manufacturer running a public software archive under Article 13(11) must inform users clearly and in an easily accessible manner about the risks of using unsupported software.
Cessation of operations: Article 13(23) requires the relevant market surveillance authorities and the users of the affected products to be informed before the cessation takes effect, the latter by any means available and to the extent possible.
Advisory messages: Annex I, Part II, point 8 requires security updates to be disseminated together with advisory messages giving users the relevant information, including on potential action to be taken.

The chain does not stop at the manufacturer. Where importers or distributors become aware that the manufacturer has ceased operations, the same duty to inform users falls on them, under Article 19(8) and Article 20(6). Open-source software stewards are caught as well: under Article 24(3), Article 14(8) applies to them to the extent that severe incidents affect the network and information systems they provide for the development of such products.

Channel and form remain largely open

The CRA prescribes no channel. For informing users about severe incidents, Recital 67 offers two examples: publishing relevant information on the manufacturer’s website, and reaching out to users directly where the manufacturer is able to contact them and the cybersecurity risks justify it. Recital 56 states generally that a manufacturer should inform users about vulnerabilities, irrespective of whether the product is designed to receive automatic updates. The existing user interface, though, that same recital raises for one specific occasion only: where a product has a user interface or similar technical means allowing direct interaction, the manufacturer should use it to inform users that the product has reached the end of its support period. For such notifications it counsels restraint in the same breath: they should be limited to what is necessary for the information to be effectively received, and should not degrade the user experience.

The machine-readable format in Article 14(8) is where the provision meets established practice. The CRA names no format. In industry, this message is today carried by advisories in the CSAF format, often with VEX statements on which versions are affected. That is a reading of practice, not a requirement of the text: a manufacturer already publishing that way has an obvious vehicle for the “where appropriate in a structured, machine-readable format” qualifier, but is not thereby relieved of the duty to actually reach the impacted users.

Not the same as reporting or user information

Three duties get blurred together. The reporting obligations in Article 14 run to the CSIRT designated as coordinator and to ENISA, travel over the single reporting platform, and follow a fixed schedule of an early warning within 24 hours, a notification within 72 hours and a final report. Informing users is aimed at the market and follows no such schedule. The information and instructions to the user under Annex II are the static package that accompanies the product from the outset.

In practice: a notification submitted through the single reporting platform does not satisfy Article 14(8), and neither does a complete Annex II package.

Application and penalties

Article 14 applies from 11 September 2026. Annex I and Article 13, by contrast, apply only from 11 December 2027, the general date of application of the Regulation; the sole other early tranche is Chapter IV (Articles 35 to 51) on the notification of conformity assessment bodies, which applies from 11 June 2026. Informing users under Article 14(8) is therefore among the very first CRA duties to reach manufacturers at all.

Infringements of Articles 13 and 14 and of Annex I fall into the top tier of Article 64(2): administrative fines of up to EUR 15 000 000 or, in the case of undertakings, up to 2.5 % of total worldwide annual turnover for the preceding financial year, whichever is higher.

Practical questions

: No. Article 14(8) contains no limitation to what is feasible for the manufacturer; the phrase “by any means available and to the extent possible” appears only in Article 13(23) and in Articles 19(8) and 20(6), all of which deal with a cessation of operations. A manufacturer that cannot reach users individually informs them publicly, because the provision names the impacted users and, where appropriate, all users. The single point of contact under Article 13(17) does not help here: it receives reports and is not a distribution list. Anyone who has to inform users regularly needs a public channel of their own that can be found without a customer account.
: For the disclosure required by Annex I, Part II, point 4, usually not. That point calls for a description of the vulnerability, information allowing users to identify the affected product, the impacts and the severity, and accessible guidance on remediation. A single line reading “various security fixes” carries none of that. Article 14(8) adds a further hurdle, because the impacted users have to be reached, not only those who go looking in a changelog of their own accord.
: No, the three duties have different triggers and different addressees. Article 23 of the NIS2 Directive requires essential and important entities, where appropriate, to inform the recipients of their services of significant incidents that are likely to adversely affect the provision of those services and, where a significant cyber threat arises, to communicate to the potentially affected recipients the measures they can take in response; the anchor is the entity’s own service. Article 34 GDPR requires communication to the data subject where a personal data breach is likely to result in a high risk to their rights and freedoms. Article 14(8) CRA attaches to the product instead and bites even where no personal data is involved and the company falls outside the NIS2 Directive.

This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.