Cyber Resilience Act: what it means for connected industrial sensors

The Cyber Resilience Act matters for connected industrial sensors in a way that earlier product rules did not. A vibration node with Wi-Fi, an edge hub with a web dashboard, the firmware on both and the software that talks to them are all "products with digital elements". From late 2027 they must meet common cybersecurity requirements to carry the CE marking, and parts of the law bite much earlier.

This article explains what the CRA covers, how sensors and hubs are likely to be classified, what the essential requirements mean on a real device and which dates to plan for. It is general engineering guidance, not legal advice.

What the Cyber Resilience Act is

The Cyber Resilience Act is Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements. It was signed on 23 October 2024 and entered into force on 10 December 2024.

It defines a product with digital elements as a software or hardware product and its remote data processing solutions, including components placed on the market separately. Remote data processing means processing at a distance, designed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions. A cloud back end that a sensor needs to work is therefore part of the product.

For industrial sensing this scope is broad. It covers the sensor node, the hub, their firmware, configuration tools, and any manufacturer-run service the product depends on.

The key dates

Article 71 sets the application dates:

Two transitional rules in Article 69 shape the planning. Products placed on the market before 11 December 2027 only have to meet the CRA requirements if they are substantially modified after that date. But the Article 14 reporting obligations apply to all in-scope products, including those placed on the market before 11 December 2027. In other words, since September 2026 your installed base counts.

Which category is your sensor in?

The CRA has three tiers of product, and the tier decides the conformity assessment route.

• Default products are everything not listed in the annexes. Most sensors, data loggers and many edge devices sit here. The manufacturer can use internal control, a self-assessment.
• Important products, class I and class II, are listed in Annex III. For class I, self-assessment is possible only if harmonised standards, common specifications or a certification scheme were fully applied; otherwise a notified body is needed. Class II always needs third-party assessment or a certification scheme.
• Critical products in Annex IV, such as hardware devices with security boxes, smart meter gateways and smartcards or secure elements, may require European cybersecurity certification.

Classification depends on the product's core functionality. Annex III class I includes, for example, operating systems, physical and virtual network interfaces, routers, modems and switches, microcontrollers and microprocessors with security-related functionalities, and network management systems. Class II includes firewalls, intrusion detection and prevention systems, and tamper-resistant microcontrollers. The Commission adopted Implementing Regulation (EU) 2025/2392 on 28 November 2025 to describe these categories technically.

A vibration sensor that contains a microcontroller is not a "microcontroller with security-related functionalities" as a product; its core function is measurement. An edge hub that runs Linux is not an operating system product. A device sold primarily as an industrial gateway or switch, however, may be class I. Look at what you sell, not at what is inside it.

What the essential requirements mean on a sensor

Annex I, Part I lists the product requirements. Translated for a connected sensor or hub:

• No known exploitable vulnerabilities at release. Track the vulnerabilities in your firmware, libraries and operating system before shipping.
• Secure by default. No shared default passwords, unnecessary services disabled, with a way to reset to the original state.
• Security updates. A mechanism to fix vulnerabilities, with automatic updates as the default where applicable and an opt-out.
• Access control. Authentication on configuration interfaces, dashboards and service ports, and reporting of possible unauthorised access.
• Confidentiality and integrity. Encryption of relevant data at rest and in transit, and protection of data, commands, programs and configuration against unauthorised change.
• Data minimisation. Process only the data needed for the intended purpose.
• Availability and resilience. Keep essential functions available after an incident, including against denial-of-service attacks, and do not degrade other devices on the network.
• Limited attack surface. Expose only the interfaces you need.
• Security logging. Record relevant internal activity such as access to or modification of data and functions, with an opt-out for the user.
• Secure deletion. Let users permanently remove all data and settings.

Vulnerability handling and reporting

Annex I, Part II adds process obligations. Manufacturers must identify components, including a software bill of materials (SBOM) in a common machine-readable format covering at least top-level dependencies; remediate vulnerabilities without delay; test regularly; publish information on fixed vulnerabilities; maintain a coordinated vulnerability disclosure policy and a contact address; distribute updates securely; and provide security updates free of charge, separately from feature updates where technically feasible.

The reporting duty in Article 14 was the first hard deadline, and it has applied since 11 September 2026; ENISA's Single Reporting Platform went live on the same day. According to the Commission's summary, manufacturers must notify actively exploited vulnerabilities and severe incidents through the CRA single reporting platform run by ENISA:

1. An early warning within 24 hours of becoming aware.
2. A main notification within 72 hours.
3. A final report within 14 days after a corrective measure is available for an exploited vulnerability, or within one month of the 72-hour notification for a severe incident.

Meeting a 24-hour deadline is not a documentation task. It needs someone on call, a way to know which firmware is where, and a decision path that works on a Sunday.

The support period

Article 13(8) requires the manufacturer to set a support period during which vulnerabilities are handled. It must be at least five years, unless the product is expected to be in use for less than that, in which case it matches the expected use time. Annex II requires the end date to be stated to the user. Industrial sensors often run for ten years or more, so the support period should follow the realistic service life, not the warranty.

How the CRA fits with other rules

Connected sensors seldom face the CRA alone.

Radio equipment. Delegated Regulation (EU) 2022/30 under the Radio Equipment Directive has applied cybersecurity requirements to certain internet-connected radio equipment since 1 August 2025. The Commission's guidance on the EN 18031 series explains the harmonised standards and their restrictions, for example on products that allow users not to set a password. A Wi-Fi sensor sold today already falls under these rules. EUR-Lex lists the delegated regulation as ending on 10 December 2027, the day before the CRA's main obligations apply.

Machinery. Recital 53 of the CRA notes that machinery products with digital elements must meet both the CRA's essential cybersecurity requirements and the health and safety requirements of the Machinery Regulation. We cover the machinery side, including protection against corruption, in EU Machinery Regulation 2023/1230.

Standards. The IFA and BAuA authors of KAN Brief 2/2025 point to SBOM formats such as CycloneDX, machine-readable advisories under CSAF, and around 40 proposals for new standards due to be voted on in 2025 for harmonisation under the CRA. They recommend publishing a security contact following RFC 9116 as a first step.

A preparation checklist for sensor manufacturers

• Decide which of your products are default, class I or class II, and record the reasoning.
• Build and maintain an SBOM for every firmware and software release.
• Publish a vulnerability contact and a coordinated disclosure policy.
• Run the reporting process that has applied since 11 September 2026: on-call responsibility, fleet inventory by firmware version and a tested path to the ENISA Single Reporting Platform.
• Define the support period per product and state its end date.
• Review defaults: passwords, open ports, services, debug interfaces.
• Plan secure, signed updates that can be separated from feature releases.
• Check products with radios against the RED delegated act now, not in 2027.

How NeuroControls approaches this

Our systems are designed to keep the attack surface small. The operator dashboard on the hub runs over the local network; integrations with Grafana, OpenSearch, Kafka or MES systems are configured only on request, so they are not open by default. Recorded data carries per-segment SHA-256 hashes, an append-only journal and a versioned manifest, which supports the integrity requirements. The structure behind this is described in the hub-and-node architecture and on our architecture page.

On our energy-autonomous VCD4.3, the cryptographic layer, with secure boot, TPM attestation and tamper-evident signatures on results, is an open development item that awaits hardware integration, as we described on the EdgeAI project blog in May. Its results leave the wagon only through passive RFID read-out, which keeps the remote attack surface small, but integrity of the stored results still has to be protected. The CRA timeline applies to our recording software and edge AI hubs as it does to any connected product; we do not claim CRA conformity before the requirements and harmonised standards are in place.