EU Cyber Resilience Act: What Device Manufacturers Need to Build
The EU Cyber Resilience Act (CRA) (Regulation EU 2024/2847) is now in force. Most product requirements apply from 11 December 2027, with earlier partial application on 11 June 2026 (governance and enforcement provisions) and 11 September 2026 (notified bodies). The 11 December 2027 deadline is the critical path for manufacturers building or upgrading connected products.
The CRA introduces mandatory cybersecurity requirements for any product with digital elements sold in the European Union, which includes nearly every connected IoT device. Non-compliance blocks market access and carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.
Most content about the CRA is written by law firms. This page focuses on what manufacturers actually need to build and operate to satisfy the technical requirements, and what Connhex covers.
Of all the CRA requirements, OTA update infrastructure and per-device credential management are the most complex to design and deploy, especially for products already in the field. The product deadline is 11 December 2027.
Official sources: CRA full text (EUR-Lex) · CRA summary (EUR-Lex)
What the CRA requires, technically
The CRA is organized around manufacturers' obligations throughout the product lifecycle. The requirements with the most direct impact on what manufacturers need to build are:
1. OTA update capability (Art. 13.8)
Manufacturers must ensure that vulnerabilities can be addressed through security updates, including remote updates, for the expected lifetime of the product or a minimum of five years.
This means every connected product sold in the EU from 11 December 2027 must have a working over-the-air update mechanism: signed, authenticated, and capable of deploying patches to devices in the field.
2. Unique device identities (Art. 13.3 and Annex I)
Products must implement secure-by-design principles, including unique per-device authentication credentials. Shared secrets, hardcoded passwords, and generic default credentials do not satisfy this requirement.
Each device must receive a unique identity (e.g. an X.509 certificate or equivalent) during manufacturing, and that identity must be used for all communication with backend systems.
3. No known exploitable vulnerabilities at time of sale (Art. 13.1)
Products must be placed on the market without any known exploitable vulnerabilities. This requires a documented security testing process and a mechanism to track and respond to newly discovered vulnerabilities after sale.
4. Vulnerability disclosure and handling (Art. 13.6, 13.7)
Manufacturers must have a process to:
- Receive vulnerability reports (a public point of contact)
- Triage and address reported vulnerabilities within defined timeframes
- Notify the appropriate EU authority (ENISA) of actively exploited vulnerabilities within 24 hours, and provide a detailed notification within 72 hours
This is primarily an organizational and process requirement, not a platform one.
5. Software Bill of Materials (SBOM) (Art. 13.9)
Manufacturers must maintain an SBOM (a machine-readable inventory of all software components in the product) to facilitate vulnerability tracking across the supply chain.
SBOM generation is a build-pipeline and toolchain requirement. Tools like Syft, CycloneDX, or SPDX-integrated build systems produce this output; it is not something an IoT connectivity platform provides.
6. Data protection and minimization (Art. 13.4)
Products must process only the data necessary for their intended purpose and protect it against unauthorized access. For EU-based manufacturers or products targeting EU customers, this intersects with GDPR obligations.
What you need to have in place
Mapping the CRA requirements to implementation tasks:
| CRA Requirement | What you need to build |
|---|---|
| OTA updates (Art. 13.8) | Signed firmware distribution, staged rollouts, rollback on failure, update client on device |
| Unique device identities (Art. 13.3) | Per-device certificate issuance during manufacturing, X.509 chain of trust |
| Vulnerability patching pipeline | Secure SDLC, patch build and sign process, OTA delivery mechanism |
| Vulnerability disclosure process | Public contact point, internal triage workflow, ENISA reporting procedure |
| SBOM | Automated generation in build pipeline (toolchain responsibility), storage and version tracking |
| Data minimization | API and data model review, retention policies, access controls |
How Connhex addresses each requirement
The sections below are explicit about what Connhex covers directly, what it supports, and what falls outside the platform.
OTA updates: covered directly
Connhex Edge provides the on-device update client. Connhex Control manages firmware campaigns from the cloud: firmware images are signed on upload, and the device agent verifies the signature before applying any update. Staged rollouts and automatic rollback on failure are built in. See OTA Firmware Updates.
Unique device identities: covered directly
Connhex Provisioning and Connhex Manufacturing automate per-device X.509 certificate issuance during production. Connhex Remote Init handles devices already in the field that need to be migrated to per-device credentials. See Secure Device Provisioning.
Monitoring and anomaly detection: supported
Connhex Monitoring provides the telemetry infrastructure to detect anomalous device behavior that may indicate an active exploit. This supports your incident detection process but does not replace a formal security monitoring program.
Data protection and GDPR: supported
Connhex provides a GDPR compliance documentation map covering data flows, residency, retention policies, and access controls, directly useful for both CRA and GDPR compliance assessments.
Vulnerability disclosure: outside Connhex scope
Establishing a public vulnerability reporting contact, defining internal triage procedures, and setting up ENISA notification workflows are organizational requirements. Connhex maintains its own vulnerability reporting process for the platform itself; your product needs a separate process for your own firmware and hardware. If you want to scope this for your deployment, reach out.
SBOM: outside Connhex scope
SBOM generation is a build-pipeline concern handled by toolchain integrations, not by an IoT connectivity platform. Connhex Manufacturing tracks firmware versions at production time (useful for tracing which SBOM version shipped with which device) but does not generate SBOMs.
CRA compliance across verticals
CRA applies to all connected products, regardless of industry. The requirements for OTA updates and unique device identities are particularly relevant for:
Connhex for HVAC · Connhex for the Smart Home · Connhex for Industrial Washing Machines
What to do now
CRA compliance spans multiple workstreams. OTA update infrastructure and per-device credential management are among the most demanding to implement and deploy, particularly for products already in the field. Starting with these allows the rest of the compliance work to build on a solid foundation before the 11 December 2027 product deadline.
If you want to understand which Connhex capabilities map to your specific product and compliance timeline, reach out: we work with manufacturers across the EU on exactly this.