When a manufacturer fixes a vulnerability under the Cyber Resilience Act (CRA), publishing a vague release note such as “security improvements” is not enough. Annex I, Part II requires manufacturers to disclose specific information about fixed vulnerabilities once a security update has been made available, so users can understand whether they are affected and what they should do.
The practical objective is straightforward: connect the fixed vulnerability to the affected product, explain the security consequence, communicate severity, and give users clear remediation information. A good advisory also makes the patch scope unambiguous enough for operators, support teams and security teams to act without reconstructing the issue from several unrelated sources.
What the CRA explicitly requires after a vulnerability is fixed
Annex I, Part II, point 4 of Regulation (EU) 2024/2847 establishes the core public-disclosure requirement. Once a security update has been made available, the manufacturer must share and publicly disclose information about fixed vulnerabilities.
The disclosed information must include:
- a description of the vulnerability;
- information that allows users to identify the affected product with digital elements;
- the impact of the vulnerability;
- the severity of the vulnerability; and
- clear and accessible information helping users remediate the vulnerability.
Point 8 adds an operational requirement around the update itself. Where security updates are available to address identified security issues, they must be disseminated without delay and accompanied by advisory messages containing relevant information, including potential action users may need to take.
These two requirements belong together. Point 4 defines the public information expected about the fixed vulnerability, while point 8 ensures the security update is communicated with information that helps users act.
Start with precise affected-product identification
An advisory cannot support remediation if users cannot determine whether it applies to their product.
The CRA requires information allowing users to identify the affected product. In practice, manufacturers should make the scope as precise as the product and release model permits. Useful identifiers can include:
- product name and model;
- product family or variant;
- affected software or firmware versions;
- affected release ranges;
- affected component versions where that information is useful to the user;
- fixed software or firmware version; and
- relevant hardware revision or configuration when exploitability depends on it.
Do not publish a broader affected range merely because it is easier to describe. Equally, do not narrow the range without evidence. The advisory should reflect the manufacturer's actual vulnerability analysis and release scope.
For products with several supported branches, state the status of each branch separately. For example, one branch may receive a patch while another requires an upgrade to a later supported release. That distinction is operationally important to the user.
Describe the vulnerability without turning the advisory into exploit instructions
The CRA requires a description of the fixed vulnerability, but it does not require manufacturers to publish unnecessary exploitation detail.
A useful description explains:
- what security weakness existed;
- which product function or trust boundary was affected;
- what preconditions are relevant to exploitation; and
- what type of security outcome could result.
For example, describing that insufficient authentication on a management interface could allow an authenticated low-privilege user to perform an administrative action is more useful than writing only “access-control vulnerability fixed.”
At the same time, disclosure should be proportionate. Technical detail that materially helps defenders understand exposure is useful. Step-by-step exploit instructions, secrets, private test material or unnecessary proof-of-concept detail may create additional risk without improving remediation.
Separate impact from severity
Impact and severity answer related but different questions, and the CRA explicitly calls for both.
Impact explains what could happen if the vulnerability is exploited. Examples include unauthorised access to data, modification of configuration, execution of code, privilege escalation, denial of service or loss of an essential security function.
Severity communicates the assessed seriousness of the vulnerability. A manufacturer may use an established scoring system such as the Common Vulnerability Scoring System (CVSS), an internal severity scale, or another defensible method appropriate to the product context.
If a numeric score is used, preserve the information needed to understand it. A score without the scoring version, vector or product-specific context may be difficult to interpret later.
The advisory should also avoid presenting severity as a substitute for product-specific risk analysis. The same vulnerability can have different operational consequences depending on deployment, exposure, configuration and the functions the product performs.
Give users a remediation path they can actually execute
The CRA requires clear and accessible information helping users remediate the vulnerability. The advisory therefore needs more than “update to the latest version” when the update path is not obvious.
Depending on the product, remediation guidance can include:
- the exact fixed version;
- where and how the security update is obtained through the manufacturer's normal trusted update mechanism;
- prerequisites for installation;
- whether a restart, service interruption or configuration change is required;
- how the user can verify that the fixed version is installed;
- supported migration paths from older affected versions; and
- temporary mitigation where immediate patching is not possible.
A workaround should be clearly distinguished from a permanent fix. If a mitigation only reduces exposure, say so. Users should not be left to infer that a temporary configuration change permanently resolves the vulnerability.
Distinguish CRA-required content from useful advisory fields
Security-advisory practice often includes fields beyond the CRA's explicit minimum disclosure elements. ENISA's coordinated vulnerability disclosure material, for example, discusses information such as affected platforms and configurations, CVE references, workarounds, disclosure timelines, exploit availability and advisory revision history.
Those fields can make an advisory substantially easier to consume, but they should be labelled conceptually as operational good practice rather than presented as textually mandatory CRA fields.
A practical advisory record may therefore contain:
| Field | Why it is useful | | --- | --- | | Advisory identifier | Gives support and security teams a stable reference | | CVE identifier, where assigned | Connects the issue to vulnerability databases and tooling | | Affected versions | Defines exposure precisely | | Fixed versions | Defines the target remediation state | | Impact | Explains the possible security consequence | | Severity and scoring context | Communicates assessed seriousness | | Remediation instructions | Tells users how to resolve the issue | | Workaround or mitigation | Provides a temporary risk-reduction option where relevant | | Publication and update dates | Shows advisory chronology | | Revision history | Makes later corrections or scope changes visible | | Credits, where appropriate | Records the reporting or coordination context |
The compliance distinction matters: optional fields can strengthen clarity and operational usefulness, but a long advisory does not compensate for omitting one of the CRA's required core elements.
When public disclosure may be delayed
Annex I, Part II, point 4 contains an important exception. In duly justified cases, a manufacturer may delay public information about a fixed vulnerability where it considers the security risks of publication to outweigh the security benefits.
The delay is not an open-ended alternative to disclosure. The regulation ties it to giving users the possibility to apply the relevant patch before the information is made public.
A manufacturer using this exception should retain the reasoning behind the decision. Useful internal evidence includes:
- the security risk identified in immediate publication;
- the expected benefit of allowing a patch window first;
- who approved the delay;
- when the security update became available;
- which users or distribution channels received access to the update;
- the planned public-disclosure point; and
- the final publication date.
This makes the exception auditable later instead of relying on an undocumented judgement made during an incident.
Do not confuse a fixed-vulnerability advisory with Article 14 reporting
Public disclosure of a fixed vulnerability under Annex I and regulatory reporting under Article 14 are different workflows.
Article 14 concerns actively exploited vulnerabilities and severe incidents and has its own reporting triggers, recipients, information requirements and deadlines. A vulnerability can require an Annex I fixed-vulnerability advisory without having triggered Article 14 reporting, and an Article 14 case can begin before a final patch and public fixed-vulnerability advisory exist.
Operationally, the records should still be connected. If the same vulnerability passes through intake, exploitation assessment, regulatory reporting, remediation, security-update release and public disclosure, the manufacturer should be able to trace those stages without treating them as one interchangeable action.
Keep the advisory tied to the exact security update
A common evidence problem occurs when the vulnerability record, the patch, the released product version and the public advisory are maintained separately.
For each fixed vulnerability, retain a relationship between:
- the vulnerability identifier or internal finding;
- affected products and releases;
- the remediation decision;
- the code or configuration change that implements the fix, where managed in engineering systems;
- verification or security-test evidence;
- the released security update;
- the fixed product version;
- the advisory revision that describes the fix; and
- publication and update timestamps.
The objective is not to copy all engineering data into the advisory. It is to preserve enough traceability that a reviewer can answer: what was affected, what fixed it, how was the fix verified, which release contains it, and what did users receive?
Treat advisory updates as controlled revisions
Security advisories sometimes change after publication. A manufacturer may discover an additional affected version, revise severity, add a workaround, clarify remediation instructions or correct an inaccurate statement.
Do not silently replace the previous meaning. Keep an advisory revision history that records material changes and dates. Where the change affects exposure or required user action, make that change prominent enough that users do not continue acting on outdated guidance.
Internally, preserve the earlier advisory state or an equivalent audit record. This is particularly valuable when the vulnerability decision itself evolves as new evidence becomes available.
Build the advisory into the vulnerability-handling workflow
The most reliable process treats the advisory as an output of vulnerability handling rather than a document assembled from memory after release.
Before publication, verify that:
- the vulnerability is mapped to the correct affected product and releases;
- the remediation or mitigation decision is recorded;
- the security update and fixed version are identified;
- validation evidence supports the fixed state;
- impact and severity are approved and consistent with the internal assessment;
- remediation instructions are usable by the target audience;
- any delayed-disclosure decision has documented justification;
- the public advisory contains the CRA-required core elements; and
- the final advisory and publication timestamp are retained as lifecycle evidence.
This checklist is an engineering and evidence-control pattern, not a substitute for determining the legal obligations applicable to a specific product and vulnerability.
Keeping vulnerability decisions, release evidence and public disclosure aligned becomes difficult when each lives in a different system. AA-sec is designed around traceability between vulnerability work, security evidence, decisions and exact product or lifecycle context, so teams can keep the advisory connected to the release and evidence behind it. AA-sec does not determine exploitability, decide whether disclosure may legally be delayed, or determine CRA conformity.
Key takeaway
For a fixed vulnerability, a CRA-ready advisory should answer five basic questions clearly: what was the vulnerability, which product is affected, what is the impact, how severe is it, and what must the user do to remediate it?
Build optional fields such as CVE references, workarounds, affected-version matrices and revision history around that mandatory core. Most importantly, connect the advisory to the actual security update and retained vulnerability evidence so that public disclosure remains consistent with what engineering fixed and users received.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Manufacturers — European Commission
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- Vulnerability Disclosure — ENISA