CRA Insights

Cyber Resilience Act

Cyber Resilience Act for SMEs: What Manufacturers Need to Do Now

Cyber Resilience Act for SMEs: What Manufacturers Need to Do Now

Last updated: 2026-10-09

The Cyber Resilience Act (Regulation (EU) 2024/2847) has no size exemption. Anyone placing a product with digital elements on the EU market - whether hardware with a software component, an embedded device or pure software - is in principle subject to the same requirements as a large corporation. The difference lies in timeline, prioritisation and available budget. This article provides a prioritised roadmap that starts exactly there.

Does the CRA apply to my business at all?

Whether the CRA applies depends on the type of product; company size plays no role. In scope are manufacturers, importers and distributors of products with digital elements that have a direct or indirect logical or physical data connection to a device or network - and that are made available on the EU market. This also applies to free software made available in the context of a commercial activity and to products marketed under your own name but developed by third parties.

Exemptions apply to products already equivalently regulated by sector-specific EU legislation, such as medical devices (MDR/IVDR), motor vehicles (type-approval), aviation products certified under Regulation (EU) 2018/1139 or marine equipment. For SME software and hardware manufacturers outside these sectors, these exemptions do not apply. Use our interactive applicability check for a systematic self-assessment; a detailed explanation of roles and boundaries is available in the article Cyber Resilience Act - am I affected?

Roadmap for SMEs under the Cyber Resilience Act in two phases; there is no size exemption for manufacturers, the order follows the deadlines. Phase 1, now, processes before documents, because the reporting obligation has applied since 11 Sep 2026: 1 clarify applicability and role, 2 classify the product, 3 build the reporting process with point of contact, escalation path, report templates and access to the reporting platform, 4 track vulnerabilities in third-party components. Phase 2, by 11 Dec 2027, close the product gaps, full requirements from 11 Dec 2027: 1 risk assessment and security by design, 2 SBOM in a commonly used machine-readable format, 3 technical documentation, 4 conformity assessment, self-assessment or notified body depending on the class, 5 user information under Annex II. Reporting deadlines under Article 14: 24 hours early warning, 72 hours notification, final report after 14 days or one month. Relief for micro and small enterprises: a simplified format for the technical documentation (Art. 33(5)), the Commission sets the form by implementing act; an exemption from fines for a missed 24-hour early warning (Art. 64(10)), whose scope is open to interpretation. The reporting obligation itself applies regardless of size. Source: Articles 14, 33(5) and 71(2) of Regulation (EU) 2024/2847; final report no later than 14 days after a corrective or mitigating measure is available for vulnerabilities, one month after the notification for incidents.
SME roadmap: the reporting process first, then the product requirements by December 2027.

The two hard deadlines - and why the first one is urgent

For SMEs, two dates structure the entire implementation plan:

  • 11 September 2026: The CRA's reporting and notification obligations (Art. 14) have applied since this date. Since then, manufacturers have been required to report actively exploited vulnerabilities and severe incidents without undue delay and in any event within 24 hours of becoming aware as an early warning, and without undue delay and at the latest within 72 hours as a notification. A final report follows no later than 14 days after a corrective or mitigating measure becomes available (vulnerabilities), or within one month of the 72-hour notification (severe incidents). Reporting is submitted via the ENISA Single Reporting Platform (SRP) to the competent CSIRT.
  • 11 December 2027: All remaining product requirements become fully applicable: security by design, vulnerability handling over the entire support period, SBOM, technical documentation, CE marking and EU declaration of conformity.

For operational decisions the first deadline is the more pressing one: it has applied since 11 September 2026. In practice this needs working reporting channels; a completed product certification is not a prerequisite. Details in the article CRA Reporting Obligations since 11 September 2026.

Minimum Viable CRA Compliance: priorities for limited budgets

When resources are constrained, sequence matters. Not all CRA obligations take effect simultaneously, and not all carry the same penalty risk. The following roadmap is ordered by deadline urgency and implementation effort.

Phase 1 (immediately, mandatory since September 2026): build reporting processes

This is the most urgent measure. A Product Security Incident Response Team (PSIRT) does not need to be a dedicated department - but it requires a named responsible person, a documented escalation path and the technical capability to issue a qualified early warning without undue delay and at the latest within 24 hours. In practice this means:

  • Define the internal notification chain: who decides whether a vulnerability is “actively exploited” or an incident “severe”?
  • Prepare access to the ENISA Single Reporting Platform (SRP) - check registration and the reporting format
  • Create templates for the 24-hour early warning, 72-hour notification and final report
  • Secure a monitoring baseline: is there a vulnerability database feed (NVD, OSV) to detect known vulnerabilities in your product components early and check them for active exploitation?

Note: reports are submitted via the Single Reporting Platform that ENISA sets up and operates under Art. 16 CRA. Manufacturers should monitor the ENISA website for the access procedure and the exact reporting format. Details on the reporting obligation.

Phase 2 (in parallel, until December 2027): build your SBOM

A Software Bill of Materials (SBOM) is an indispensable foundation for further CRA obligations: without knowing which third-party components are in a product, neither rapid vulnerability reporting nor coordinated vulnerability handling is possible.

For SMEs a staged approach is recommended:

  • Immediate action: create an SBOM for your highest-revenue or highest-risk product - in CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1 format (BSI TR-03183-2)
  • Tooling: open-source tools such as Syft or cdxgen generate SBOMs in the build; Dependency-Track continuously matches them against vulnerability databases
  • Note the retention obligation: the technical documentation including the SBOM must be kept for at least 10 years after the product is placed on the market, or for the product's support period - whichever period is longer

A detailed technical overview of formats, tools and the retention obligation is available in the article SBOM Requirements under the CRA. With our SBOM check you can automatically scan an SBOM (CycloneDX/SPDX) or a lockfile for known vulnerabilities.

Phase 3 (until December 2027): determine product class and plan conformity assessment

The CRA distinguishes four tiers with different conformity assessment requirements:

Product category Conformity assessment Typical examples
Default Self-assessment (Module A) Mobile apps and video games without the core functionality of a product category listed in Annex III or IV
Important, Class I (Annex III) Self-assessment (Module A) with full application of harmonised standards, common specifications or a European cybersecurity certification scheme (at least “substantial”); otherwise notified body (Module B+C or H) Password managers, VPN, browsers, PKI software, SIEM
Important, Class II (Annex III) Always third-party assessment: Module B+C or H with a notified body or, where available, a European cybersecurity certificate at least at assurance level “substantial” Firewalls, hypervisors, tamper-resistant microprocessors
Critical (Annex IV) Mandated European cybersecurity certificate (Art. 8(1)), otherwise as Class II (Art. 32(4)) Smart cards, secure elements, smart-meter gateways

For Class I products there is an important relief option: where harmonised standards, common specifications or a European cybersecurity certification scheme (assurance level at least “substantial”) are fully applied, self-assessment under Module A is sufficient - without an external testing body. Otherwise Module B+C or H with a notified body is required. These standards are being developed by CEN, CENELEC and ETSI under standardisation request M/606. SMEs with Class I products should follow their progress, because it determines whether self-assessment under Module A is possible.

The precise classification of specific products requires interpretation and depends on Implementing Regulation (EU) 2025/2392. All class references in this article are schematic - the classification of your specific product should be assessed with professional support. More details in the article CRA Product Classes: Default, Class I/II and Critical.

What drives the effort

The effort for initial implementation depends mainly on product complexity, the starting state of your security processes and the product class. Clarifying the product class early shows in good time whether third-party assessment will be needed.

Reliefs for micro and small enterprises - and what they do not cover

The CRA defines micro and small enterprises by reference to Recommendation 2003/361/EC (microenterprises: fewer than 10 employees and annual turnover or balance-sheet total not exceeding €2 million; small enterprises: fewer than 50 employees and not exceeding €10 million). Micro and small enterprises benefit from targeted relief, for example the option to submit the technical documentation in a simplified format, with the form to be set by the Commission (Article 33(5)), and an exception from fines for a missed 24-hour early warning (Article 64(10)), whose scope is a question of interpretation. The reporting obligation itself applies regardless of company size. This does not exempt these enterprises from the CRA; the technical product requirements apply to them as well. For manufacturers in this size category the pragmatic approach is especially important: prioritise reporting processes and SBOM, use self-assessment wherever permitted, apply harmonised standards as soon as they are available.

A possible timeline at a glance

  • Immediately (Q4 2026): assess applicability, make a preliminary product class estimate, assign PSIRT responsibility, document the notification chain, prepare SRP registration
  • Q4 2026 to Q2 2027: build SBOMs for core products, introduce Dependency-Track or comparable tooling, begin technical documentation
  • Q3 to Q4 2027: complete conformity assessment (self-assessment or notified body), affix CE marking, issue EU declaration of conformity

A complete overview of all CRA obligations is available on the CRA pillar page. If you are unsure whether and how your product is affected, start with the applicability check or schedule a no-obligation initial consultation directly.

Frequently asked questions

Does the Cyber Resilience Act apply to small businesses too?+
Yes. The CRA has no general size exemption. Manufacturers, importers and distributors of products with digital elements are in principle subject to the same obligations - regardless of whether they have 5 or 5,000 employees. Micro and small enterprises benefit from targeted relief, for example the option to submit the technical documentation in a simplified format, with the form to be set by the Commission (Article 33(5)), and an exception from fines for a missed 24-hour early warning (Article 64(10)), whose scope is a question of interpretation. The reporting obligation itself applies regardless of company size. The technical product requirements apply to them as well.
What is the most important CRA obligation SMEs should address first?+
The most urgent measure is building reporting processes for vulnerabilities and security incidents, because this obligation has applied since 11 September 2026, while the remaining product requirements apply from 11 December 2027. Manufacturers already need a named responsible person, a documented notification chain and the capability to issue a qualified early warning via the ENISA Single Reporting Platform without undue delay and at the latest within 24 hours.
Do I need to involve a notified body for my product?+
That depends on the product class. For default-category products, self-assessment is sufficient. For important products in Class I (Annex III CRA), self-assessment under Module A is permitted provided harmonised standards, common specifications or a European cybersecurity certification scheme (assurance level at least “substantial”) are fully applied - otherwise a notified body is required (Module B+C or H). Class II always requires third-party assessment: Module B+C or H with a notified body or, where available, a European cybersecurity certificate at least at assurance level “substantial” (Art. 32(3)). For critical products, a European cybersecurity certificate mandated by delegated act applies (Art. 8(1)), otherwise the Class II procedures (Art. 32(4)). The classification of a specific product requires interpretation and should be assessed with professional support.
What is an SBOM and why is it so important for CRA compliance?+
An SBOM (Software Bill of Materials) is a structured inventory of all software components in a product - comparable to an ingredients list. The CRA requires it as part of technical documentation. In practice it is even more important: without an SBOM, it is impossible to quickly determine which of your products are affected when a vulnerability in a third-party component becomes known - which in turn jeopardises compliance with the 24-hour and 72-hour reporting deadlines.
What does the effort of CRA implementation depend on?+
The effort for initial implementation depends mainly on product complexity, the starting state of your security processes and the product class. Clarifying the product class early shows in good time whether third-party assessment will be needed.

Sources

This content provides general technical and organizational information on the Cyber Resilience Act (Regulation (EU) 2024/2847) and does not constitute legal advice (no legal services within the meaning of the German RDG).