Until now, device security has been a matter of manufacturer discretion. From December 2027, a product with digital elements that fails to meet the requirements of the Cyber Resilience Act cannot be placed on the European Union market. The principle mirrors CE marking: no conformity means no market access.
Below I set out what a manufacturer has to do, and in what order.
What the CRA covers, and what it does not
The scope is broader than most companies assume. The regulation covers products with digital elements (PDE), meaning any hardware or software product capable of being connected, directly or indirectly, to a device or a network.
That includes a sensor, a controller, a router and a camera, but equally a commercially sold software library and a desktop application. The criterion is straightforward: placing the product on the EU market in the course of a commercial activity.
Products covered by sectoral regulation fall outside the scope, including medical devices, civil aviation and type approved vehicles, as does open source software developed non-commercially. That last boundary is easy to misjudge. Charging for support around your own open source project can be enough to bring it into scope.
A frequent error at this stage is assuming that an integrator of third party modules is not a manufacturer. Selling a product under your own brand makes you the manufacturer under the regulation, together with responsibility for components you did not write.
Four product categories
The category determines whether self assessment suffices or whether a notified body has to be involved. That decision feeds directly into budget and schedule, which is why it is worth establishing at the very beginning.
| Category | Examples | Conformity assessment |
|---|---|---|
| Default | most consumer products, sensors, simple electronics | manufacturer self assessment |
| Important, class I | password managers, VPNs, home routers, IdM systems | self assessment under a harmonised standard, or a notified body |
| Important, class II | firewalls, IDS/IPS systems, hypervisors, tamper-resistant microprocessors and microcontrollers | third party involvement required |
| Critical | hardware devices with security boxes, smart meter gateways, smartcards and secure elements | European certification |
Most IoT devices land in the default category. This simplifies the formal path but does not lower the technical requirements. Self assessment simply means nobody will verify the product before launch.
Implementation timeline
The regulation entered into force on 10 December 2024, with obligations applying in stages.
- 11 June 2026. Provisions on notified bodies. The certification infrastructure starts operating.
- 11 September 2026. The duty to report actively exploited vulnerabilities and severe incidents.
- 11 December 2027. Full application of the regulation.
September 2026 is the date most often missing from plans. The reporting duty starts more than a year before the rest of the requirements and presumes organisational readiness that cannot be assembled in a week: an intake channel, out of hours availability, a decision procedure and somebody with the mandate to classify events.
Requirements from Annex I
Annex I splits into two parts, and the distinction has practical consequences.
Part I: product properties
The product must be designed, developed and produced so as to ensure an appropriate level of cybersecurity based on risk. In practice this means, among other things:
- shipping without known exploitable vulnerabilities;
- a secure default configuration, with the ability to reset to factory state;
- protection from unauthorised access, with authentication and identity management;
- protection of data confidentiality and integrity, at rest and in transit;
- minimising the attack surface and limiting incident impact through appropriate isolation;
- recording and monitoring security relevant events;
- collecting only data necessary for the product to function.
The first point deserves particular attention. Requiring a product to ship without known exploitable vulnerabilities means, in practice, running a security test before launch. Without one, the declaration has no evidentiary basis.
Part II: vulnerability handling
The second part concerns not the product but the process around it, and applies throughout the support period:
- identifying and documenting vulnerabilities and components, including an SBOM covering at least top level dependencies;
- addressing vulnerabilities without delay, including through security updates;
- regular security testing and reviews;
- publicly disclosing information about fixed vulnerabilities once a patch is released;
- operating a coordinated vulnerability disclosure policy;
- distributing security updates free of charge and without delay, separately from functionality updates where that is feasible.
The last requirement often surprises product teams. Security updates have to be separated from functionality updates wherever that is technically feasible, and the free of charge rule yields only for tailor-made products, by separate agreement with a business user.
Support period
The manufacturer determines the support period based on the expected product lifetime, and as a rule it may not be shorter than five years. Products with a genuinely shorter life cycle are the exception. The support period must be clearly communicated to the buyer before purchase.
For industrial equipment with life cycles measured in decades, this is a commitment that needs pricing at design time. The cost of maintaining support rises sharply once a silicon vendor ends kernel support while the product is still being sold.
Reporting duty
For an actively exploited vulnerability, the manufacturer notifies both the CSIRT designated as coordinator and ENISA:
- an early warning within 24 hours of becoming aware;
- a vulnerability notification within 72 hours, including information on corrective measures;
- a final report within 14 days of a corrective measure becoming available.
For a severe incident affecting product security the pattern is similar: 24 hours for the early warning, 72 hours for the notification and one month for the final report.
The clock runs from becoming aware, not from confirming the event. The procedure therefore has to state unambiguously who classifies a vulnerability and on what basis. Details are covered in reporting within 24 hours.
SBOM
Two misconceptions about SBOMs come up in nearly every workshop.
The first concerns publicity. An SBOM does not have to be public. The regulation requires it to be produced, maintained and made available to market surveillance authorities on request, not published on the product page.
The second concerns the life cycle. An SBOM is not a one off document. It has to reflect the current state of the product, in a commonly used machine readable format, in practice CycloneDX or SPDX, and be updated alongside the product. An SBOM generated once before launch and left untouched creates a false sense of control over dependencies.
Penalties
Infringements of the essential requirements in Annex I and of manufacturer obligations carry penalties of up to EUR 15,000,000 or 2.5% of worldwide annual turnover, whichever is higher. Other obligations carry up to EUR 10 million or 2%, and supplying misleading information to a notified body or market surveillance authority up to EUR 5 million or 1%.
For a smaller manufacturer, however, the more material risk is not the maximum fine but an order to withdraw the product from the market, which can end a product line faster than any penalty.
Implementation order
The sequence that works for hardware manufacturers:
- Establish scope and category. A list of products covered by the regulation with categories assigned. The five question test helps.
- An SBOM for one product. Not the whole portfolio, one product. It reveals how much you actually know about your dependencies.
- Launch an intake channel. A
security@address, a public disclosure policy, a declared response time. The cheapest item on this list and the first one an auditor checks. - Test the product. A penetration test produces a list of vulnerabilities with proof of exploitation, which is the evidence behind any claim about the absence of known vulnerabilities.
- Assemble technical documentation. Risk assessment, test results, a description of the vulnerability handling process.
Point four is where I most often support manufacturers. A full device analysis covers hardware, firmware, communication and the update process, and ends with a report written so that it goes straight into the technical documentation.
If you want to establish where your product stands, get in touch. The first conversation is free and usually enough to determine the category and the scope of work.
This text describes Regulation (EU) 2024/2847 and is informational. It does not replace legal analysis for a specific product.