"We'll deal with the CRA in 2027." That is the sentence we hear most often from manufacturers. It rests on a misreading of the timeline: some of the Cyber Resilience Act's obligations have already applied since September 11, 2026. As for the rest, fourteen months is very little when you need to rework a development cycle, put vulnerability management tooling in place and build up technical documentation.
Rather than a legal reading of the regulation, this article draws on our recent connected device audits. They show in concrete terms where the gaps lie, and where to start.
The CRA in brief
The Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity requirements for all products with digital elements placed on the European market: connected devices, software, network equipment, components. It follows the logic of CE marking. A product can only be sold in the Union if it meets essential requirements, demonstrated through a conformity assessment and technical documentation.
The timeline has two deadlines:
- September 11, 2026: reporting obligations for actively exploited vulnerabilities and severe incidents (already in force);
- December 11, 2027: all obligations apply, including the essential requirements and CE marking.
Penalties can reach €15 million or 2.5% of worldwide annual turnover.
Case study 1: the connected livestock building, when cybersecurity becomes a matter of life and death
A manufacturer of control systems for livestock buildings asked us to carry out a penetration test of its control unit, as well as of the data flows to its remote platform.
The real risk was not the data
During scoping, the team was initially thinking about confidentiality: the farm's production data, the farmer's login credentials. As we built the threat scenarios, another priority emerged. The unit controls the building's ventilation and temperature. An attacker able to change the setpoints could, within a few hours, endanger the animals' lives.
The feared scenario was therefore not a data leak but an attack on the integrity of the control system. That is exactly what the CRA asks for: a risk analysis specific to the product and its use, not a list of generic controls.
Three points of attention from the outset
The technical architecture immediately raised three questions, each linked to a requirement in Annex I of the regulation:
- data stored without protection on the device, accessible to anyone with physical access;
- local and remote updates, which must be checked for authentication and integrity;
- a configuration mode intended for installation, which must not become a permanent entry point.
The embedded software was custom-built. That is a good starting point, but it guarantees nothing on its own: without good build practices (minimal system, default accounts removed, unnecessary services stripped out), a device easily ships with more than it needs.
Case study 2: cold chain sensors, when the buyer takes the lead
A large retail group asked us to audit the connected sensors that monitor the temperature of its refrigerated warehouses. The audit took four days, entirely in the lab, without access to the deployment site.
When the customer audits instead of the manufacturer
This project illustrates a deeper trend. Today, it is often the buyer who pays for the security assessment of the products it deploys. Tomorrow, with the CRA, the burden of proof falls on the manufacturer. Large public and private purchasers will require technical documentation, the declaration of conformity and security support commitments in their tenders.
For a sensor manufacturer, this is a shift in commercial posture: CRA compliance will become a selection criterion, just like measurement accuracy or battery life.
Testing without the field
A lab audit requires careful preparation: samples representative of the deployed fleet, with the same software versions and a configuration matching production. Without that, you end up auditing a product that is not the one running in the field.
It is also an argument for the software bill of materials (SBOM) required by the CRA: knowing exactly which version runs on which device is the prerequisite for assessing, then fixing, a fleet of thousands of devices.
Case study 3: embedded equipment and the encryption question
A final case, outside the scope of the CRA but very instructive. For an automotive supplier, we audited an embedded maintenance device with a local interface used, among other things, to export data. Vehicles fall under their own regulatory framework (UN Regulation No. 155), but the technical questions are identical to those raised by products within the CRA's scope.
During scoping, the client asked us a question we hear often: "Should we encrypt?"
The answer depends on the risk. Here, the priority scenario was an attack on code integrity through that local interface. But encryption protects confidentiality, not integrity. An encrypted system without secure boot or update signature verification can still run modified code.
What about connected health?
For our healthcare clients, one clarification is needed. Medical devices covered by the MDR and IVDR regulations are excluded from the scope of the CRA, because their cybersecurity is already governed by those texts.
But this exclusion is narrower than many think. A home gateway that uploads readings, a wellness app not classified as a medical device, a portal for caregivers or network equipment installed in a hospital may all fall under the CRA. The right reflex is to classify each product individually, rather than assume an entire product line is excluded because it serves the healthcare sector.
What the regulation requires in practice
Our engagements overlap extensively with the CRA's requirements:
| CRA requirement | What we check during an audit |
|---|---|
| No known exploitable vulnerability at market placement | Outdated components, vulnerable libraries, unnecessary services |
| Secure by default configuration | Default passwords, active debug interfaces, open configuration modes |
| Protection against unauthorized access | Authentication of local and remote interfaces, secrets management |
| Data confidentiality and integrity | Storage and traffic encryption, update signing, secure boot |
| Security updates | Authenticated OTA mechanism, rollback capability, time to fix |
| Logging | Security event records usable in the event of an incident |
On top of these product requirements come process obligations:
- an SBOM for each version;
- a coordinated vulnerability disclosure policy;
- a support period of at least five years, unless the expected use time is shorter;
- reporting of actively exploited vulnerabilities, with an early warning within 24 hours and a notification within 72 hours via the ENISA platform.
Which conformity assessment?
| Category | Examples | Assessment |
|---|---|---|
| Default products | Most connected devices and software | Self-assessment by the manufacturer |
| Important – Class I | Routers, VPNs, identity managers, smart home security devices | Self-assessment if a harmonized standard is fully applied, otherwise third party |
| Important – Class II | Firewalls, intrusion detection systems, hypervisors | Notified body |
| Critical | Smart cards, hardware security boxes | European certification where required |
Self-assessment is not a formality. It engages the manufacturer's liability, and the manufacturer must be able to produce its technical documentation at the authorities' request.
Where to start?
- Map your portfolio: which products fall within the scope of the CRA, and in which category.
- Set up reporting now: owners, procedure, platform access and a simulation exercise. This obligation already applies.
- Generate SBOMs automatically in your build chain.
- Build the product risk analysis from real-world use, such as the ventilation of a livestock building or the code integrity of embedded equipment.
- Carry out a gap analysis against the Annex I requirements, backed by a technical audit.
- Secure the update chain: signing, secure boot and rollback.
- Compile the technical documentation, to be kept for ten years.
In summary
Our audits show it: the most frequent gaps do not come from a lack of security knowledge, but from architecture choices made too early and never revisited. Data stored without protection, an unsigned update or an overloaded system are far easier to fix at the design stage than at the time of CE marking.
December 2027 starts now.
← All articles