ACL Digital

October 19, 2026

5 Minutes read

EU Cyber Resilience Act (CRA): IoT Cybersecurity Compliance

Connected devices went to market with a simple security model for years : ship first, patch later, and hope nobody notices the default password. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) ends that model. It has made huge changes, making cybersecurity a legal condition of selling in the European market, and one of its deadlines has already passed. The key highlights of the blog are outlined below which includes what the CRA requires, who it applies to, how conformity works, and how engineering teams can prepare.

What is CRA?

The Cyber Resilience Act has been active since December 10, 2024. From firmware to cloud-connected software, all ‘products with digital elements’ (PDE) must now adhere to enforced cybersecurity standards. That covers IoT sensors, gateways, cellular modules, routers, smart home appliances, industrial control systems, and embedded and general-purpose software.

The CRA is product-centric. Frameworks like ISO/IEC 27001 or NIS2 focus on how an organization manages risk. Whereas the CRA asks whether each product you place on the market was designed, documented and supported securely. Passing conformity assessment lets you affix the CE mark, which now signals cybersecurity compliance as well as physical safety.

CRA vs. Other Cybersecurity Regulations

A common question engineering leadership asks is: “Current compliance stack already cover us for the CRA?” The short answer is partially, but not completely.

The reason comes down to scope. Most established frameworks—like ISO 27001, SOC 2, or NIS2—are designed to audit your organization. They evaluate corporate governance, internal access controls, and operational risk management.

The Cyber Resilience Act flips the lens. It regulates the products you build and ship.

While strong organizational policies build a good foundation, the CRA mandates that security controls live inside the asset itself—embedded into the hardware architecture, software supply chain, and continuous patch lifecycle. Passing a corporate security audit is a great start, but it won’t automatically earn your hardware or software a CE mark.

Framework	What it regulates	Nature	Where it overlaps with the CRA
CRA	Each product with digital elements, across its lifecycle	Mandatory, tied to CE marking	n/a
RED (Art. 3.3)	Wireless devices at market entry: network, privacy and fraud protection	Mandatory since 1 Aug 2025	Day-one security controls, which the CRA builds on
NIS2	Organizations running essential and important services (energy, transport, health, digital infrastructure)	Mandatory	Incident reporting and risk management, but at the organization level
DORA	An organization’s information security management system	Voluntary certification	Useful process foundations, but no product-level obligations
GDPR	Personal data processing	Mandatory	Data-protection safeguards that support the CRA’s security requirements

Key Differentiators of the Cyber Resilience Act

It covers the whole lifecycle. Design, development, distribution and post-market support are all in scope. Also includes explicit vulnerability handling.
It ties security to market access. Conformity assessment and the CE mark mean a non-compliant product can’t be sold in the EU.
It requires SBOMs. Transparency about components is an obligation, not a best practice.
It puts the duty on the manufacturer. NIS2 and DORA mostly bind the operators who use products, whereas the CRA binds the companies that build them.

Essential Documentation & Processes for CRA Self-Assessment

For products that are eligible for the CRA’s internal conformity assessment procedure, manufacturers may conduct a self-assessment in accordance with the applicable CRA requirements.

Although these products may not require an external assessment, self-assessment remains a formal compliance activity. Manufacturers must able to demonstrate that the required cybersecurity measures have been implemented and supported by appropriate technical documentation and internal processes.

Five Core Internal Processes for EU CRA Compliance

To keep your CRA strategy manageable, your team needs a structured framework that embeds compliance directly into product engineering.

Focusing on these five core lifecycle processes will cover the heaviest CRA requirements:

Cybersecurity Risk Assessment

Map the product’s entire lifecycle to identify threats, entry points, and potential vulnerabilities before attackers can exploit them. Document every risk alongside the specific technical controls which used to mitigate it.

Secure-by-Design Development

Embed mandatory security controls from the start of product design. Long before locking in hardware or writing production code, set up the basics like smart default settings, end-to-end encryption, strict user access, and as few open targets as possible.

Vulnerability and Security Update Management

Set up a clear, repeatable process to spot, evaluate, and fix software and hardware flaws before launching—keeping your products safe and fully compliant over time. Establish a secure intake channel for security researchers to report vulnerabilities, paired with an authenticated, over-the-air (OTA) patching mechanism to deliver signed security updates safely to devices.

Support Period Determination

Clearly define how long you will maintain and patch each product based on its expected usage and underlying technology. Publishing a clear support timeline sets honest expectations for your customers and creates a formal, legally binding commitment to patch vulnerabilities.

Market Monitoring and Incident Reporting

Track post-launch security threats continuously to check pop up after product launches. Organization needs clear, step-by-step procedures to find, evaluate, escalate, and report severe security incidents and active exploits within strict CRA deadlines.

System architecture: engineering security end to end

Meeting the CRA is largely an architecture problem. Security principles have to be mapped across four places: the hardware, the firmware, the running system and the update infrastructure. The layers depend on each other, so a weakness low in the stack undermines everything above it.

Layer 1: Silicon and device identity

Every device gets its own unchangeable ID stored directly inside the chip. Its cryptographic keys and anti-rollback counters are stored in one-time-programmable (OTP) eFuses or a dedicated secure element. This kind of storage is hard to alter or extract. This prevents attackers from cloning the device or rolling it back to an older, vulnerable firmware version.

Layer 2: Boot and firmware integrity

The system implements a hardware-anchored Secure Boot sequence to satisfy CRA requirements. Immutable ROM acts as the Root of Trust, cryptographically validating the bootloader and subsequent firmware prior to execution. The system detects and halts unauthenticated software modifications at boot, establishing a defensible mitigation against physical and remote firmware tampering.

Layer 3: A hardened runtime

Once the device is running, the aim is to leave attackers as little as possible to work with:

Remove unused services, interfaces and admin endpoints
Disable physical debug ports such as JTAG on production units
Sandbox processes and enforce least-privilege access
Encrypt flash and other non-volatile memory, so stored data stays protected even if someone has the hardware in hand

These steps align directly with the CRA’s expectations for secure defaults and a minimal attack surface.

Layer 4: Updates and dependency tracking in the field

Long-term security doesn’t end at launch. Using cryptographically signed OTA updates ensures that every patch pushed to field devices is authentic. Combining signed updates with real-time, automated SBOM generation gives you full visibility across your software stack. It allows pinpoint affected releases the moment a component vulnerability is flagged.

Post-Market Security and Vulnerability Reporting

CRA compliance requires manufacturers to maintain cybersecurity throughout a product’s expected lifespan by actively monitoring threats, patching vulnerabilities, and delivering security updates. If a real-world vulnerability is actively exploited, manufacturers must report it promptly via the ENISA Single Reporting Platform (SRP).

Following are the key reporting timelines:

24-Hour Early Warning: Manufacturers must provide an initial notification after becoming aware of an actively exploited vulnerability, including relevant information about the affected product and the nature of the vulnerability.
72-Hour Notification: A more detailed notification follows, providing additional information about the vulnerability, its impact, and any available mitigation measures or workarounds.
14-Day Final Report: Once a corrective or mitigating measure becomes available, manufacturers must provide a final report containing the relevant technical and remediation information.

These timelines make incident response an important part of CRA compliance. Therefore, organizations should establish clear escalation procedures, assign responsibilities in advance, and maintain the technical capabilities required to identify qualifying cybersecurity events.

Accelerate Your IoT CRA Readiness with ACL Digital

Achieving CRA readiness requires integrating cybersecurity directly into silicon selection, embedded software design, and long-term device lifecycle management.

ACL Digital helps IoT hardware manufacturers navigate CRA compliance end-to-end:

Embedded & Hardware Security Engineering: Implementing Secure Boot, HSM integration, ARM TrustZone, and encrypted storage.
Firmware Architecture & OTA Pipelines: Designing resilient, signed over-the-air update mechanisms and SBOM supply chain tracking.
Testing, Validation & Technical Documentation: Conducting hardware penetration testing, vulnerability assessments, and preparing technical files required for CE marking.

Contact ACL Digital today to evaluate your connected product architecture and build a streamlined path to CRA compliance and European market access.

FAQs

What is the EU Cyber Resilience Act (CRA)?

The Cyber Resilience Act (Regulation (EU) 2024/2847) is an EU act mandatory cybersecurity standards for hardware and software in the European market. It requires all “Products with Digital Elements” (PDE) to be secure by design, regularly updated, and supported throughout their entire lifecycle.

How does EU CRA impact IoT manufacturers?

The CRA shifts responsibility to manufacturers, making cybersecurity required for EU market. IoT manufacturers must integrate secure hardware and firmware controls, maintain automated Software Bills of Materials (SBOMs), deliver cryptographically signed over-the-air (OTA) patches, and provide technical documentation to earn the CE mark.

Why are CRA regulations so important?

The CRA regulates the security embedded in products. It sets clear manufacturer accountability, implements rapid vulnerability reporting via the ENISA Single Reporting Platform, and protects critical infrastructure and consumers from cyber threats.

How does the CRA change the connected device market?

The CRA ends the traditional “ship first, patch later” IoT business model. It mandates security from the initial design phase through post-market maintenance. Devices without built-in security controls, verifiable supply chain transparency, or defined long-term support lifespans can no longer be sold in the European Union.