Annex I Part II (4) Disclosure of fixed vulnerabilities

Annex I Part II (4) CRA vulnerability disclosure: what the requirement asks

Once a security update is available, the manufacturer must tell the public what was fixed. Annex I Part II point (4) of the Cyber Resilience Act requires manufacturers to share and publicly disclose information about fixed vulnerabilities. A usable disclosure contains a description of the vulnerability, information that identifies the affected products and versions, the impacts, the severity and clear remediation information telling users what to do. The requirement exists because a patch that nobody knows about protects nobody. Users who run an affected version without knowing a fix exists stay exposed, and customers cannot judge their own risk without knowing which product lines, builds or deployment models are involved. Your product security or PSIRT team owns this duty, and the advisory text should be reviewed by engineering for technical accuracy and by legal for claims. Point (4) allows a delay in duly justified cases, where the manufacturer considers that the security risks of publication outweigh its benefits. The delay runs until users have had a chance to apply the patch, so it is a short window tied to deployment, not an open-ended hold. Record the justification at the time of the decision, who approved it, and the date the advisory was released. Keep this separate from the Article 14(8) duty to inform affected users while risks persist, which Commission guidance C(2026) 5252 treats as a different obligation. Confirm the exact wording of the delay justification and how assessors will test it against the current Commission guidance before relying on it. The hard part is usually consistency rather than drafting a single advisory. Affected product versions, support branches and components inherited from third parties must match what the vulnerability tracker, the SBOM and the release notes say, or the advisory will misidentify who is exposed. Severity ratings also need one method applied across products, so a score in one product line does not contradict another. Plan a review step that checks identifiers, version ranges and remediation steps against the fixed build before publication. Tracking tools such as DefectDojo can hold the finding history that supports these checks, but the advisory content and its approval remain the manufacturer's responsibility.

Which products, vulnerabilities and teams fall under point (4)

Point (4) applies to products in scope of the Cyber Resilience Act, and only once a security update exists for a fixed vulnerability. The decisions below determine which products, which flaws and which people your disclosure process must cover, so settle them before the first advisory is drafted.

Products in scope and support period

Start with the inventory of products with digital elements that you place on the EU market, including versions still supported after launch. Point (4) follows the support period, so a product that remains in support must keep receiving disclosures for fixed flaws. Confirm which versions are still maintained and which have reached end of support, and record that date per product. Products placed on the market before 11 December 2027 are generally outside the regulation unless substantially modified, so check that status product by product.

Product code versus third-party components

Decide whether a disclosure covers only flaws in your own code or also flaws in libraries, runtimes and other components you ship. Point (4) asks for information that identifies affected products, so a component flaw still needs a clear statement of which of your products and versions are affected. Map each shipped component to the products that include it, using the SBOM from point (1), so that a component advisory can name the affected products accurately.

Which vulnerabilities trigger a disclosure

Define the trigger: a vulnerability becomes subject to point (4) once a security update is available and fixes it. Flaws still awaiting a fix fall under other duties, such as the duty to inform users under Article 14(8), so they are not handled as public advisories yet. Write the rule into your procedure so that intake, triage and release teams apply the same test. Confirm whether low-severity findings, hardening fixes and findings from internal testing also need an advisory.

Who owns the advisory

Name the owner of each published advisory and the approver who signs off on its content. Product, security and legal functions usually share this work, but one accountable role should hold the decision on whether a delay is justified and on the wording of impact and severity. Document the handoffs between the vulnerability intake team, the engineering team that ships the fix and the publication team. Record who approved each disclosure so that a market surveillance authority can trace the decision.

Contracted and tailor-made products

Identify products built to order for a single business customer, and separate them from standard products that you sell to many users. Point (4) applies to products in scope, so a tailor-made product needs a decision on whether a public advisory is required or whether the agreed customer channel is sufficient, and that decision should be recorded in the contract or product file. Ask your legal team to confirm how the exception for tailor-made products in point (8) interacts with your customer agreements before you commit to a model.

How CRA disclosure differs from the duty to inform users

The Article 14(8) duty to inform users and the Annex I Part II point (4) public disclosure duty are two separate obligations, and the Commission's guidance C(2026) 5252 (section 9.1) keeps them apart. The Article 14(8) duty concerns users who are exposed while a risk is still open. It may be limited to the affected users, because a broadcast to everyone during an active exploit can hand attackers a map of who is still unpatched. Point (4) is different: once a security update is available, the manufacturer shares and publicly discloses information about the fixed vulnerability, so that the wider population of users and the security community can learn about it.

A team will often need both. During an active exploit, the first communication is a user-facing notice aimed at the people running the affected version: what is happening, whether they are exposed, and what interim mitigation is available. That notice can precede any patch and does not have to be a full vulnerability description. Once the fix ships, the public advisory under point (4) follows. Confirm with your legal and product security leads whether the early notice and the advisory will be issued from the same channel, and whether either one is drafted before an incident occurs.

The two documents must contain different things. The point (4) disclosure carries a description of the vulnerability, information that identifies the affected products and versions, the impacts, the severity and clear remediation steps for users. The Article 14(8) notice focuses on the immediate risk and what users should do now. Check that the severity and affected-product fields match across both, and record the reasoning for any decision to delay public disclosure under point (4), because that justification is what an authority will ask to see.

How to build a disclosure process that produces CRA-ready advisories

This sequence turns a fixed vulnerability into a published advisory that covers every content element of point (4), with a recorded decision for each publication or delay. Each step closes with a record an assessor can inspect.

Set the trigger for security update availability
Define in writing the event that starts the disclosure clock: the moment a security update, patch or mitigation is available for the affected versions. Product security and the release owner agree on who declares that event and which systems feed it, such as the vulnerability management queue and the release pipeline. The trigger should be tied to a release identifier so that the start point is reproducible. Output to show an assessor: the trigger procedure, the named role that declares availability, and a sample ticket showing the date a fix became available for a real or illustrative finding.
Define the advisory template
Build one advisory template with a required field for each element point (4) names: a description of the vulnerability, information to identify the affected products and versions, the impacts, the severity, and clear remediation information for users. Add fields for the fix version, the workaround if one exists, and the links to the update. Keep the template in a versioned wiki or document system so that changes are traceable. Output to show an assessor: the approved template, its version history, and a completed example advisory showing every field filled.
Assign publication approval
Name the people who approve an advisory before it goes public, typically product security, engineering owner and legal or communications for wording. Write the approval rules, including who may approve a delay and who must be consulted when risk to users is disputed. Record approvers and their roles in the process document so that the approval chain can be reconstructed later. Output to show an assessor: the approval matrix, the delegation list, and the signed approval recorded against each advisory.
Record any delay decision with justification
Where the manufacturer considers that the security risks of publication outweigh its benefits, point (4) allows publication to be delayed until users have had the chance to apply the patch. Log each such decision with the risk reasoning, the decision maker, the date of the decision and the date users were able to apply the patch. Review open delays on a fixed cadence set by your own process, so that no advisory is held indefinitely. Output to show an assessor: a delay register with justification, decision date, and the patch availability date for every delayed advisory, plus the publication date when it was released.
Publish the advisory to users
Publish the approved advisory at the location your coordinated vulnerability disclosure policy names, and make it discoverable from the product's support pages. Where the advisory is also a vulnerability notification under Article 14, confirm that it is consistent with the reporting record and with any information given to users under Article 14(8). Preserve the published version and its timestamp. Output to show an assessor: the public URL or distribution record, the publication timestamp, and the archived copy of the advisory as published.
Track outcome and update the record
After publication, track whether affected users applied the fix, whether the advisory required correction, and whether the vulnerability has been added to the European vulnerability database under Article 17(5) with manufacturer agreement. Feed corrections back into the template and the approval rules. Close each advisory record only when publication, approval and outcome fields are complete. Output to show an assessor: the closed advisory records, the correction log, and evidence of any update to the template or process following lessons learned.

How an assessor tests CRA point (4) disclosure

This table sets out what an assessor checks for Annex I Part II point (4), the duty to publicly disclose fixed vulnerabilities, along with the evidence requested and the findings that most often come up. Read each row as a test: the left column names the check, the middle column describes how it is run, and the right column shows where manufacturers usually fall short. The main takeaway is that disclosure is tested against the timing and content of each published advisory, so records must tie each advisory to a specific security update and its release date.

Test area	What the assessor checks	Common finding
Advisory content	Each published advisory includes a description, information to identify affected products, the impacts, the severity and clear remediation steps for users	Advisories name a product family but omit affected versions, or give severity without the impact it describes
Timing against the fix	Publication date is later than the date the security update became available to users	Advisory goes live before the patch is downloadable, or the two dates are not recorded at all
Delayed publication	Any delay has a written justification showing the security risk of publication outweighed its benefit, and a date by which users could apply the patch	Delays are informal, lack a rationale, or have no recorded end date
Consistency across versions	The same vulnerability is described the same way in every affected release line, branch and channel	Severity or fixed-version information differs between the release notes, the advisory and the update server
Traceability to records	Each advisory links to the vulnerability record, the fix commit or release and the scanning or triage evidence behind it	Advisories are written from memory, so the assessor cannot trace them to the vulnerability handling records
Version history	Changes to a published advisory are logged, with who changed it, when and why	Advisories are edited in place with no history, so the assessor cannot tell what was known at publication
Interaction with user notification	Public disclosure is kept separate from the duty to inform affected users while risks persist, and both are evidenced	Teams treat a customer email as satisfying public disclosure, or the reverse, without records for each

Evidence that shows CRA vulnerability disclosure works

Disclosure under Annex I Part II (4) is judged by records, not by a single published notice. The artifacts below show that each advisory was complete, timed against the fix, and kept accurate as the product changed over its support period.

Complete published advisories

Each published advisory should carry a description of the vulnerability, information that identifies the affected products and versions, the impacts, the severity, and clear remediation steps for users. Check that every advisory contains all five elements and that none is published as a bare notice with a patch link. An assessor will compare the advisory text against the fix to confirm the remediation guidance is accurate for the versions named.

Fix-availability timestamps

Record when the security update became available for each vulnerability, separately from when the advisory was published. The gap between the two shows whether disclosure followed the fix as the point (4) sequence requires. Keep the timestamp in the vulnerability record and link it to the release that contains the fix, so the timing can be reconstructed without relying on memory.

Approved advisory templates

Standard templates fix the structure of each advisory so that severity, affected products and remediation appear in the same place every time. Store the approved templates in a controlled wiki or document system with an owner and an approval record. Confirm that the template used for each published advisory matches the approved version in force on the publication date.

Delay decision records

Where publication was delayed until users could apply the patch, keep a dated decision record stating the justification, the risk comparison and the approver. Point (4) allows a delay only in duly justified cases where the security risks of publication outweigh its benefits. Assessors will look for records that explain why the delay was needed and when publication followed, and they will question any delay with no record.

Advisory register by product and version

Maintain a register that lists every disclosed vulnerability by product, version, severity, fix release and publication date. The register lets you show, for any product version in its support period, which vulnerabilities were disclosed and whether each was fixed. Export it at each audit and reconcile it against the scanner and tracker records that produced the findings.

Records of advisory updates

Advisories often change after publication when new affected versions are identified or remediation steps are corrected. Keep the revision history showing what changed, when, and who approved it, and make sure the public version reflects the latest record. Confirm that access rights to edit advisories are limited to the roles that own the process.

What meeting CRA vulnerability disclosure costs in money and effort

This table lists each cost component of publishing advisories for fixed vulnerabilities under Annex I Part II (4), who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a quote request, since no price is set in the regulation or in this table.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down, and what to ask for
Tooling and licenses	Software vendors, or the internal team for self-hosted tools	Recurring for commercial licenses, one-time for setup	Commercial advisory platforms charge per seat or product. Self-hosted open-source tools such as DefectDojo (BSD-3-Clause) remove license spend but still need hosting and administration. Ask for each license and hosting cost separately.
Engineering and security time to write advisories	Internal product security and engineering staff, or an implementation partner under a fixed-scope agreement	Recurring with each security update	Effort rises with the number of products, the number of supported versions and the number of fixes per release. Ask the partner to state assumed advisory volume and what counts as one deliverable.
Review and approval of advisory content	Product security, engineering leads and sometimes customer success or communications	Recurring with each advisory	Review cycles lengthen when severity, impact or affected-product lists are unclear. A written template for description, affected products, impact, severity and remediation shortens review.
Legal or product approval for delayed publication	Legal counsel, product owners and risk committees	Recurring, only when a delay is invoked	A delay must be duly justified under point (4), so each delay needs a documented risk comparison. Costs rise with the number of delay decisions. Ask who signs off and how each decision is recorded.
Evidence upkeep	Internal compliance or a partner preparing records	Recurring across the support period	Keeping dated advisories, version history and decision records current is ongoing work. Wiki-style tools such as XWiki (LGPL-2.1-or-later) keep version history and rollback, which reduces rework. Ask how long records are retained and where they are stored.
External review	Independent security testers or reviewers	Recurring, at a frequency set by risk	Scope depends on how many products and versions are covered and how often testing happens. Ask for the review scope in writing and whether it covers advisory accuracy as well as the underlying fix.
Auditor or assessor time	Independent auditor, assessor or notified body, where an assessment route requires one	One-time for initial assessment, recurring for surveillance	Most products follow self-assessment under module A, so audit time may be limited. Where a notified body is involved, its fees depend on its own scope. Confirm with the assessor which evidence it will examine.
Hosting and operations for disclosure channels	Internal platform team or an implementation partner	Recurring	Self-hosted advisory publication, vulnerability tracking and access control add operating cost. Ask for hosting, backup, upgrade and support obligations as separate line items in the quote.

Self-hosted open-source tools that support disclosure evidence

Disclosure is only as credible as the records behind it. The four tools below, all self-hosted and open source, can hold the findings, scan history, advisory revisions and approval trail that a manufacturer may need to show when it publishes details of a fixed vulnerability. None of them makes a disclosure compliant on its own, and each carries its own license terms, so confirm the fit with your environment before you rely on it.

Linking findings to fixes

DefectDojo (BSD-3-Clause) imports and reimports findings from more than 500 security tool report formats, including in the open source edition, and it also accepts a generic findings import. Its deduplication relies on per-tool hashcode fields, so one vulnerability reported by several tools is recorded once. Keep the finding identifier, the fixed version and the advisory reference in the same record, so the public description can be traced to the update users receive. Confirm that your scanners' report formats appear in the supported list before you depend on automatic import.

Scan results and retest records

Greenbone Community Edition (AGPL-3.0-or-later) runs vulnerability scans through gvmd, which stores results in PostgreSQL and manages users, permissions and scheduled scan tasks. Analysts review the results in the Greenbone Security Assistant web interface. Retained scan records show which product versions were tested and what was found before the fix, which supports the list of affected products in a disclosure. Because AGPL terms can apply when you modify the software and offer it over a network, have counsel review the license before you embed it in a customer-facing service.

Advisory version history

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For disclosure, this lets you reconstruct how an advisory was drafted, revised after the security update and finally published, with who changed what and when for each step. Check that your backup and retention settings keep the full history, since a gap in the revision trail weakens the evidence even when the published text is correct.

Approval controls by role

BookStack (MIT) grants abilities through the roles assigned to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. This makes it practical to let engineers draft advisory text while only a named product security role can edit or publish the final page. Review role assignments on a fixed schedule and record who holds each role. BookStack enforces the access rules, but it does not record a sign-off decision by itself, so keep the approval note in the advisory or in your tracking system as well.

Who owns CRA disclosure, what a partner does and where the auditor stops

Your organization owns the Annex I Part II point (4) duty. The manufacturer must decide what to disclose, when, and in what form, and it is accountable for that decision in front of market surveillance authorities. Internal roles need clear assignments before the first fix ships, because disclosure decisions tend to stall between teams.

Product security owner: Decides whether a fixed vulnerability meets the threshold for public disclosure, records the severity and impact, and signs off on any delay justified by the security risks of publication.
Legal and communications approval: Reviews advisory wording for accuracy and exposure, confirms that customer contracts and any notification obligations are consistent with the advisory, and approves the publication channel.
Engineering release staff: Confirms which versions are affected and fixed, supplies identifiers for affected products, and makes sure the remediation steps in the advisory match what the released update actually does.
Support and operations: Publishes the advisory where users can find it and keeps the record of publication dates for later review.

Check that each role has a named person, a written decision path and a record of who approved each advisory.

Questions buyers ask about CRA vulnerability disclosure

How long does it take to set up a vulnerability disclosure process?

The duration depends mostly on how many products are in scope, how mature your existing vulnerability handling is, and whether a disclosure workflow already exists. The regulation does not set a number of weeks for setup. The work usually covers three parts: deciding who approves an advisory, building a template for the Annex I Part II point (4) content, and connecting your vulnerability findings to a place where fixed issues can be tracked. Ask any partner for a fixed-scope plan that lists products, deliverables and dates in writing before work starts. Confirm the setup timeline against your own release calendar, since the first advisory you publish will depend on your next security update cycle.

How much effort does the product team need to put in?

Effort falls on engineering, product and support staff, and it recurs with every fixed vulnerability. Each disclosure needs an accurate description, the list of affected product versions, the impact, the severity and clear remediation steps for users. Engineers supply the technical facts, while product owners confirm which customers and versions are affected. The effort rises with the number of products, the number of supported versions and the number of third-party components that carry their own advisories. It falls when identification and tracking are automated and when advisory templates are already written. Ask a prospective partner which of these tasks it performs and which your team must still own.

Can a small team run vulnerability disclosure in-house?

A small team can run disclosure in-house if it has a named owner, a written procedure and enough engineering time to verify fixes before publication. The core duty is not large in volume for a single product, but it is continuous across the support period, so it needs a standing owner rather than an occasional task. Open-source tools can help track findings and store drafts. For example, DefectDojo can import findings from many scanner formats and deduplicate them, and BookStack or XWiki can hold versioned advisory pages with recorded changes. Partners can help write the procedure and set up the tooling, but your organization still owns the decisions and the published content.

What happens when a patch is delayed?

Point (4) allows publication to be delayed in duly justified cases where the manufacturer considers that the security risks of publishing outweigh the benefits, until users have had the chance to apply the patch. The justification must be real and documented, so record why the delay was chosen, who approved it and when publication is expected. A delay does not remove the wider duty to inform users. Commission guidance C(2026) 5252 distinguishes the Article 14(8) duty to inform users, which may be limited to affected users while risks persist, from the Part II point (4) public disclosure duty after a security update. Confirm with your national authority or counsel how a delay will be reviewed in your case.

Can an outside partner sign off our security advisories?

A partner can draft, review and format advisories, but the manufacturer must approve and publish them, because the manufacturer owns the obligation. An implementation partner prepares the procedure, templates and evidence. It does not issue assessment reports, certificates or regulatory approvals, and no advisory should imply that an outside party has verified it unless that party actually did so. Put the approval chain in writing: who drafts, who checks technical accuracy, who approves publication and who holds the final decision on a delay. Ask any partner to state which steps it performs under the agreed scope and which remain with your named staff.

What will an assessor ask to see for disclosed vulnerabilities?

An assessor will look for evidence that every fixed vulnerability was disclosed in line with point (4), and that the record of each decision is kept. Typical evidence includes the published advisories with their dates, the severity and affected-version information, the remediation guidance, the decision records for any delay, and the link between each advisory and the security update it describes. Keep version history for advisory pages, so you can show what changed and who changed it. Confirm with your conformity assessment body or notified body which evidence it expects for your product class, since the route differs for self-assessed and independently assessed products.

What drives the cost of a disclosure program?

Cost has three parts: the one-time setup of procedures, templates and tooling; the recurring effort of writing and approving each advisory; and any retainer for ongoing support or testing. The main drivers are the number of products, the number of supported versions, the volume of vulnerabilities from your own testing and from third-party components, and how much of the workflow is automated. Open-source tools reduce licensing spend but still need configuration and staff time. Ask for a quote built from a written scope that lists products, versions, tooling and deliverables. DeployOpen does not publish a price list, and a quote follows from that scope.

How DeployOpen prepares CRA disclosure processes and evidence

DeployOpen helps manufacturers build the workflow that turns a fixed vulnerability into a public disclosure with a clear description, affected products, severity and remediation steps. The manufacturer keeps ownership of the disclosure decisions, and DeployOpen prepares the self-hosted systems, records and evidence that show how those decisions were made and carried out.

How we scope

Engagements are fixed-scope, so the written scope names which products, versions and disclosure channels are covered.
The scope records who decides on disclosure timing and who approves delayed publication under point (4).
We confirm which open-source trackers and documentation systems will hold disclosure records, and who can edit them.

How we build

We configure a self-hosted vulnerability register, such as DefectDojo, to hold findings and deduplicate them before any disclosure decision.
We set up versioned advisory pages in a wiki such as XWiki, so each disclosure draft and its edit history can be reviewed.
We configure role-based permissions in a documentation tool such as BookStack so advisory publication is restricted to approved roles.

How we hand over

We deliver a written disclosure procedure with templates for description, affected products, impact, severity and remediation guidance.
We document each decision to delay publication, including the justification and the date users were able to apply the patch.
We provide a record of configuration, roles and test runs so your assessor or market surveillance authority can trace the evidence.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We help your team rehearse a disclosure from a fixed vulnerability to a published advisory before a real release depends on it.
Confirm with your legal and compliance advisers how Article 17 and the point (4) duty interact with your own obligations before you rely on this workflow.