Security advisories: when and how to publish a fixed vulnerability

The last step of the vulnerability-handling process is the most visible one: an advisory — a public notice that you have fixed a security problem. The Cyber Resilience Act requires it in Annex I, Part II: once a fix is made available, the manufacturer must publish information about the vulnerability. Let's look at when to issue it and what to write in it.

Why issue an advisory at all

An advisory serves two purposes at once. For users it's a signal to "update, and here's why" — without it they don't know a quiet update fixes something security-related, and they'll postpone it. For you it's evidence the process works: a transparent, dated notice you can show to a customer or a surveillance authority. And for the whole ecosystem it's a contribution to databases (e.g. via an assigned CVE), so that those who use your component further downstream also learn about the problem.

When to publish it

Timing is the heart of the word "coordinated". A simple rule applies: you usually issue the advisory only once the fix is available — so that publishing doesn't hand attackers a recipe before users can protect themselves. If an agreement with the reporter or other circumstances set a different time (e.g. an agreed deadline elapsing), follow that. The goal is always the same: at the moment of publication, the user has something to do.

What an advisory should contain

A good advisory is short and specific. It should answer what the user needs to know to decide and act:

1. Identifier and title. Your own advisory number and, if assigned, a CVE.
2. Description of the vulnerability. What it concerns, what type of problem it is — without unnecessary detail that would be a recipe for attack.
3. Affected products and versions. Which versions are vulnerable and which is not — this is the most important line for the user.
4. Severity and impact. An indicative severity (e.g. CVSS) and what's at risk if not updated.
5. How to fix. Which version to move to, and any temporary mitigation (workaround) until updating is possible.
6. Credit and date. When it was issued and any acknowledgement of the reporter (per your CVD policy).

What to leave out

An advisory is not an exploit. Leave out the precise technical recipe for exploitation (a proof-of-concept that saves an attacker work), internal infrastructure details and personal data. The balance is simple: enough for a user to decide and protect themselves, no more. Equally, avoid both downplaying ("nothing serious") and scaremongering — write factually.

What a short advisory can look like

It needn't be a long document. An example structure for a small company:

1. Title: "ADV-2026-003: Input-handling vulnerability in component X".
2. Affected versions: 2.3.0 – 2.4.1. Fixed in: 2.4.2.
3. Severity: high (CVSS 8.1). Impact: unauthorised access to … when condition … is met.
4. Recommendation: update to 2.4.2. Temporary mitigation: restrict … until you can update.
5. Date and credit: issued 2026-05-12, thanks to the reporter (if they agreed).

That's the whole "recipe" — the user immediately sees whether it affects them and what to do. No proof-of-concept, no internal details.

Where to publish an advisory

An advisory belongs where users will find it: a public "Security advisories" page on your site, or in the release notes for the fixed version. If you have an assigned CVE, include its number so the advisory can be linked to databases (NVD, OSV). Don't delete old advisories — they form a history that is, for a customer and a surveillance authority, evidence the process actually runs.

How it fits the chain

An advisory is the end of a chain that starts with a reporting channel and security.txt, continues with a CVD policy and a finding lifecycle (new → assessed → fixed → advisory). Once you have that flow in place, every advisory is just a natural last step, not firefighting. And if the vulnerability has meanwhile become actively exploited, a report under Article 14 runs in parallel — that's a separate duty with its own deadlines.

FAQ

1. Do we need a CVE to issue an advisory? No. A CVE helps link the advisory to databases, but you can issue one with your own identifier.
2. Should we publish vulnerabilities we fixed "quietly"? Annex I Part II requires publishing information about a vulnerability once a fix is available — silent fixes with no notice go against the spirit of this duty, and users don't know why to update.
3. How much detail is right? Enough for a user to decide and protect themselves; not so much that it's a recipe for attack.

Why an advisory is also in your interest

Beyond the duty, an advisory has a practical benefit: when a user sees a clear "update to 2.4.2 because …", the fix actually gets deployed and you reduce the number of vulnerable installations in the field. Without an advisory, many users stay on the old version, not knowing that "ordinary" update was a security one. A history of advisories is also evidence to customers that you take your process seriously — which you'll appreciate at supplier questionnaires.

Key point

An advisory is the last and most visible step of vulnerability handling — and Annex I, Part II requires it: after a fix is available, publish information about the vulnerability. Timing is the heart of the word "coordinated": you usually release it only once a fix is available, so you don't give attackers a head start over users. A good advisory is short and specific — an identifier, a description, affected and fixed versions, severity and impact, how to fix, and a date. Leave out proof-of-concept and internal details; the goal is for a user to know whether it affects them and what to do. An advisory helps you too: more users actually update, cutting the number of vulnerable installations, and a history of advisories is evidence the process runs — which you'll appreciate in supplier questionnaires. If the vulnerability has meanwhile become actively exploited, Article 14 reporting runs in parallel — a separate duty with its own deadlines.

How CRAguard helps

CRAguard pre-fills an advisory from the finding (affected versions, severity, fixed version), lets you edit the text, and publishes it on your public advisories page — all with an audit trail you can then show a customer. Find out whether the CRA applies to you, or join the waitlist.

This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Annex I Part II) and the European Commission's guidance of 27 July 2026.