CRA — Vulnerability handling, coordinated disclosure, and post-market obligations

In one paragraph

The Cyber Resilience Act expects manufacturers of products with digital elements to handle vulnerabilities across the whole product lifecycle — not only at release, not only at end of life. This article explains what the regulator expects, how the NexCyber platform reflects it, and what evidence makes the difference between an audit-ready posture and a fragile one.

What CRA expects, plainly

CRA defines a small set of vulnerability-related obligations that look simple in the text but compound quickly in practice:

• Process and policy — a documented vulnerability handling process owned at the right level of the organisation.
• Coordinated disclosure — a way to receive reports from researchers and partners, acknowledge them, triage them, and respond.
• Identification — a way to be aware of vulnerabilities in your product, including those introduced by third-party components (this is where the SBOM matters).
• Remediation — security updates as the default response, with clear timelines.
• Reporting — to authorities, of actively exploited vulnerabilities and severe incidents, within tight timelines.
• Post-market monitoring — a continuous surveillance, not a one-off audit.

The Help Center article CRA basics covers the wider picture. This page zooms in on vulnerability handling specifically.

The four layers NexCyber tracks for you

NexCyber maps your CRA vulnerability handling to four layers. You will see them as four sections in the assessment workspace.

Layer 1 — Policy and governance

The fundamentals: a written vulnerability handling policy; named roles and responsibilities; integration with risk management; periodic review.

Evidence we expect:

• Policy document (version, owner, last reviewed date).
• RACI for vulnerability handling.
• Board / management approval where applicable.

Evidence we do not want:

• Generic ISO templates with no scope.
• Slides with no signature.

Layer 2 — Identification

How you find vulnerabilities, in three sub-areas:

1. External research — a clear channel where researchers, customers, and partners can report (your security.txt and a published policy).
2. Internal discovery — SAST / DAST / IAST / fuzzing / penetration testing.
3. Supply chain awareness — an SBOM per product and a process that connects the SBOM to a known-vulnerabilities feed (CVE, GHSA, vendor advisories).

Evidence we expect:

• Published vulnerability disclosure policy (RFC 9116 + a Help Center page).
• Internal scan reports with cadence.
• SBOM per product (CycloneDX / SPDX), refreshed at build time.
• Mapping between SBOM and known-vulnerabilities feeds (process description; can be tool-based).

Layer 3 — Remediation

The actual fix flow:

• Triage SLAs (e.g., critical / high / medium / low).
• Patch release process, including out-of-band updates for critical issues.
• Security update distribution path (how the patched binary reaches users).
• Communication to affected users (release notes, advisories).

Evidence we expect:

• A vulnerability lifecycle policy with SLAs.
• Sample advisories for recent fixes.
• Distribution architecture (manifest, signature, transport).

Layer 4 — Reporting and post-market

What you do once a vulnerability is known to be exploited, or once a severe incident occurs:

• Authority reporting playbook (which authority, which channel, which timeline).
• Customer notification playbook.
• Post-incident review and learning loop.
• Ongoing post-market surveillance plan.

Evidence we expect:

• Authority contact list and notification playbook.
• Customer notification template.
• Post-mortem template; recent examples.
• Surveillance plan and metrics.

How the four layers compose into your CRA readiness score

NexCyber weights the four layers by regulatory criticality. Identification and remediation carry the most weight; governance and reporting modulate them. Skipping a layer drops the score even if the others are strong — vulnerability handling is by nature end-to-end, and CRA reflects that.

Coordinated disclosure — what good looks like

CRA does not prescribe a single coordinated disclosure standard, but a small set of practices tends to satisfy auditors:

• A public, machine-readable policy (security.txt at the canonical paths).
• A dedicated contact (security@<domain>).
• A published triage timeline (acknowledge within X business days; triage within Y).
• A safe-harbor clause that protects good-faith research.
• A mutual disclosure window that aligns with industry norms (typically 90 days, with extensions for complex remediations).

NexCyber's own VDP article and security.txt are illustrative — you can adapt them for your products.

SBOM is not optional

Auditors will ask for the SBOM. Two questions in particular:

1. Per release, where is the canonical SBOM stored?
2. Per known vulnerability in that SBOM, what is the disposition? (fixed, mitigated, not exploitable, accepted residual risk).

The second question is where SBOM meets VEX (Vulnerability Exploitability eXchange). VEX is the structured way of saying "this CVE applies to component X version Y, and here is the disposition" — a small file alongside the SBOM that turns a long list of CVEs into a manageable set.

NexCyber accepts SBOMs at upload and tracks dispositions in the evidence workspace. See Preparing an SBOM for the formats.

Severe incident reporting — the clock

CRA introduces reporting of severe incidents to authorities. The timelines are tight and start when you become aware. A clean playbook covers:

• Who decides an incident is severe (criteria, owner).
• What must be reported, in what format.
• Where the report goes (which authority).
• When (early warning, intermediate report, final report).
• How the decision is logged for audit.

NexCyber does not file reports for you; it provides the playbook scaffold, the evidence locker for the playbook, and the timeline tracker once an incident is open.

What happens at end of support

CRA has expectations around end of support: clear communication to users, last security update window, archival of the SBOM and vulnerability disposition history. NexCyber maintains the end-of-support metadata in your product estate so the picture stays consistent during transition periods.

The relationship with NIS2

If you are also in scope of NIS2, vulnerability handling appears in NIS2 Article 21 measures (notably risk management, supply chain, incident handling). NexCyber maps the same evidence to both regulations — upload an evidence item once, see it covering both obligations.

What CRA vulnerability handling does NOT do

• It does not require you to publish every vulnerability publicly.
• It does not require you to disclose to authorities every vulnerability — only severe / actively exploited ones.
• It does not replace your responsible-disclosure relationship with researchers.

Common pitfalls

• Policy without ownership. A document signed by nobody is worth almost nothing.
• SBOM at design-time. The SBOM must reflect the artefact that ships; build-time is the answer.
• Triage without SLA. Auditors look for cadence.
• Reporting playbook without contact details. Update yearly, at least.
• No safe-harbor. Researchers stop reporting if the policy is hostile.

Related articles

• CRA basics — wider picture.
• Preparing an SBOM (CycloneDX or SPDX).
• Responsible vulnerability disclosure — NexCyber's own policy.
• What evidence should I prepare? — across regulations.

Next step

Open the CRA assessment in your workspace, expand the Vulnerability handling section, and attach the four-layer evidence above. Re-run to see the score evolve.