Cyber Resilience Act: What Changes for OT and IoT Device Manufacturers

What the CRA Is and Who It Applies To

The EU Regulation on Cyber Resilience (Cyber Resilience Act, CRA) entered into force in 2024 and becomes fully applicable in 2027. It is the first European piece of legislation that imposes cybersecurity requirements directly on manufacturers of products with digital elements: from hardware to software, from connected devices to components.

The logic of the CRA differs from that of NIS2 or DORA: it does not address the operators who use the products, but those who design and sell them. The goal is to shift responsibility for security toward the origin of the supply chain, building security into product design instead of leaving it as a problem for the end user.

The scope of application is broad: all products with digital elements that are placed on the European market, except for certain products already covered by other sector-specific legislation. For the OT and industrial IoT world, this means PLCs, connected sensors, industrial gateways, HMIs, industrial routers, embedded control systems and supervisory software.

Obligations for Manufacturers: Security by Design, Updates, Disclosure

The CRA defines three main categories of obligations.

Essential security requirements: the product must be designed and developed with security as an intrinsic requirement, not added after the fact. This includes: minimized attack surface, robust authentication, no default credentials, data protected at rest and in transit, secure update capability. These requirements must be met at the time the product is placed on the market and demonstrable through technical documentation.

Vulnerability management: manufacturers must implement processes to identify and remediate vulnerabilities in their products throughout the entire supported lifecycle. This means a coordinated vulnerability disclosure (VDP) program, the ability to deliver security updates securely, and the obligation to notify ENISA of actively exploited vulnerabilities within 24 hours of discovery.

Transparency obligations: complete technical documentation, EU declaration of conformity, CE marking, and information for the end user on how to keep the product secure over time.

"Important" and "Critical" Products: The OT/IoT Risk Categories

The CRA distinguishes three categories with different compliance requirements:

Standard products: the majority of products. They can self-certify by following the CEN/CENELEC harmonized standards when available.

Important products (Class I and II): products with an elevated risk profile. Class I can still self-certify if it applies harmonized standards; Class II requires the involvement of a third-party conformity assessment body.

Critical products: the highest level. They require a European cybersecurity certification scheme.

For the industrial OT/IoT world, many products fall into the Class I and II categories: operating systems for industrial use, hypervisors, industrial routers and switches, microcontrollers with connectivity, and industrial IoT gateways. Some control systems for critical infrastructure may fall into the critical category.

Deadlines and Transition Period

The Regulation has been in force since December 2024. The main deadlines:

• September 2026: the obligations to notify vulnerabilities to ENISA become applicable.
• December 2027: all CRA requirements become fully applicable for new products placed on the market.

Products already on the market before December 2027 do not have to be withdrawn, but they must comply in the event of substantial updates. Manufacturers with long development cycles, as is often the case in industrial OT, must start now to be ready.

How to Prepare: From Documentation to Process

CRA compliance is not a documentation exercise: it is a transformation of the product development process.

Product portfolio audit: identify which products fall within the CRA scope, which category they belong to, and what the gap is between the current state and the requirements.

Secure development lifecycle (SDL): build security requirements into every phase of development: threat modeling at the design stage, secure code review, penetration testing before release, and a formal process for managing vulnerabilities after release.

Vulnerability disclosure program: establish a formal channel for receiving vulnerability reports from researchers and users, with defined processes for assessment, remediation and public communication.

Technical documentation: the CRA requires detailed technical product documentation that demonstrates compliance with the essential requirements. It is not a marketing document: it must include risk analysis, a description of the security measures implemented, and verification testing.

For manufacturers of OT and IoT devices accustomed to long development cycles and customers with stability requirements, the CRA represents a significant cultural change. Security can no longer be a last-minute addition or delegated to the end user: it must be an integral part of the product from the first line of code.

The MON5 Angle

The CRA concerns manufacturers, but its effects fall on those who use the devices: the more vulnerabilities are formally disclosed, the more security updates will need to be managed on the plant floor. Knowing which products and which firmware versions are present on the network becomes the condition for benefiting from the new vendor obligations.

The ANALYZE phase of MON5 maintains a continuous asset inventory, correlates published CVEs with the devices actually installed, and supports CRA and NIS2 compliance paths. To build this visibility ahead of the 2026 and 2027 deadlines, start with an OT assessment.