The Cyber Resilience Act makes product support part of the sale

The EU's Cyber Resilience Act tied market access to the security of connected products over time. For hardware and software companies, support duration became a product and funding decision.

Illustration of an opened industrial edge controller with a circuit board and network interfaces inside a metal enclosure.
Industrial edge controller. Illustration.

Selling a connected device can produce revenue immediately and maintenance work for years. The Cyber Resilience Act made that mismatch harder to overlook. When the European law entered into force on 10 December 2024, it established a framework in which manufacturers would have to address security during a product’s design and its support period. A product that worked on shipment day was only the beginning of the commitment.

The Commission’s announcement set 11 December 2027 as the date when the main obligations would apply. Entry into force therefore did not make every new requirement immediately enforceable. It did give founders designing equipment, enterprise software and security products a concrete reason to reconsider support promises, component choices and the cost of maintaining products already sold. These decisions could outlast a funding round or a single generation of hardware.

The scope follows the product and its connections

Article 2 covers products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network. The definition includes software, hardware and qualifying remote data processing solutions. It also reaches components placed on the market separately. A manufacturer could not assess its position simply by calling itself a software company or describing a feature as connected.

The boundaries still mattered. The law contains exclusions for products covered by specified sectoral regimes and distinguishes commercial supply from other activity. A startup needed to map the actual product, its network dependencies and the role of each party selling it. A cloud function necessary for a device to perform one of its functions could raise different questions from an unrelated hosted service. Broad claims that every digital service faced identical duties would obscure that analysis.

A support promise needs an engineering budget

Article 13 requires the support period to reflect how long a product is expected to be used, taking account of reasonable user expectations and the nature and purpose of the product. The period must be at least five years, unless expected use is shorter. Equipment expected to operate for longer requires an assessment grounded in its expected use, regardless of the sales forecast.

That requirement changes the economics of an inexpensive connected product. Its contribution has to help fund vulnerability investigation, dependency updates, testing and a secure distribution mechanism after the original transaction. A subscription may provide continuing revenue, but it does not remove the engineering work. A founder also needs to consider whether an upstream component supplier’s support lasts long enough for the finished product’s expected use.

A Raspberry Pi 4 Model B circuit board showing its Broadcom processor, memory, connectors and USB and Ethernet ports.
Raspberry Pi 4 Model B with a Broadcom BCM2711 Arm processor, July 2019.Laserlicht (opens in a new tab) · CC BY-SA 4.0 (opens in a new tab)

The law separately requires security updates issued during the support period to remain available for at least ten years after issue, or for the remainder of the support period if longer. Maintaining access to an existing update is different from developing new fixes indefinitely. Keeping those duties distinct prevents both underestimating the commitment and overstating it.

The component list is the beginning of the response

The adopted text requires manufacturers to exercise due diligence when integrating third-party components, including noncommercial open source components. Annex I also calls for a machine-readable software bill of materials covering at least top-level dependencies. The practical benefit is an ability to identify where a component sits inside a shipped product. A list that is disconnected from product versions or build records cannot reliably answer that question.

Consider a manufacturer learning of a vulnerability in a library shared by several device models. It needs to determine which versions contain the library, whether the weakness matters in their operating environment and which users need a fix. It then has to test and distribute the remedy. This sequence explains why software supply chain tools need links to engineering and release systems, beyond producing a document for procurement.

The transition allowed time to prepare for product maintenance

The transition gave companies three years to prepare for the main requirements. Reporting obligations for actively exploited vulnerabilities and severe security incidents began on 11 September 2026, ahead of the main product requirements in December 2027. Teams need a vulnerability contact, clear responsibility for investigation and records that explain security decisions as the product evolves.

Hackathon participants lean over crowded tables of laptops in a blue-lit hall.
Participants at the Junction hackathon, 2015.Vmuru (opens in a new tab) · CC BY-SA 4.0 (opens in a new tab)
From adopted text to the main application date
  1. 23 October 2024

    Adopted legislative text

    The Parliament and Council text sets product security, vulnerability handling and support duties.

  2. 10 December 2024

    Entry into force

    The law establishes the transition period; the main duties do not all apply immediately.

  3. 11 December 2027

    Main obligations scheduled to apply

    The main product security and vulnerability handling obligations become applicable.

Reporting duties and provisions for conformity assessment bodies followed earlier schedules than the main product obligations.

Sources12

Conformity assessment and CE marking were part of the framework, but an assessment could not replace the continuing ability to respond. A startup entering Europe needed to budget for both the evidence supporting market access and the operation behind that evidence. Work done early on build traceability and update delivery could be reused across product generations; reconstructing those records after shipment could be much harder.

Support quality can matter before the deadline

Investors needed to assess whether a company's product margin and staffing plan could sustain its commitments to existing customers. Fast shipment growth could increase future support work even if the development team stayed small. A clearer view of supported versions, upstream dependencies and expected product life could therefore improve the assessment of operating costs.

There was room for businesses that reduced this work through reliable inventories, secure updates and coordinated vulnerability handling. The law did not guarantee demand for a separate tool at every step. A useful product would need to fit the manufacturer’s existing engineering systems and make a concrete task easier. A manufacturer needed to maintain what it had already sold while continuing to build the next product.

Investment implications

  • The support period must reflect expected use; five years is a floor with an exception for products expected to be used for less time.
  • A component inventory becomes commercially useful when the manufacturer can connect a vulnerability to affected products and deliver a remedy.
  • The transition period gave product teams time to budget for maintenance, documentation and secure update delivery.

Sources

  1. Cyber Resilience Act enters into force to make Europe’s cyberspace safer and more secure (opens in a new tab)

    European Commission

  2. Regulation of the European Parliament and of the Council on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) (opens in a new tab)

    European Parliament and Council of the European Union

  3. Cyber Resilience Act (opens in a new tab)

    European Commission

CIR Ventures Journal

Published

Browse the journal