For years, cybersecurity in connected products was often treated as something to improve after the product reached the market. Devices were designed, firmware was developed, cloud platforms were connected, and security improvements were sometimes postponed until vulnerabilities appeared.

That approach is becoming increasingly difficult to sustain.

The EU Cyber Resilience Act (CRA) introduces mandatory cybersecurity requirements for a broad range of products with digital elements sold in the European Union.

For IoT manufacturers, this represents more than another regulatory obligation. It changes how connected devices must be designed, developed, updated, and supported throughout their lifecycle.

In this article, we explore what the EU Cyber Resilience Act means, which products it affects, and how IoT companies can prepare without unnecessarily rebuilding their existing technology.

‍

What Is the EU Cyber Resilience Act?

The EU Cyber Resilience Act is a European Union regulation establishing cybersecurity requirements for products with digital elements.

Formally known as Regulation (EU) 2024/2847, it aims to improve the cybersecurity of hardware and software products placed on the EU market.

Its central principle is straightforward:

Cybersecurity should be built into digital products from the beginning and maintained throughout their supported lifetime.

Previously, cybersecurity requirements for connected products varied across sectors and product categories.

The CRA introduces a broader regulatory framework that applies to many types of hardware and software.

Why Was the Cyber Resilience Act Introduced?

Connected devices have become part of everyday life and critical business operations.

Smart home devices, industrial gateways, medical technologies, connected vehicles, and enterprise IoT platforms increasingly exchange information across networks.

However, these connected environments introduce security risks.

Common weaknesses include:

• Default or weak passwords.
• Outdated firmware containing known vulnerabilities.
• Insecure communication between devices and cloud services.
• Poorly protected device credentials.
• Missing security update mechanisms.
• Limited visibility into third-party software components.
• Devices that remain deployed long after security support ends.

A vulnerability in one connected device can sometimes provide an entry point into a larger network.

The CRA addresses these risks by requiring manufacturers to consider cybersecurity throughout product development and maintenance.

What Does the CRA Aim to Achieve?

The regulation focuses on several outcomes.

1. Secure products by design

Manufacturers must consider cybersecurity during product design and development rather than treating it as an optional feature.

2. Better vulnerability management

Manufacturers must establish processes for identifying, documenting, and addressing vulnerabilities.

3. Security updates throughout the support period

Products must have appropriate mechanisms for distributing security updates.

4. Greater transparency

Manufacturers must provide relevant security information, including details about the support period and how users can report vulnerabilities.

5. More consistent cybersecurity expectations

The CRA establishes a common framework for many digital products entering the EU market.

The practical takeaway is that cybersecurity becomes part of product conformity, alongside other applicable regulatory requirements.

When Does the EU Cyber Resilience Act Become Mandatory?

The Cyber Resilience Act entered into force on December 10, 2024, but its obligations apply in stages.

Understanding this timeline is important for manufacturers planning product development and future releases.

Key CRA Compliance Dates

December 10, 2024: Regulation enters into force

The CRA became part of EU law.

June 11, 2026: Conformity assessment body provisions

Certain provisions relating to notified conformity assessment bodies began applying.

September 11, 2026: Vulnerability reporting obligations

Manufacturers become subject to specified reporting requirements concerning actively exploited vulnerabilities and severe incidents affecting product security.

December 11, 2027: Main CRA requirements apply

The principal cybersecurity requirements become applicable to products within scope.

These dates are particularly relevant to manufacturers with long hardware development cycles.

A connected product being designed today may still be sold or introduced into the European market after the main requirements become applicable.

Why IoT Companies Should Prepare Early

IoT products often involve several development layers:

• Hardware design.
• Embedded firmware.
• Communication protocols.
• Mobile applications.
• Cloud infrastructure.
• Device management platforms.

Security improvements across these layers may require architectural changes.

For example, adding secure firmware updates to an existing device can involve changes to the bootloader, flash memory allocation, firmware signing process, and device recovery mechanism.

Such modifications become more expensive once hardware designs are finalized or products are deployed at scale.

The earlier manufacturers assess CRA requirements, the more flexibility they have to address security gaps through normal product development.

If your connected product is approaching commercialization, Infolitz can help assess security considerations across firmware, device connectivity, mobile applications, and cloud infrastructure.

Which IoT Products Are Covered by the Cyber Resilience Act?

The CRA generally applies to products with digital elements that are made available on the EU market and whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

This includes many connected hardware products and software applications.

Examples of Potentially Covered Products

Consumer IoT

• Smart home controllers.
• Connected cameras.
• Smart lighting systems.
• Connected appliances.
• Home automation gateways.

Industrial IoT

• Industrial communication gateways.
• Connected sensors and controllers.
• Remote monitoring devices.
• Industrial edge computing equipment.
• Network-connected automation components.

Enterprise Technology

• Network routers.
• Security appliances.
• Connected access control systems.
• Enterprise software.
• Device management applications.

Software Products

• Commercial software applications.
• Device management platforms.
• Firmware distributed as part of a product.
• Certain standalone software components.

The actual applicability depends on the product, how it is made available, and whether specific exclusions or sector-specific rules apply.

Are Medical Devices Covered?

Certain regulated product categories are excluded from the CRA because they are subject to other applicable EU regulatory frameworks.

For example, medical devices covered by the EU Medical Device Regulation and in vitro diagnostic medical devices covered by the corresponding EU regulation are excluded.

Manufacturers should therefore evaluate their product classification rather than assuming that every connected product falls under identical CRA requirements.

Does the CRA Apply to Companies Outside Europe?

Yes, potentially.

A manufacturer based in India, the United States, or another non-EU country may need to comply when placing an in-scope product on the EU market.

The regulation is not limited to manufacturers headquartered in Europe.

This matters for global IoT businesses developing devices for international customers.

A product designed and manufactured outside the EU may still need to satisfy CRA requirements before being placed on the European market.

How the Cyber Resilience Act Changes IoT Architecture

One of the most important implications of the CRA is that cybersecurity cannot be addressed by protecting only one component.

Modern IoT systems consist of interconnected layers.

A typical architecture includes:

IoT Device → Communication Network → Cloud Platform → Mobile or Web Application

Each layer introduces potential vulnerabilities.

A secure cloud platform cannot compensate for a device that accepts unauthorized firmware updates.

Similarly, secure firmware does not eliminate risks caused by poorly protected cloud APIs.

Layer 1: Device and Hardware Security

Security begins at the device.

Manufacturers should evaluate:

• Secure boot mechanisms.
• Protected cryptographic keys.
• Device identity and authentication.
• Debug interface restrictions.
• Secure storage.
• Hardware security capabilities.

Secure boot, for example, helps prevent unauthorized firmware from executing by verifying software integrity during startup.

For products with long deployment lifetimes, device-level protections are particularly important.

Layer 2: Embedded Firmware Security

Firmware controls device behavior and communication.

Security weaknesses at this layer can expose the entire connected system.

Important practices include:

• Secure coding.
• Firmware integrity verification.
• Dependency management.
• Vulnerability scanning.
• Secure configuration.
• Reliable update and recovery mechanisms.

Firmware security should also account for operational conditions.

A device installed in a remote industrial facility may have intermittent connectivity.

Its update mechanism must account for interrupted downloads, power failures, and recovery scenarios.

Layer 3: Communication Security

IoT devices frequently communicate using protocols such as MQTT, HTTPS, BLE, and industrial communication standards.

Security considerations include:

• Encrypted communication where appropriate.
• Mutual authentication.
• Secure certificate management.
• Protection against replay attacks.
• Access control.
• Secure credential provisioning.

The appropriate security mechanism depends on device capabilities, communication requirements, and deployment conditions.

Layer 4: Cloud and Backend Security

Cloud platforms often manage thousands of connected devices.

A weakness in backend authorization or device management can affect an entire deployment.

Manufacturers should evaluate:

• API authentication and authorization.
• Device access permissions.
• Secure storage of credentials.
• Audit logging.
• Cloud infrastructure configuration.
• Vulnerability monitoring.
• Incident response procedures.

Layer 5: Mobile and Web Application Security

Mobile and web applications frequently provide user access to connected devices.

Their security must be considered as part of the overall product architecture.

Important controls include:

• Secure authentication.
• Role-based authorization.
• Protected API communication.
• Secure session management.
• Sensitive data protection.
• Appropriate software update practices.

The key architectural lesson is that IoT cybersecurity must be evaluated across the complete connected product, not just the device firmware.

Essential Cybersecurity Requirements Under the CRA

The CRA establishes essential cybersecurity requirements for products with digital elements.

These requirements address both product characteristics and manufacturers' vulnerability-handling processes.

Secure by Design and Default

Products must be designed, developed, and produced with cybersecurity in mind.

They must also be made available with secure default configurations.

For example, a connected gateway should not rely on a universal, publicly known administrator password.

Manufacturers should instead implement appropriate authentication and secure provisioning mechanisms.

Vulnerability Management

Manufacturers must establish processes for identifying and addressing vulnerabilities.

These processes should cover:

• Monitoring security vulnerabilities.
• Tracking affected components.
• Assessing vulnerability impact.
• Developing security fixes.
• Distributing updates.
• Communicating relevant security information.

Vulnerability management continues after the product reaches customers.

Secure Software Updates

Manufacturers must provide appropriate mechanisms for addressing vulnerabilities through security updates.

For connected devices, this often means implementing secure over-the-air firmware updates.

A robust OTA system should support:

• Firmware authenticity verification.
• Integrity checking.
• Secure update delivery.
• Version management.
• Update failure handling.
• Recovery mechanisms.

Automatic security updates may be required where applicable, subject to the regulation's conditions and product context.

Software Bill of Materials

A Software Bill of Materials (SBOM) is a structured inventory of software components used in a product.

It helps manufacturers identify third-party libraries and dependencies that may contain vulnerabilities.

For example, an IoT gateway might use:

• An embedded Linux distribution.
• OpenSSL.
• An MQTT client library.
• A web server.
• Device drivers.
• Third-party communication libraries.

If a vulnerability is discovered in one of these components, the SBOM helps identify affected products.

Under the CRA, manufacturers must identify and document product components and vulnerabilities, including by drawing up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies.

The regulation does not generally require manufacturers to publish their complete SBOM publicly.

Cybersecurity Risk Assessment

Manufacturers must assess cybersecurity risks associated with their products.

This includes considering intended use, reasonably foreseeable use, and the product's operating environment.

For example, a consumer temperature sensor and an industrial gateway controlling critical processes may face different risk scenarios.

Their security controls should reflect those differences.

Security Support Period

Manufacturers must determine an appropriate support period during which vulnerabilities are handled.

The CRA generally establishes a minimum support period of five years, unless the product is expected to be used for a shorter period.

The support period must account for factors such as expected product lifetime and reasonable user expectations.

This has major implications for IoT manufacturers.

A device sold today may require security maintenance years after its original firmware development team has moved to other projects.

Building a CRA-Ready IoT Technology Stack

There is no single technology stack that automatically guarantees CRA compliance.

Compliance depends on product-specific risks, technical controls, documentation, development processes, and conformity assessment.

However, certain technologies can help manufacturers implement relevant security capabilities.

Embedded Device Security

Potential technologies include:

• Secure boot.
• Trusted execution environments.
• Hardware security modules.
• Secure elements.
• Cryptographic key storage.
• Signed firmware.

Hardware security features can strengthen device protection, but they may increase component costs and development complexity.

Manufacturers should select controls based on the product's risk profile.

Firmware Development and Testing

Common practices include:

• Static application security testing.
• Software composition analysis.
• Dependency vulnerability scanning.
• Firmware signing.
• Automated security testing.
• Secure build pipelines.

Automating these checks can help identify vulnerabilities earlier in development.

Cloud and Device Management

Cloud platforms can support:

• Device authentication.
• Certificate management.
• Firmware distribution.
• Device health monitoring.
• Security event logging.
• Remote configuration.

Platforms such as AWS IoT and Azure IoT provide capabilities that can support secure device management.

However, using a major cloud provider does not automatically make a connected product CRA-compliant.

Manufacturers remain responsible for evaluating their overall product and applicable obligations.

SBOM and Vulnerability Tools

Tools such as Syft, Trivy, and Dependency-Track can support software component visibility and vulnerability monitoring.

Their capabilities differ.

For example:

• Syft can generate software inventories.
• Trivy can scan software artifacts for known vulnerabilities.
• Dependency-Track can help monitor software component risk over time.

These tools are useful building blocks, but they do not replace cybersecurity risk assessment or regulatory documentation.

‍

‍

‍