A security update is only useful if affected users can identify it, obtain it and understand what to do. CRA communication should connect the vulnerability, affected versions, corrected release, installation instructions and support information without burying the security message inside ordinary feature release notes.
Tell Users When a Security Update Is Available
Annex I Part II point 8 requires available security updates addressing identified security issues to be disseminated without delay and accompanied by advisory messages. The communication should therefore make the availability of the security correction clear rather than requiring users to infer it from a general product update feed.
- Identify the security update.
- State that it addresses a security issue.
- Publish the notice promptly.
- Keep the notice connected to the affected product.
Identify Affected and Corrected Versions
Users need to know whether their product version is affected and which release contains the correction. Version-specific communication reduces the risk that customers install the wrong package or assume an older branch is safe merely because another branch has been fixed.
- Affected product versions.
- Corrected versions.
- Branch-specific packages where relevant.
- Release or update identifier.
Use Advisory Messages to Explain User Action
Annex I Part II point 8 requires advisory messages to provide relevant information, including potential action to be taken. The notice should explain whether the update installs automatically, requires manual action, needs a restart, depends on configuration changes or has another operational prerequisite.
- Explain required user action.
- Identify important prerequisites.
- State whether installation is automatic or manual.
- Explain temporary mitigation where relevant.
Point Users to Clear Installation Instructions
Annex II point 8(c) requires information on how security-relevant updates can be installed. The update notice should connect users directly to the correct instructions for the product and version. If a security update uses an exceptional manual or offline path, the notice should explain that process rather than relying on ordinary update documentation that does not apply.
- Link to the correct installation path.
- Identify package or version prerequisites.
- Explain exceptional update procedures.
- Confirm how users can verify installation.
Keep Security Communication Separate From Feature Marketing
A release may contain both security fixes and new functionality, but users should not have to search through marketing material to discover a security correction. Security advisories should make the security relevance visible and should identify the remediation even where the same software package also includes feature changes.
- Label security content clearly.
- Avoid hiding security fixes in feature notes.
- Use consistent advisory identifiers.
- Keep remediation instructions prominent.
Coordinate With Fixed-Vulnerability Disclosure
Annex I Part II point 4 requires public information about fixed vulnerabilities once a security update has been made available, subject to the specific justified-delay provision. Update availability communication and fixed-vulnerability disclosure should therefore use consistent affected-version, severity and remediation information.
- Use consistent affected versions.
- Use consistent fixed versions.
- Coordinate severity and impact wording.
- Document justified disclosure delay where applicable.
Connect Update Availability to the Support Period
Annex II point 7 tells users the support period during which they can expect vulnerabilities to be handled and security updates to be provided. Security-update communications should therefore be consistent with the public support status of the product. An update notice should not imply continuing active support beyond the communicated support period unless the manufacturer has actually extended it.
- Check product support status.
- Keep support dates consistent.
- Avoid creating contradictory support expectations.
- Explain exceptional post-support corrections carefully.
Keep Issued Security Updates Available for the Required Period
Article 13(9) requires each security update issued during the support period to remain available for at least 10 years after issuance or for the remainder of the support period, whichever is longer. Communication architecture should therefore preserve durable links or another reliable path to historical security updates rather than removing them when a product page is redesigned.
- Preserve issued update packages.
- Use durable download or distribution paths.
- Retain version and release information.
- Keep historical advisories accessible.
Maintain a Consistent Update Communication Record
The manufacturer should retain the security advisory, release date, affected versions, corrected versions, installation instructions and distribution location as part of the vulnerability record. This supports consistent customer communication and makes it easier to demonstrate that an available security update was actually communicated and made accessible.
- Security advisory.
- Release date.
- Affected and fixed versions.
- Installation instructions.
- Distribution location.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.