The Cyber Resilience Act for SMEs: What Product Makers Actually Need to Do

If you make a product that connects to the internet — a smart thermostat, a mobile app, an industrial sensor, even a piece of software — the EU Cyber Resilience Act (CRA) probably applies to you. If you're a small or medium business, that may sound daunting.

The good news: there's time, and a clear path.

The CRA is the most significant product-security regulation in EU history. But it's also surprisingly navigable for SMEs once you understand what it asks, when it asks for it, and how to build compliance into your product development rather than bolting it on at the end.

This guide breaks down the Cyber Resilience Act (Regulation (EU) 2024/2847) for small businesses — manufacturers, importers, distributors, and software teams who need clarity without the legal fog.

What is the Cyber Resilience Act?

The CRA is an EU regulation — not a directive, so it applies directly in every Member State without national transposition — that sets horizontal cybersecurity requirements for products with digital elements placed on the EU market.

Key dates:

• 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. Before the CRA, if your smart lock had a vulnerability, that was the buyer's problem. After December 2027, it's yours — and getting it wrong can cost up to €15 million.

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: 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.

Critical point: 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:

For SMEs, the manufacturer role is the heavy lift. 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:

What this means for SMEs: most small software vendors and IoT makers fall into "Standard" or "Important Class I" — meaning 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.

Core manufacturer obligations

Article 13 lists the manufacturer's duties. Here are the ones that matter most for SMEs, translated from legalese into plain English.

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.

SME translation: 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.

SME translation: 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.

SME translation: 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.

SME translation: 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.

SME translation: the CE mark now also means "this product meets cybersecurity requirements." You can't slap it on 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.

Reports go to the CSIRT of your main-establishment Member State and to ENISA via the CRA Single Reporting Platform.

SME reality check: a 15-person team needs a 24/7 escalation path for security incidents. That doesn't mean a SOC — 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.

SME translation: 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 CRA worried the open-source community. The final text answers it with the "open-source software steward" concept:

What this means for SMEs: if you build a commercial product on open-source components (most do), you're responsible for the security of the whole product — open-source bits included. Exercise due diligence when integrating third-party components and report vulnerabilities upstream.

Practical tip: keep a Software Bill of Materials (SBOM) for every release. Tools like Syft, CycloneDX, or SPDX can automate it.

A 24-month compliance roadmap for SMEs

With full application on 11 December 2027, SMEs have roughly 24 months from mid-2026 to prepare. A realistic phased approach:

Phase 1: Scoping & assessment (months 1–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–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–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–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–24+)

• Confirm every product placed on the market after 11 Dec 2027 is compliant
• Monitor for harmonised standards 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:

Authorities can also withdraw or recall products, prohibit sales, issue corrective orders, and publicly name non-compliant companies.

The SME angle: for a €5M-turnover SME, a 2.5% fine is €125,000; for a €50M SME, it's €1.25M. Real numbers that can kill a business — and entirely avoidable with preparation.

CRA vs NIS2: how they interact

Many SMEs will face both. Here's how they differ and overlap:

The overlap: 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. For the organizational side, see our NIS2 guide for SMEs.

How Komplyo helps you get CRA-ready

The CRA's product-security duties — risk assessment, vulnerability handling, secure-by-default configuration, and technical documentation — sit on top of an organizational security baseline. That baseline is exactly what Komplyo helps you build and prove.

• Assess once, read everywhere. You answer once against NIST CSF 2.0 and Komplyo projects your posture onto NIS2, GDPR, ISO 27001, and SOC 2 — the same controls that underpin CRA vulnerability management and risk assessment. See how the methodology works.
• Start free. The free diagnostic gives you a maturity score by CSF function in minutes — a fast way to spot the gaps that CRA conformity will expose.
• From gaps to evidence. Identified gaps flow into a prioritized roadmap and generated policies — the documentation auditors and enterprise buyers ask for. Explore the product.

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 actually start to bite?

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.

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

Final thoughts: start now, at a steady pace

The CRA fundamentally changes how digital products are designed, sold, and supported in the EU. For SMEs, it creates both risk and opportunity.

The risk is clear: non-compliance means fines, market exclusion, and reputational damage. The opportunity is quieter but just as real — SMEs that build CRA-compliant products early can use security as a competitive differentiator. When a procurement team compares two IoT vendors, one with a documented security lifecycle and one without, the choice makes itself.

Start with three questions:

1. Are our products in scope? (connectivity + EU market + commercial)
2. What's our product class? (Standard, Important I/II, or Critical)
3. Who owns compliance? (someone must coordinate engineering, legal, and operations)

Frameworks like NIST CSF 2.0, ISO 27001, and NIS2 provide the structure. The CRA provides the product-specific urgency. Your engineering knowledge provides the context. Combine them, and compliance becomes a product feature, not a burden.