The CRA in practice.
Security after delivery.

The CRA, Regulation (EU) 2024/2847, sets cybersecurity requirements for products with digital elements within its scope. It is an established regulation, not a legislative proposal. The precise obligations depend, among other things, on the product, its function, the market introduction, and your role in the chain.

Not every digital product is subject to the same rules; there are exceptions and other product regimes. Therefore, assess a router, embedded controller, software package, or connected application individually. The European Commission provides the general overview.

September 11, 2026

Reporting obligations for manufacturers apply to actively exploited vulnerabilities and serious incidents affecting product security. Not every software problem found automatically falls under the same reporting procedure.

December 11, 2027

The primary product obligations become applicable. Looking only at this date is insufficient: the reporting obligations start earlier.

In the event of an incident, use the current official explanation on CRA reporting. The role of a manufacturer here is different from the role of an organization under NIS2.

For products within the scope, it involves a coherent process: assessing risks, designing appropriate security, handling vulnerabilities, and building documentation. Conformity assessment and CE marking are not exclusively relevant to a small group of high-risk products; the route and potential involvement of a third party differ by category.

For an industrial application, a practical product file starts, for example, with the intended function, interfaces, dependencies, and support terms. Record which security functions are in the product and which measures are expected from the integrator or user. See the explanation for manufacturers.

The CRA requires a substantiated support period. This is, in principle, at least five years, unless the expected lifetime is shorter. A longer expected lifetime may require a longer period. Five years is therefore not a general maximum, nor is it a commitment for every Remote product. The concrete product terms must be established.

Additionally, ask how to report vulnerabilities, how updates are announced, and how to recognize the current version. For the machine manager, testing possibilities, maintenance windows, and recovery after a failed update are important practical agreements. Consult the regulation for the full provisions.

• Which product and which software version are being delivered, and who is acting as the manufacturer?
• Which functions, interfaces, and external software components are included in the delivery?
• What documentation substantiates the security claims and any conformity?
• What support, updates, and contact route for vulnerabilities have been agreed upon?
• Who tests a change before it is used in a production environment?

These project questions are not a substitute for the legal conformity assessment.

Remote combines routers/controllers, a web portal, IIoT platform, and app. For custom apps, protocol couplings, and embedded software, we also put management and maintenance on the table. Discuss early who is responsible for which product components, documentation, and updates.

IEC 62443 can help to handle security requirements in a structured way. A reference to that standard or an ISO certificate is not, in itself, a CRA declaration of conformity.