A useful CRA security advisory should be version-specific, connected to the actual security update and written for remediation rather than marketing. Customers need to understand which products are affected, what the security issue means, which corrected version or package is available and how to install or otherwise apply the remediation.
Communicate After a Security Update Becomes Available
Annex I Part II point 4 requires manufacturers, once a security update has been made available, to share and publicly disclose information about fixed vulnerabilities. This connects public communication to actual remediation availability. The advisory should therefore identify the update or corrected product version that users can obtain rather than announcing a vulnerability without a practical remediation path where circumstances allow coordinated disclosure.
- Connect disclosure to the available remediation.
- Identify the corrected version or package.
- Publish accurate affected-product information.
- Keep vulnerability and update records linked.
Identify the Affected Product Clearly
Point 4 expressly requires information allowing users to identify the product with digital elements affected by the fixed vulnerability. A broad statement that a manufacturer's software was affected may not be enough where several products, editions, hardware revisions or branches exist. The advisory should use product names, versions, builds, platforms or other identifiers that let customers determine whether their deployment is affected.
- Product name.
- Affected versions.
- Affected platforms.
- Relevant configuration where necessary.
Explain Impact and Severity
The fixed-vulnerability disclosure required by point 4 includes the impacts of the vulnerabilities and their severity. The communication should explain the security consequence in terms meaningful to users, such as unauthorised access, loss of confidentiality, code execution, privilege escalation or denial of service. A severity label should be consistent with the manufacturer's internal assessment and should not replace a clear explanation of actual product impact.
- State severity.
- Explain security impact.
- Describe important prerequisites where useful.
- Keep the advisory consistent with the internal assessment.
Provide Clear Information Helping Users Remediate
Annex I Part II point 4 requires clear and accessible information helping users remediate the fixed vulnerability. The advisory should identify the corrected version, security update or other required action and explain how users obtain it. Where configuration or temporary mitigation is still relevant, that information should be clearly distinguished from permanent remediation.
- Identify the corrected version.
- Identify the security update.
- Explain installation or remediation steps.
- Separate temporary mitigation from permanent remediation.
Security Updates Need Advisory Messages
Annex I Part II point 8 requires available security updates addressing identified security issues to be accompanied by advisory messages providing users with relevant information, including potential action to be taken. The advisory should therefore answer the practical question of what the customer needs to do next rather than functioning only as a technical vulnerability description.
- Explain relevant customer action.
- Identify whether installation is automatic or manual.
- Explain required configuration changes.
- Identify important restart or deployment steps where relevant.
Explain How Security-Relevant Updates Can Be Installed
Annex II point 8(c) requires user information and instructions to explain how security-relevant updates can be installed. Security-update communication should remain consistent with those standing product instructions. If the remediation uses a different emergency process, offline package or manual recovery path, the advisory should explain that difference clearly enough for affected users to apply the correction securely.
- Link to installation instructions.
- Identify prerequisites.
- Explain exceptional update paths.
- Avoid ambiguous package selection.
Use Version-Specific Language
A security advisory becomes much more useful when affected versions and fixed versions are explicit. Statements such as update to the latest version can be insufficient where several supported branches exist or where a user cannot move to the newest major release. The communication should distinguish affected versions, fixed versions and versions confirmed not to contain the vulnerability where that information is useful.
- List affected versions.
- List fixed versions.
- Identify branch-specific updates.
- Avoid ambiguous latest-version wording.
Do Not Mix the Security Advisory With Marketing Release Notes
A product release can contain both security fixes and new functionality, but security communication should remain easy to identify. Users should not need to read a long marketing release note to discover that a serious vulnerability was corrected. Where technically feasible, the CRA also expects new security updates to be provided separately from functionality updates. Communication should make the security relevance unmistakable even when the release contains other changes.
- Label security content clearly.
- Keep remediation information easy to find.
- Separate unrelated feature messaging.
- Reference the relevant security update.
Public Disclosure Can Be Delayed in Duly Justified Cases
Annex I Part II point 4 allows manufacturers in duly justified cases to delay making public information about a fixed vulnerability where they consider the security risks of publication to outweigh the security benefits. The delay can continue until users have been given the possibility to apply the relevant patch. This is a specific security-based exception rather than a general option to delay uncomfortable disclosures for commercial reasons.
- Assess publication risk.
- Document the justification.
- Give users an opportunity to apply the patch.
- Publish when the security justification no longer applies.
Keep Regulatory Reporting Separate From Customer Communication
Customer security advisories and Article 14 regulatory reports serve different audiences and purposes. A public security advisory does not replace a required Article 14 notification, and an Article 14 submission does not necessarily provide customers with the remediation information they need. The manufacturer should coordinate the two processes so facts such as affected versions, severity and remediation remain consistent without confusing public communication with regulatory notification.
- Keep Article 14 reporting separate.
- Keep factual information consistent.
- Coordinate timing where appropriate.
- Do not use one process as a substitute for the other.
Preserve Communication Evidence
The vulnerability case should retain the published advisory, publication date, affected-version information, corrected versions, update identifier and any significant disclosure-delay decision. This makes it possible to show that users received relevant remediation information after the security update became available and that communication remained connected to the underlying vulnerability record.
- Published advisory.
- Publication date.
- Affected versions.
- Fixed versions.
- Update identifier.
- Disclosure-delay rationale where applicable.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.