After becoming aware of an actively exploited vulnerability or severe incident affecting product security, a manufacturer must inform impacted users and, where appropriate, all users. Where necessary, that information includes risk-mitigation and corrective measures users can deploy.
This user duty is separate from the authority notification stages. Do not close it merely because the regulatory submission succeeded.
Define the audience from product evidence
Start with the affected products, versions, configurations, and deployment conditions. Map them to customers or user groups using the evidence available. Record the inclusion rule, data sources, gaps, and person approving the audience.
If direct identification is incomplete, document whether a broader notice is appropriate. Avoid narrowing the audience simply because contact data is inconvenient to retrieve. At the same time, do not state that unaffected users are impacted when the evidence does not support it.
Use three audience states: impacted on current evidence, potentially impacted pending a named check, and outside current scope with evidence. Record the product or version rule that placed each group in its state. A broad customer list is a distribution tool, not the impact analysis itself.
If the scope changes, preserve the earlier audience decision and identify which recipients require an update. Do not overwrite a list after a notice has been sent.
Coordinate the notice with response work
The message owner needs the current product scope, observed risk, user action, and support route. Security and communications should work from the same approved facts, while legal review considers timing and sensitivity. Use a versioned notice so later corrections remain visible.
Preserve the channel, audience definition, content, send or publication time, delivery evidence, and any follow-up. If several channels are used, record what each audience actually received.
Treat timing as its own decision
Open the user-notice work when the Article 14 trigger is recognised, not after the authority filing is closed. Record who owns the audience, message, disclosure review, delivery, and support response. Keep the notice status visible beside the reporting clocks while preserving its separate approval path.
Where facts are incomplete, decide which verified information users need now and which point requires an update. Avoid holding an actionable measure for a polished incident narrative, and avoid sending an instruction that engineering has not validated for the affected versions.
Keep the authority fallback visible
Article 14(8) allows notified coordinating CSIRTs to inform users when the manufacturer fails to do so in a timely manner and authority action is proportionate and necessary to prevent or mitigate impact. That is a fallback power, not a communications plan for the manufacturer.
Assign the user-notice task at the same moment as the reporting case. Track it to evidence-backed completion, with an owner distinct from the person who closes the platform submission.
The completion packet should show the approved audience rule, notice version, channel, dispatch time, delivery or publication evidence, failed deliveries, and follow-up owner. A copy of the text alone does not show whom the manufacturer informed.
Continue this workflow with the user-notice drafting workflow and the delivery-evidence packet.