Under Article 14(8) of the Cyber Resilience Act (CRA), manufacturers must inform impacted users after becoming aware of an actively exploited vulnerability in a product with digital elements or a severe incident affecting its security. Where appropriate, they must inform all users. Where necessary, the communication must also explain risk-mitigation and corrective measures users can take. This is a separate duty from reporting the event to EU authorities.
The practical challenge is not simply writing an announcement. A manufacturer needs to identify the affected products and users, provide accurate instructions while facts are changing, choose effective communication channels and preserve evidence of what was communicated. This guide distinguishes the regulation's requirements from implementation practices that help teams meet them.
What triggers the Article 14(8) user notification duty?
Article 14(8) refers to two events:
- An actively exploited vulnerability: a vulnerability contained in a product with digital elements for which the manufacturer becomes aware of active exploitation.
- A severe incident: an incident having a severe impact on the security of a product with digital elements, assessed against the criteria in Article 14(5).
The duty is triggered by the manufacturer's awareness of the relevant event, not by completion of a patch, assignment of a CVE identifier or publication of a final incident report. A team should therefore not wait for every technical detail to be settled before evaluating its user-communication obligations.
Not every reported vulnerability is known to be actively exploited, and not every operational disruption is a severe product-security incident under Article 14. Record the facts and reasoning behind the classification. If new evidence changes the classification, reassess the communication duty and update the response record.
Article 14 has applied since 11 September 2026. Article 69(3) extends its obligations to in-scope products placed on the market before the CRA's general application date of 11 December 2027. A manufacturer should not exclude an older product from Article 14 solely because it was sold before that date. These dates and the reporting framework are set out in the Regulation and the European Commission's CRA reporting guidance.
Which users must receive the information?
The legal starting point is impacted users. Article 14(8) also says to inform all users where appropriate. The provision does not say that a generic public notice is always sufficient to reach the impacted population, nor that every case requires contacting every user regardless of relevance.
Determine the audience using the best available product evidence:
- affected product families, models and variants;
- vulnerable software or firmware versions and relevant configurations;
- deployment or exposure conditions;
- known customer, reseller and support channels;
- connected-device or account records, where available and appropriate; and
- the distinction between directly impacted users and a wider audience that may reasonably need the warning.
For example, a vulnerability limited to one firmware branch may call for a targeted message to that branch's users. A severe incident affecting a shared update mechanism across several products may justify broader communication. These are implementation examples, not separate legal categories.
When the manufacturer cannot reliably identify every affected user, document that limitation and use additional channels proportionate to the risk. Do not present a mailing-list delivery count as proof that all impacted users actually received or understood the information.
What must the message tell users?
Article 14(8) requires information about the vulnerability or incident and, where necessary, risk-mitigation and corrective measures users can deploy. The Regulation also envisages a structured, machine-readable format where appropriate and readily automatically processable.
An effective first notice should answer the following operational questions:
- What happened? State whether the message concerns an actively exploited vulnerability or a severe incident, using terminology supported by the current assessment.
- What is affected? Identify products, versions, configurations or services as precisely as the evidence allows.
- Who should act? Explain which users need to check their installations or configurations.
- What should users do now? Provide specific mitigation or corrective steps, distinguishing a temporary workaround from a permanent security update.
- Where are reliable updates? Give an official advisory identifier, support contact or maintained update channel.
- What is still unknown? Make material uncertainties explicit rather than presenting preliminary findings as final conclusions.
These six fields are a recommended communication structure, not an exhaustive list prescribed word-for-word by Article 14(8). The statutory core remains informing the relevant users of the event and, where necessary, the actions available to mitigate its impact.
Avoid ambiguous advice such as "apply security best practices" when a specific protective action is known. If no safe user action is yet available, say so and explain how further guidance will be provided. Do not expose secrets, unnecessary exploit details or personal data in a broad notification.
Is there a 24-hour or 72-hour deadline for notifying users?
Do not copy the authority-reporting deadlines onto Article 14(8). Article 14(2) and (4) establish early-warning and subsequent notification deadlines for reporting actively exploited vulnerabilities and severe incidents to the CSIRT designated as coordinator and ENISA. The early warning is due without undue delay and in any event within 24 hours of awareness; the further notification is due without undue delay and in any event within 72 hours.
Article 14(8) does not set an equivalent numerical 24-hour or 72-hour deadline for informing users. It does, however, contemplate timely communication: if the manufacturer fails to inform users in a timely manner, the notified CSIRT designated as coordinator may provide the information when it considers doing so proportionate and necessary to prevent or mitigate impact.
Operationally, treat user communication as time-sensitive and record the decision on when and how to notify. A delayed message should not be justified merely because the authority report is not yet complete. Equally, do not claim that the 24-hour authority deadline automatically defines the legal deadline for every user notice.
Authority reporting and user communication are different workflows
The CRA Single Reporting Platform (SRP), operated by ENISA, is the channel for mandatory Article 14 reporting to the relevant CSIRT and ENISA. ENISA confirms that the SRP became operational on 11 September 2026.
A submission through the SRP is not a substitute for informing users under Article 14(8). Conversely, publishing a customer advisory does not replace the manufacturer's regulatory reporting duties. Teams should track both activities under the same case identifier without marking one as complete because the other was performed.
| Activity | Recipient or audience | Relevant rule | | --- | --- | --- | | Early warning and further notification | CSIRT designated as coordinator and ENISA via the SRP | Article 14(1)–(4), (7) | | User notice and mitigation guidance | Impacted users; all users where appropriate | Article 14(8) | | Public information on a fixed vulnerability after an update | Users and public audience as applicable | Annex I, Part II, point 4 |
The final row is a distinct vulnerability-disclosure requirement. Its timing and conditions should not be confused with the immediate user-communication assessment following awareness of active exploitation or a severe incident.
How should manufacturers deliver the notice?
Article 14(8) does not mandate one universal delivery channel. Choose a channel mix that can actually reach the relevant audience and allows the message to be maintained as facts evolve.
Depending on the product and customer relationship, useful options include direct customer email, an in-product security notification, an official security-advisory page, a customer portal, a service-status channel, or a reseller and distributor communication route. For business-to-business products, a named security contact and an escalation path can reduce the chance that urgent guidance remains in a general support inbox.
Where appropriate, provide structured, machine-readable information so operators can process affected-version and remediation details. The CRA's reference to machine-readable communication should not be misrepresented as an unconditional requirement to publish every notice in a particular advisory format.
Whichever channels are chosen, keep the substantive instructions consistent. An updated advisory must not contradict an older in-product banner without a clear revision or replacement notice.
A practical notification workflow
Build the user-notification decision into vulnerability handling and incident response rather than treating it as an afterthought.
First, establish the case and scope. Record the awareness timestamp, the event classification, the affected product identifiers and the evidence supporting those decisions. Assign an accountable owner for user communication.
Second, determine the audience. Identify impacted versions, deployments and customer channels. Decide whether notifying all users is appropriate and record the rationale. If user records are incomplete, identify additional reasonable communication routes.
Third, prepare an actionable initial message. Separate confirmed facts from open questions. Have product security validate the affected scope and mitigation instructions, and have the appropriate internal owner approve the message. This review should be rapid enough not to undermine timely communication.
Fourth, distribute and record the notice. Publish through the selected channels and preserve the content, version, approval and timestamps. Track delivery evidence where available, without equating attempted delivery with confirmed receipt.
Fifth, update as the situation changes. If a new affected version is found, a workaround proves ineffective or a patch becomes available, issue a clearly dated revision. Keep a stable reference so customers can identify the latest authoritative guidance.
Finally, reconcile the case. Connect the user messages with the regulatory reports, vulnerability decisions, security updates and final remediation evidence. The case should show both what the manufacturer knew and what users were told at each stage.
Evidence to retain for later review
A defensible record of the user-notification process can include:
- the event and awareness timestamps;
- the assessed Article 14 trigger and classification rationale;
- the affected-product and affected-user analysis;
- the decision on whether a broader audience should be notified;
- each approved message version and its publication timestamp;
- communication channels, recipient groups and delivery evidence where available;
- the mitigation or corrective guidance provided;
- subsequent corrections and update notices;
- the responsible reviewers and approvers; and
- links to the corresponding SRP case, vulnerability record and release evidence.
This is a recommended evidence model, not a claim that Article 14(8) enumerates these fields. Retaining a clear history helps teams explain whether the communication was timely, appropriately targeted and useful to affected users.
Where lifecycle traceability helps
User notifications become harder to keep accurate when affected versions, vulnerability decisions, mitigations and release evidence are maintained in disconnected systems. AA-sec is designed to connect vulnerability management, security evidence and product lifecycle context so that teams can trace which product and release a decision concerns. Its roadmap includes post-market monitoring and CRA Article 14 workflows; it does not automatically submit regulatory reports or make the manufacturer's legal notification decisions.
Key takeaway
CRA Article 14(8) creates a user-facing duty distinct from reporting to authorities. Manufacturers must inform impacted users after becoming aware of an actively exploited vulnerability or severe product-security incident, inform all users where appropriate, and explain user-deployable mitigations or corrective measures where necessary. A reliable process identifies the right audience, communicates practical actions promptly, maintains revisions and preserves evidence linking the notice to the underlying security event.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act, Article 14 — EUR-Lex
- Cyber Resilience Act - Reporting obligations — European Commission
- Single Reporting Platform: Frequently Asked Questions — ENISA