CRA

The Cyber Resilience Act (CRA) explained — what, who, and when

The Cyber Resilience Act (CRA) explained — what, who, and when TL;DR — The CRA is the EU's horizontal cybersecurity law for products with digital elements. If you manufacture, import, or distribute hardware or software placed on the EU market, it likely applies to you. It requires secure-by-design development, vulnerability handling, and a Software Bill of Materials (SBOM). Vulnerability-reporting duties begin 11 September 2026; full manufacturer obligations apply from 11 December 2027. What is the CRA? The Cyber Resilience Act is a regulation that sets mandatory cybersecurity requirements for products with digital elements sold in the European Union. "Products with digital elements" is deliberately broad — it covers software and hardware whose intended use includes a direct or indirect data connection. Unlike sector-specific rules, the CRA is horizontal: it applies across industries, from consumer IoT to enterprise software to industrial components. Who does the CRA apply to? The CRA assigns obligations along the supply chain: - Manufacturers carry the heaviest duties: secure design, risk assessment, vulnerability handling, technical documentation, conformity assessment, and CE marking. - Importers must verify that manufacturers have met their obligations before placing products on the EU market. - Distributors must act with due care and not make non-compliant products available. If you develop software or connected hardware and sell it into the EU — directly or embedded in someone else's product — you are almost certainly in scope as a manufacturer. What does the CRA require? At a high level, manufacturers must: 1. Design and build securely — apply security-by-design and security-by-default principles across the product lifecycle. 2. Assess cybersecurity risk — document a risk assessment that informs design and support decisions. 3. Handle vulnerabilities — operate a coordinated vulnerability disclosure (CVD) process and provide security updates for a defined support period. 4. Produce a Software Bill of Materials (SBOM) — maintain a machine-readable inventory of components, in a standard format. 5. Report actively exploited vulnerabilities — notify ENISA and relevant authorities within tight deadlines. 6. Provide documentation and a conformity declaration — assemble a technical file and, for higher-risk classes, involve a notified body. The SBOM requirement The CRA makes the Software Bill of Materials a baseline expectation. An SBOM is a structured inventory of the software components — including open-source dependencies — inside your product. It enables you and your customers to know what is in the software, track vulnerabilities in dependencies, and respond quickly when a component is found to be affected. Standard machine-readable formats (such as CycloneDX and SPDX) are the expected way to produce and exchange SBOMs. Vulnerability reporting: the 24-hour clock One of the CRA's most operationally demanding obligations is early reporting of actively exploited vulnerabilities. When you become aware that a vulnerability in your product is being exploited, a short-fuse notification workflow begins — an early warning to ENISA within 24 hours, followed by further notifications as the situation develops. Meeting this obligation requires a documented, tested internal process well before the deadline — not something you can improvise during an incident. Key CRA dates - 11 September 2026 — Vulnerability-reporting obligations begin - 11 December 2027 — Full manufacturer obligations apply Enforcement is backed by significant penalties for non-compliance and by market-surveillance authorities empowered to remove non-compliant products from the market. Dates are provisional and may be refined; always confirm against current official sources. How the CRA overlaps with other EU rules The CRA rarely arrives alone. A connected product may also fall under: - RED Cyber — for radio equipment cybersecurity - NIS2 — if you or your customers are essential/important entities - AI Act — if the product embeds AI Because these frameworks share evidence needs (SBOMs, risk assessments, vulnerability processes), addressing them together — rather than one at a time — saves substantial effort. → CRA vs NIS2 overlap Product risk classes at a glance The CRA scales its conformity-assessment demands by how critical a product is. Understanding roughly where your product sits helps you anticipate the effort involved. | Class | Examples (illustrative) | Conformity route (simplified) | |---|---|---| | ▸ Default | Most software and connected products | Self-assessment against requirements | | ▸ Important (Class I) | Password managers, network management, certain security functions | Standards-based route, heightened rigour | | ▸ Important (Class II) | Hypervisors, firewalls, tamper-resistant components | Stricter route, third-party involvement more likely | | ▸ Critical | Highest-criticality categories | Most stringent assessment | Illustrative only — the definitive classification depends on the product's function and the current legal text. The cost of getting it wrong The CRA is enforced by national market-surveillance authorities empowered to require corrective action, restrict or withdraw products from the market, and impose significant administrative fines. Beyond penalties, a product blocked from the EU market is a commercial event, not just a compliance one. Readiness is cheaper than remediation under pressure. How a readiness platform helps You still make the decisions and sign the declarations. What a platform like NexCyber does is make the structured work fast and reusable: it scopes which obligations apply, shows your gap, organises your SBOM and evidence, and produces artefacts you can share. The CRA's evidence — SBOMs, risk assessments, vulnerability processes — overlaps heavily with NIS2, the AI Act, and RED, so building it once and reusing it is the efficient path. Frequently asked questions Does the CRA apply to free and open-source software? There are specific, nuanced provisions for open source, particularly around non-commercial activity. Whether and how it applies depends on the context in which the software is supplied. When in doubt, scope it. We're a US/APAC company — does the CRA reach us? If you place products with digital elements on the EU market, yes — regardless of where you are established. Importers and distributors in the chain also carry duties. Is an SBOM alone enough? No. The SBOM is one required element among several — secure design, risk assessment, vulnerability handling, and documentation all matter. But the SBOM is foundational and a good place to start. When exactly do we need to be ready? Vulnerability-reporting duties begin 11 September 2026; full manufacturer obligations apply 11 December 2027. Given lead times for SBOM integration and CVD processes, "start now" is the honest answer. What to do now 1. Confirm scope — establish whether and how the CRA applies to your products. 2. Start your SBOM — if you do not generate SBOMs today, begin now to have them integrated into your release process before the deadlines. 3. Stand up a CVD process — a public contact channel, acknowledgement process, and triage timeline. 4. Document the ENISA workflow — the 24-hour early-warning path, tested internally. A free scope review is the fastest way to see which CRA obligations apply to your specific product. → Related: How EU compliance works · What is an SBOM and why it matters NexCyber provides a readiness analysis, not legal advice. The CRA's application to your specific product may require legal review; conformity assessment for higher-risk classes involves accredited notified bodies. Last reviewed 2026-07-10.

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.