The Rapid Growth of Global IoT Connections

The EU Cyber Resilience Act Is Moving From Policy to Operational Requirements

The European Union's Cyber Resilience Act is changing how manufacturers approach the security of products with digital elements. The regulation covers a wide range of connected hardware and software and places cybersecurity responsibilities across the product lifecycle rather than treating security as a one-time certification exercise.

The timeline is particularly important in 2026.

Since September 11, 2026, manufacturers have been required to report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The broader set of main CRA obligations is scheduled to apply from December 11, 2027.

That creates a transition period in which manufacturers need to build the processes that will eventually support full compliance.

Security Becomes a Product Responsibility

Traditional product development often separates engineering, security, and compliance. The CRA pushes these areas closer together.

Manufacturers need processes for identifying vulnerabilities, assessing their impact, maintaining security information, and responding when a serious problem is discovered after release.

The reporting obligation is especially significant because the regulation establishes defined response windows. Manufacturers must provide an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, followed by more detailed notifications under the CRA rules.

This means vulnerability response cannot depend entirely on an informal security team workflow. Product engineering, security operations, legal teams, and compliance functions need a coordinated process.

The Software Supply Chain Matters

Modern connected products rarely contain only code written by the manufacturer.

Applications may depend on open-source libraries, operating-system components, third-party services, development frameworks, and hardware supplied by other companies. A vulnerability in one dependency can therefore become a product-security problem for the final manufacturer.

Software composition analysis can help identify components and versions, but an inventory alone is not enough. Organizations need to know which components are actually deployed, where they are used, and how quickly security updates can reach customers.

This is one reason software bills of materials, or SBOMs, have become increasingly important. An SBOM provides structured information about software components and can support vulnerability response, although it does not replace security testing or lifecycle management.

Secure Updates Are Part of the Lifecycle

A secure product is not simply a product that passes testing before launch.

Connected devices may remain in customer environments for years. Vulnerabilities can emerge long after the original development team has moved on to another product generation.

Manufacturers therefore need update mechanisms that are reliable, authenticated, and practical for the expected deployment environment.

For consumer devices, automatic updates may be the most effective approach. Industrial systems can be more complicated because updates may require maintenance windows, compatibility testing, or operational approval.

The right strategy depends on the product, but the underlying requirement is the same: security needs to continue after the initial sale.

Open-Source Software Has a Special Role

The CRA also recognizes the role of open-source software in the European technology ecosystem.

Not every open-source contributor is treated in the same way as a commercial product manufacturer. The regulation distinguishes commercial activity and the responsibilities of open-source software stewards.

The reporting obligations for relevant open-source software stewards under Article 24(3) are scheduled to begin on December 11, 2027.

This distinction matters because open-source projects often have limited resources and distributed maintenance models. Organizations that commercially integrate open-source components remain responsible for understanding the security implications of those components within their own products.

What Engineering Teams Should Do Now

The most useful preparation is operational rather than cosmetic.

First, establish an accurate inventory of products, software components, dependencies, and responsible teams.

Second, connect vulnerability monitoring with product ownership. Security alerts should quickly identify which products are affected and who can authorize a response.

Third, document the update process before a crisis occurs. Emergency patching is difficult when signing keys, release pipelines, customer notifications, and testing procedures have never been defined.

Fourth, preserve evidence. Vulnerability assessments, security decisions, remediation steps, and release records can become important when demonstrating that a security process was followed.

The Cyber Resilience Act is therefore more than another compliance checklist. It pushes cybersecurity deeper into product engineering and lifecycle management.

For manufacturers, the practical question is no longer whether a product is secure on launch day. The stronger question is whether the organization can continuously identify, respond to, document, and remediate security problems throughout the product's useful life.