The EU Cyber Resilience Act entered into force on 10 December 2024. Its reporting obligations apply as of 11 September 2026, and the main obligations introduced by the Act apply from 11 December 2027. On 27 July 2026 the European Commission published practical guidance to help manufacturers, developers, and businesses of all sizes meet their obligations under it.
Read as a compliance calendar, that sequence looks generous. Read as an engineering calendar it is not, and the reason sits in one sentence of the Commission's own description of the Act.
The obligations start before the product exists
The CRA introduces mandatory cybersecurity requirements for manufacturers covering the planning, design, development, and maintenance of products with digital elements, and states those obligations must be met at every stage of the value chain.
Planning and design are the first two words on that list, and they are the two that cannot be revisited. A terminal's secure boot chain, its key storage, whether firmware can be updated in the field and whether that update can be verified, whether debug interfaces are permanently closed on production units — these are settled when the mainboard and its BOM are chosen. By the time a product is in a customer's hands, the options remaining are documentation and patching. Everything structural has been decided.
That is what makes 11 December 2027 a misleading date to plan against. Industrial and commercial terminals are designed on multi-year cycles and stay in the catalogue for years afterwards. A unit expected to be selling into the EU in 2028 is being specified now.
Vulnerability handling for the life of the product
The Act also requires manufacturers to handle vulnerabilities during the lifecycle of their products. That is a short clause with a long tail.
Consider what a deployed fleet of terminals actually looks like. A panel PC commissioned in 2024 on an operating system release that was current then. A POS unit whose payment module carries firmware from a third party. An Android all-in-one in a store that will not accept a maintenance window during trading hours. A box PC on a network segment the customer manages, behind a gateway we never see.
Handling a vulnerability across that estate is not primarily a coding problem. It requires knowing which units shipped with which components — a software bill of materials maintained per build, not reconstructed after the fact — plus a way to deliver an update to equipment with no reliable inbound connectivity, and a customer-side process willing to install it. Any one of those missing makes the obligation unmeetable in practice, whatever the engineering intent.
CE marking, and who gets to certify
Products will bear the CE marking to indicate compliance with CRA requirements, and national market surveillance authorities will enforce the rules. For hardware manufacturers CE marking is familiar territory, but the CRA adds a dimension to it that previous directives did not: the mark now asserts something about software behaviour over time, not only about the physical unit at the point of sale.
The Commission also notes that some products of particular relevance for cybersecurity may need to undergo third-party assessment by a notified body before being sold on the EU market. That introduces a queue outside the manufacturer's control, and it typically requires evidence assembled during development rather than reconstructed afterwards. A product family sharing a hardware platform and firmware base across variants has a real advantage here, because assessment effort spent once can be referenced by every member of it.
What the Act is trying to fix
The Commission is explicit about the problem being addressed: inadequate cybersecurity in many products, and the lack of timely security updates. It also identifies a buyer-side difficulty — customers currently struggle to determine which products are cybersecure and to set them up securely — and frames the CRA as making it easier to identify hardware and software with the proper cybersecurity features.
That second point deserves attention from anyone selling into procurement processes. If the CE marking becomes the shorthand a buyer uses to filter suppliers, then compliance stops being a cost of market access and starts functioning as a qualification. The Commission's stated aim is that consumers and businesses buying software or hardware products with digital elements can tell the difference.
The CRA builds on the 2020 EU Cybersecurity Strategy and the EU Security Union Strategy, and complements other legislation in the area, specifically the NIS2 Directive. That last point is worth noting because it splits the obligations across parties: NIS2 addresses the operators of essential and important services, while the CRA addresses the products they buy. A customer subject to NIS2 will pass requirements down the supply chain whether or not the CRA obliges them to.
The unglamorous part
Yinestar builds industrial panel PCs, box PCs, Android all-in-ones, and POS touch systems, and the CRA reaches all four — none of them are sold with the expectation of staying offline.
The awkward truth about this regulation is that the work it demands is invisible in a product datasheet. Nobody specifies a terminal because its supplier maintains an accurate software bill of materials. But with reporting obligations already applying and the main obligations arriving on 11 December 2027, the manufacturers in the best position will be those who treated lifecycle security as an engineering discipline before it became a legal one.