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:
- Design and build securely — apply security-by-design and security-by-default principles across the product lifecycle.
- Assess cybersecurity risk — document a risk assessment that informs design and support decisions.
- Handle vulnerabilities — operate a coordinated vulnerability disclosure (CVD) process and provide security updates for a defined support period.
- Produce a Software Bill of Materials (SBOM) — maintain a machine-readable inventory of components, in a standard format.
- Report actively exploited vulnerabilities — notify ENISA and relevant authorities within tight deadlines.
- 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
- Confirm scope — establish whether and how the CRA applies to your products.
- Start your SBOM — if you do not generate SBOMs today, begin now to have them integrated into your release process before the deadlines.
- Stand up a CVD process — a public contact channel, acknowledgement process, and triage timeline.
- 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.