The EU Cyber Resilience Act (CRA) applies to SMEs that make products connecting to the internet: smart thermostats, mobile apps, industrial sensors, and software. The regulation applies directly across all Member States.
The CRA is the first horizontal EU regulation on product cybersecurity: it covers products with digital elements as a whole, where earlier texts targeted specific sectors.
This guide describes the Cyber Resilience Act (Regulation (EU) 2024/2847) for small businesses, including manufacturers, importers, distributors and software teams: scope, obligations, timeline and compliance sequence.
What is the Cyber Resilience Act?
The CRA is an EU regulation, not a directive. It applies directly in every Member State without national transposition. It sets horizontal cybersecurity requirements for products with digital elements placed on the EU market.
Key dates are:
- Adopted: 23 October 2024
- Entered into force: 10 December 2024
- Reporting obligations (Article 14): 11 September 2026
- Full application: 11 December 2027
The CRA's core principle is "secure by design and by default." It shifts responsibility for product cybersecurity from the user to the manufacturer. From 11 December 2027, a manufacturer placing a product on the EU market answers for its cybersecurity throughout the support period, under penalty of the sanctions described below.
Does the CRA apply to your SME?
Three questions decide it. If the answer to all three is yes, you're in scope.
Question 1: Do you make or sell a "product with digital elements"?
The CRA defines this broadly. It means any software or hardware product that can connect to another device or network, directly or indirectly.
In scope:
- Smart home devices (thermostats, cameras, locks)
- Network equipment (routers, firewalls, switches)
- Mobile apps and software
- Industrial control systems and IoT sensors
- Laptops, smartphones, wearables
- Embedded software and firmware
- Remote data-processing solutions
Out of scope (already regulated elsewhere): medical devices (MDR/IVDR), automotive components (UNECE), marine equipment, and certain aviation systems.
The CRA applies based on where the product is placed on the market, not where it's made. A US SaaS company selling to EU customers is in scope. A Chinese manufacturer selling through Amazon EU is in scope.
Question 2: Are you an "economic operator"?
The CRA imposes obligations on four roles:
| Role | Definition | Primary obligations |
|---|---|---|
| Manufacturer | Designs, develops, or places a product on the market under its name | Risk assessment, conformity, CE marking, vulnerability handling, reporting |
| Importer | Brings non-EU products into the EU market | Verify CE marking, retain documentation, cooperate with authorities |
| Distributor | Makes products available on the EU market (not manufacturer or importer) | Check CE marking, avoid non-compliant products, cooperate with surveillance |
| Open-source steward | Supports open-source software within a commercial ecosystem | Specific vulnerability-handling and documentation duties |
For SMEs, the manufacturer role is the main responsibility. If you design, brand, or sell a digital product, you're the manufacturer, even as a 10-person team.
Question 3: Is your product commercial?
Open-source software developed without commercial activity is generally exempt. But if you monetize the software (subscriptions, support, hosting), integrate it into a commercial product, or provide it as a service (SaaS), the CRA likely applies.
The three product classes
Not all products are treated equally. The CRA escalates requirements across three tiers:
| Class | Examples | Conformity assessment |
|---|---|---|
| Standard products | General software, non-critical hardware | Self-assessment |
| Important - Class I | Browsers, password managers, VPNs, operating systems, network management tools | Self-assessment |
| Important - Class II | Hypervisors, firewalls, industrial monitoring, smart-meter components, smart-card readers | Third-party assessment |
| Critical products | Smart cards, secure elements, industrial safety systems | EU cybersecurity certificate or third-party assessment |
Most small software vendors and IoT makers fall into "Standard" or "Important Class I", which means you can self-assess. Only firewalls, industrial control systems, and security hardware need third-party certification. The CRA Fast Check tool can pin down your class in about a minute.
The third party is not a freely chosen supplier: the regulation refers to a notified body, meaning a conformity assessment body designated by a national notifying authority under Articles 39, 47, 49 and 51. In France, that notifying authority is ANSSI. A candidate body must first obtain COFRAC accreditation for the intended scope, then file a notification request with ANSSI. On 21 July 2026 the agency published the process for module B (EU type-examination), with the module H process (full quality assurance) to follow. For a manufacturer of important Class II or critical products, the consequence is a scheduling one: the pool of notified bodies is being built through 2026 and 2027, and it will determine how readily an assessment slot can be secured before 11 December 2027.
Core manufacturer obligations
Article 13 lists the manufacturer's duties. Below are the ones that matter most for SMEs, in plain language.
1. Security by design & by default (Annex I, Part I)
Before you ship, a product must come with secure default configurations (no default passwords, least privilege), protect against unauthorised access by design, ensure confidentiality and integrity of data, protect the availability of essential functions, and minimise impact on other systems.
In practice: don't ship with "admin/admin" credentials, don't make users disable security to get your product working, and don't let your IoT device become a botnet waiting to happen.
2. Vulnerability handling (Annex I, Part II)
You need a documented process to identify and document vulnerabilities, ship security updates promptly, keep updates available for the support period (minimum 5 years), run a coordinated vulnerability disclosure (CVD) policy, and share remediation with upstream maintainers where relevant.
In practice: you need a security@ address, a reasonable response time to vulnerability reports, fast patches for critical bugs, and the discipline to keep doing this for at least 5 years after you stop selling the product.
3. Cybersecurity risk assessment
Before placing a product on the market, you must run and document a risk assessment that drives your security design. Keep it for at least 10 years.
In practice: write down what could go wrong, what you did to prevent it, and why that's enough. A 5-page document is fine for a simple product.
4. Technical documentation
Maintain documentation covering the product description and intended use, the risk assessment, how you met the essential requirements, your vulnerability-handling procedures, and test evidence.
In practice: keep a digital folder with your risk assessment, architecture diagrams, security test results, and update logs. Market surveillance authorities can request it any time for 10 years.
5. EU Declaration of Conformity & CE marking
Once you've self-assessed (or been certified), draw up an EU Declaration of Conformity, affix the CE marking, and include manufacturer identification and the support-period end date.
In practice: the CE mark now also means "this product meets cybersecurity requirements." You can't affix it without doing the work.
6. Support period & update availability
The minimum support period is 5 years (or the product's expected lifetime if shorter). Security updates must stay available for at least 10 years after release, and the end-of-support date must be communicated to buyers at purchase.
The reporting timeline: 24h / 72h / 14 days
Article 14 introduces strict reporting for actively exploited vulnerabilities and severe incidents. It applies from 11 September 2026, earlier than the main obligations.
| Stage | Deadline | What to report |
|---|---|---|
| Early warning | Within 24 hours | Actively exploited vulnerability or severe incident detected |
| Notification | Within 72 hours | Detailed assessment, impact, indicators of compromise |
| Final report | 14 days (vulnerabilities) / 1 month (incidents) | Root cause, corrective measures, cross-border impact |
Reports go to the CSIRT of your main-establishment Member State and to ENISA via the CRA Single Reporting Platform.
A 15-person team needs a 24/7 escalation path for security incidents. That doesn't mean a SOC (security operations center). It means a documented process for who gets called when a critical vulnerability drops on a Friday evening.
Importers, distributors & the supply chain
If you're not the manufacturer but you bring products into the EU or distribute them, you have your own duties.
Importers must verify the CE marking, confirm that technical documentation and the Declaration of Conformity exist, ensure user instructions are in an understandable language, retain documentation for 10 years, and cooperate with authorities.
Distributors must check for the CE marking and required documentation, refuse to place non-compliant products on the market, cooperate with investigations, and take corrective action when a product presents a cybersecurity risk.
In practice: if you import smart-home devices and resell them on Amazon EU, you are responsible for verifying CRA compliance. You can't blame the manufacturer if they fall short.
Open source: the steward exception
The final text of the CRA addresses the concerns raised by the open-source community during the negotiation with the "open-source software steward" concept:
| Scenario | CRA applicability |
|---|---|
| Non-commercial open-source project (no monetization) | Exempt |
| Open-source component inside a commercial product | The commercial product's manufacturer is responsible |
| Commercial entity supporting an open-source ecosystem (steward) | Steward has specific vulnerability-handling and documentation duties |
| SaaS built on an open-source stack | The SaaS provider is the manufacturer and must comply |
If you build a commercial product on open-source components (most do), you're responsible for the security of the whole product, including open-source bits. Exercise due diligence when integrating third-party components and report vulnerabilities upstream.
Keep a Software Bill of Materials (SBOM) for every release. Tools like Syft, CycloneDX, or SPDX can automate it.
Compliance roadmap: 24 months for SMEs
With full application on 11 December 2027, SMEs have 24 months to prepare. A phased approach:
Phase 1: Scoping & assessment (months 1 to 3)
- Confirm your product class with the CRA Fast Check
- Map your portfolio: which products are in scope, which are exempt
- Identify your role: manufacturer, importer, distributor, or steward
- Run a gap analysis against the Annex I essential requirements
- Create initial SBOMs for each product
Phase 2: Foundation building (months 4 to 9)
- Establish a secure development lifecycle: threat modelling, code review, security testing
- Implement a vulnerability-handling process: CVD policy, intake channel, triage SLA
- Draft a technical-documentation template
- Set support periods (minimum 5 years per product)
- Build incident-response capability: 24/7 escalation, reporting templates
- Write user security documentation
Phase 3: Conformity & documentation (months 10 to 18)
- Complete risk assessments for all in-scope products
- Run internal conformity assessment (self-assessment for Standard / Class I)
- Prepare the EU Declaration of Conformity for each product
- Affix the CE marking (can be digital for software)
- Publish user instructions with the support-period end date
- Stand up an update-delivery mechanism (OTA updates, patch repository)
Phase 4: Reporting readiness (months 19 to 22)
- Register with the CRA Single Reporting Platform (via ENISA)
- Test the reporting workflow with a tabletop exercise
- Train the team on the 24h/72h/14-day deadlines
- Build a relationship with your national CSIRT
- Document your 10-year evidence-retention process
Phase 5: Go-live & continuous improvement (months 23 to 24+)
- Confirm every product placed on the market after 11 Dec 2027 is compliant
- Monitor the Official Journal for harmonised standards citations (M/606 deliverables expected between August 2026 and October 2027) and delegated acts
- Run an annual review of risk assessments and documentation
- Apply for SECURE EU funding if eligible (up to €30,000 for MSMEs)
Fines & enforcement
The CRA's penalties are tiered:
| Violation | Maximum fine |
|---|---|
| Non-compliance with essential requirements or Articles 13 & 14 | €15 million OR 2.5% of global annual turnover |
| Other infringements | €10 million OR 1.5% of global annual turnover |
Authorities can also withdraw or recall products, prohibit sales, issue corrective orders, and publicly name non-compliant companies.
The ceilings are expressed as a fixed amount or a percentage of worldwide annual turnover, whichever is higher. The actual amount is set by the market surveillance authorities according to the nature, gravity and duration of the infringement.
Harmonised standards: where the timeline stands
The essential requirements of Annex I are written as objectives, not technical specifications. Harmonised standards will do the translation: a product that conforms to a harmonised standard cited in the Official Journal of the EU will benefit from the presumption of conformity under Article 27 of the regulation.
Standardisation request M/606, accepted by CEN, CENELEC and ETSI in 2025, covers 41 standards: around fifteen horizontal standards applying to all products in scope, and the rest vertical standards for specific categories of important or critical products. The schedule set by the request places the two core horizontal standards (secure development and vulnerability handling) at 30 August 2026, the vertical standards at 30 October 2026, and the remaining horizontal standards in October 2027.
As of mid-2026, no CRA harmonised standard is cited in the Official Journal. The presumption of conformity is therefore not available for any product category, and citation will follow delivery of the standards on a schedule the Commission has not yet published. That is no reason to wait: self-assessment is done today directly against the Annex I requirements, and the draft standards released for consultation indicate what the technical expectations will look like. The Commission also maintains a technical FAQ on CRA implementation, updated in July 2026, answering recurring questions on scope and obligations.
CRA vs NIS2: how they interact
Many SMEs will face both. Here's how they differ and overlap:
| Aspect | CRA | NIS2 |
|---|---|---|
| Type | Regulation (directly applicable) | Directive (national transposition) |
| Focus | Product security | Organizational security |
| Target | Makers, importers, distributors of digital products | Essential and Important Entities |
| Key obligation | Secure-by-design, CE marking, vulnerability reporting | Risk management, incident reporting, supply-chain security |
| Timeline | Full application Dec 2027 | Already transposed in most Member States |
| Fines | Up to €15M or 2.5% turnover | Up to €10M or 2% turnover |
If you're a software manufacturer that's also an "Important Entity" under NIS2, you're doing double duty. But the CRA's technical documentation, risk assessment, and vulnerability handling align closely with NIS2's Article 21 measures. One well-structured security program serves both. See our NIS2 guide for SMEs for the organizational side.
The organizational baseline for the CRA in Komplyo
The CRA's product-security duties (risk assessment, vulnerability handling, secure-by-default configuration, technical documentation) rest on an organizational security baseline. Komplyo uses NIST CSF 2.0 as the assessment framework and projects the same answers onto NIS2, GDPR, ISO 27001 and SOC 2 through the mappings between frameworks; the controls covering vulnerability management and risk assessment are part of that base. Identified gaps feed a prioritized roadmap and the generated documents. The Cyber Resilience Act page details the product scope, the essential requirements and the deliverables, and the free diagnostic (23 questions, around 5 minutes) gives a first picture of the organizational baseline.
Frequently asked questions
Does the Cyber Resilience Act apply to software, or only hardware?
Both. The CRA covers any "product with digital elements" that can connect to a device or network, including standalone software, mobile apps, firmware, and SaaS with remote data-processing components.
When does the CRA apply?
Reporting obligations under Article 14 apply from 11 September 2026, and the full set of obligations applies from 11 December 2027. Products placed on the market after that date must be compliant.
Do small businesses have to pay for third-party certification?
Usually not. Most SME software and IoT products fall into "Standard" or "Important Class I," which allow self-assessment. Only Class II and Critical products (firewalls, industrial control systems, security hardware) require third-party assessment or an EU cybersecurity certificate.
What are the CRA reporting deadlines?
For actively exploited vulnerabilities and severe incidents: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days (vulnerabilities) or 1 month (incidents), sent to your national CSIRT and ENISA.
Should I wait for the harmonised standards before starting compliance work?
No. As of mid-2026 no CRA harmonised standard is cited in the Official Journal; standardisation request M/606 schedules the first deliveries between August and October 2026. In the meantime, self-assessment is done directly against the essential requirements of Annex I, and the Article 14 reporting obligations apply from 11 September 2026 regardless of when the standards are published.
How long must I support a product under the CRA?
A minimum of 5 years (or the product's expected lifetime if shorter). Security updates must remain available for at least 10 years after release, and the end-of-support date must be disclosed to buyers at purchase.
Free resources & tools
| Resource | Source | What it provides |
|---|---|---|
| CRA full text (EU Official Journal) | EU Official Journal | The legal text of Regulation (EU) 2024/2847 |
| CRA Fast Check self-assessment | Independent CRA resource | 3-question wizard for scope and product class |
| European Commission CRA summary | European Commission | Official summary of the legislation |
| CRA implementation FAQ | European Commission | Technical FAQ on implementation, updated July 2026 |
| CRA standardisation (request M/606) | European Commission | Status of the standardisation request and the 41 harmonised standards |
| ENISA CRA materials | ENISA | Guidance, standards mapping, implementation support |
| Notification process for notified bodies | ANSSI | French designation rules for notified bodies, module B published on 21 July 2026 |
| SECURE EU project | EU-funded project | Free training and cascade funding (up to €30,000) for MSMEs |
| CycloneDX SBOM standard | OWASP | Free SBOM format and tooling |
| SPDX SBOM standard | Linux Foundation | Alternative SBOM standard, widely used in open source |
Summary
The CRA sets cybersecurity requirements for the design, sale and support of products with digital elements on the EU market. The compliance work starts with three determinations: whether the products are in scope (connectivity, EU market, commercial activity), which class they fall into (Standard, Important I/II or Critical, which decides the conformity assessment route), and who coordinates the work between engineering, legal and operations. Non-compliance exposes the manufacturer to the fines described above and to the withdrawal of the affected products from the EU market; a documented security lifecycle also answers the requirements that procurement teams include in their vendor evaluations.
Frameworks like NIST CSF 2.0, ISO 27001 and NIS2 provide the structure; the regulation sets the timeline, with the Article 14 reporting obligations applying from 11 September 2026 and the full set of obligations from 11 December 2027.