CRA in the industrial sector: complete compliance guide

The Cyber Resilience Act (CRA) represents the most significant regulatory change for the European industrial sector in decades. If you manufacture embedded software, IoT devices, industrial machinery, or any product with digital elements destined for the EU market, this article is your definitive compliance guide.

What is the CRA and why does it affect the industrial sector

The Cyber Resilience Act (EU Regulation 2024/2847) is the European regulation that establishes mandatory cybersecurity requirements for all products with digital elements marketed in the European Union. Published in October 2024, the CRA introduces the concept of "cybersecurity by design" as a legal obligation, not a recommendation.

The industrial sector is particularly affected for a simple reason: industrial systems have traditionally prioritized operational continuity and physical safety over cybersecurity. Many PLCs, SCADA systems, and industrial controllers were designed in an era when network connectivity was an exception rather than the rule. Today, these same systems are connected to corporate networks, cloud platforms, and in many cases, directly to the internet. The CRA recognizes this reality and requires security measures proportional to the risks involved.

The cybersecurity by design principle

The CRA starts from a fundamental premise: the vast majority of successful cyberattacks exploit known vulnerabilities that could have been avoided with more rigorous development practices. This is not speculation—analysis of major industrial incidents in recent years confirms that most compromises occurred through exploiting well-documented vulnerabilities that had available patches.

Therefore, the regulation requires security to be incorporated from the earliest stages of product design, not added as an additional layer after the fact. This represents a fundamental shift in how industrial products must be conceived and developed.

For the industrial sector, this means that PLCs, SCADA systems, and industrial control systems must be designed with security as a primary consideration from the outset. Firmware for industrial IoT devices must include secure update mechanisms that allow vulnerabilities to be patched throughout the product's lifecycle. HMI and supervisory systems must implement robust authentication that prevents unauthorized access to critical functions. Industrial communication interfaces, whether Modbus, OPC-UA, MQTT, or proprietary protocols, must be adequately protected against interception and manipulation.

Products with digital elements: definition and examples

The CRA defines "product with digital elements" as any software or hardware product and its remote data processing solutions, including software or hardware components marketed separately. This deliberately broad definition captures not only finished products but also the components that integrate into larger systems.

For industrial manufacturers, this has important implications. A sensor manufacturer cannot assume that their component is "too small" to be covered—if it includes firmware or processes data, it is a product with digital elements. Similarly, software vendors cannot argue that their SCADA system is "just software"—the CRA applies equally to hardware and software.

Industrial products clearly covered

The following table provides a non-exhaustive classification of industrial products according to CRA risk categories. The actual classification of a specific product depends on its characteristics and intended use, but these examples illustrate typical positioning.

The component integration challenge

A frequently underestimated aspect of CRA compliance concerns integrated third-party components. When a manufacturer incorporates a third-party library into their firmware, or uses an open-source component in their control system, they become responsible for that component's compliance.

This does not mean the manufacturer must audit every line of code from their suppliers. But it does mean they must have processes to identify their components, assess their security posture, and respond when vulnerabilities are discovered. The SBOM (Software Bill of Materials) required by the CRA serves precisely this purpose: to maintain traceability of all components integrated into the product.

CRA application timeline

The CRA establishes a phased implementation schedule that gives manufacturers time to adapt their processes, but the deadlines are firm and approaching rapidly. Understanding this timeline is essential for planning compliance activities.

The September 2026 deadline deserves particular attention. From that date, any manufacturer who discovers an actively exploited vulnerability in their product must notify the designated CSIRT within 24 hours. This requires not only having technical systems to detect vulnerabilities, but also organizational processes to escalate and communicate them within the required timeframe.

Essential cybersecurity requirements (Article 10)

Annex I of the CRA establishes the essential requirements that every product with digital elements must meet. These are not optional recommendations—they are legal obligations that must be demonstrable through technical documentation and, in some cases, verified by notified bodies.

Security by design

The security by design requirements form the foundation of CRA compliance. Attack surface minimization means that products should only expose the functionality strictly necessary for their intended purpose. Software and firmware integrity protection ensures that unauthorized code cannot be executed on the device. Authentication and access control mechanisms prevent unauthorized users from accessing sensitive functions. Protection of stored and in-transit data safeguards confidentiality and integrity. Logging of relevant security events enables incident detection and forensic analysis.

Each of these requirements must be addressed in the product's technical documentation, explaining how it is implemented and providing evidence of its effectiveness.

Vulnerability management

Vulnerability management is not a one-time activity but an ongoing process throughout the product's lifecycle. Component identification and documentation through an SBOM allows rapid assessment when new vulnerabilities are published. A process for receiving and managing vulnerability reports ensures that external researchers and users can communicate security issues. Timely correction through security updates demonstrates the manufacturer's commitment to maintaining product security. Coordinated vulnerability disclosure balances transparency with responsible handling of security information.

Security updates

The CRA requires providing security updates for a minimum period of 5 years from product commercialization, or during its expected useful life if longer. This requirement has significant implications for product architecture and business models.

Products must be designed with update capability from the outset. Update mechanisms must be secure, preventing attackers from exploiting the update channel to compromise devices. Manufacturers must maintain the infrastructure and expertise necessary to develop, test, and deploy security updates throughout the support period.

Technical documentation: CRA Annex VII

Article 31 of the CRA requires manufacturers to prepare and maintain complete technical documentation according to Annex VII requirements. This documentation serves multiple purposes: it demonstrates compliance to market surveillance authorities, supports conformity assessments by notified bodies, and provides a reference for the manufacturer's own processes.

The required documentation includes a general product description and intended use that establishes the context for security requirements. Design and development documentation, including architecture, diagrams, and specifications, shows how security was incorporated into the product. The cybersecurity risk assessment performed demonstrates that threats were identified and addressed. A list of applicable essential requirements and how they are met creates traceability between regulatory requirements and product features. The SBOM with all components enables supply chain security. Test reports of conformity assessments performed provide evidence that the product meets requirements. Instructions for use with security information for users ensure that end users can maintain security during operation.

Retention requirement: 10 years

Technical documentation must be kept for 10 years from product commercialization (Article 31.13). This requirement recognizes the long lifecycles typical of industrial products and ensures that documentation remains available for market surveillance throughout the product's operational life.

The 10-year retention period means manufacturers need robust document management systems. Documentation must be maintained in a way that preserves integrity and accessibility over time, even as organizational structures and technology platforms evolve.

CE marking and Declaration of Conformity

EU Declaration of Conformity (Article 28)

Before marketing the product, the manufacturer must issue an EU Declaration of Conformity according to the Annex V format. This declaration is a formal commitment by the manufacturer that the product meets all applicable requirements.

The Declaration of Conformity must include product and manufacturer identification, ensuring clear traceability. The declaration of conformity with essential requirements is the manufacturer's formal statement of compliance. References to applied harmonized standards demonstrate how technical requirements were met. Notified body identification (if applicable) confirms third-party assessment. The signature of the authorized responsible person creates legal accountability.

The Declaration of Conformity must be updated whenever there are changes that affect the product's conformity, and must be available to market surveillance authorities upon request.

CE Marking (Article 30)

The CE marking must be placed visually, legibly, and indelibly on the product or its packaging. For software products without physical packaging, it can be included in the user interface or digital documentation.

The CE marking is not just a label—it represents the manufacturer's declaration that the product complies with all applicable EU requirements. Applying the CE marking to a non-compliant product is a serious infringement with significant penalties.

Conformity assessment: Modules A, B+C, H

The CRA establishes different assessment procedures according to the product's risk category. Understanding which procedure applies to your product is essential for planning the compliance process and associated costs.

Module A: Internal production control

For default category products (low risk), Module A allows the manufacturer to perform the conformity assessment internally. No notified body intervention is required, but the manufacturer must prepare complete technical documentation demonstrating compliance with all applicable requirements. This documentation must be available to market surveillance authorities upon request.

Module A provides flexibility and reduces compliance costs for lower-risk products, but the manufacturer remains fully responsible for ensuring compliance.

Modules B+C: EU type examination + Type conformity

For Class I products (important risk), the assessment is divided into two phases. In Module B, a notified body examines the technical design and verifies that it meets essential requirements. If the examination is successful, the notified body issues an EU type-examination certificate. In Module C, the manufacturer ensures that production conformity with the approved type is maintained through appropriate quality control measures.

This combined approach ensures independent verification of the design while allowing the manufacturer to manage production without continuous third-party oversight.

Module H: Total quality assurance

For Class II products (critical risk), Module H requires a comprehensive quality management system audited by a notified body. This includes continuous supervision of design and production processes, not just assessment of the finished product.

Module H is appropriate for products used in critical infrastructure or high-security applications where the consequences of failure are severe. The ongoing relationship with the notified body provides additional assurance but also increases compliance costs and administrative burden.

Penalty regime: up to 15 million euros

Article 53 of the CRA establishes significant penalties for non-compliance. These penalties are designed to be dissuasive even for large organizations, and are calibrated to the severity of the infringement.

For a medium-sized industrial manufacturer with 100 million euros in revenue, a 2% penalty represents 2 million euros—a significant impact on profitability. For larger organizations, the absolute cap of 15 million euros may be more relevant.

Beyond financial penalties, non-compliance can result in market withdrawal orders that prevent sales throughout the EU, reputational damage that affects relationships with customers and partners, and potential personal liability for responsible individuals under certain circumstances.

How EMETHRA helps with CRA compliance

EMETHRA is the platform specifically designed to help industrial manufacturers comply with the CRA efficiently. The platform addresses the key technical challenges of compliance while generating the documentation required by the regulation.

Automated dependency analysis

Identifying and tracking software components is one of the most technically challenging aspects of CRA compliance. EMETHRA provides complete SBOM generation in SPDX 2.3 (ISO 5962:2021) and CycloneDX 1.5 formats, meeting the requirements of both CRA and EO 14028. The platform identifies known vulnerabilities (CVEs) in all dependencies, including transitive dependencies that are often invisible to developers. The complete transitive dependency tree provides full visibility into components that would otherwise be hidden. Continuous monitoring of new vulnerabilities ensures that emerging threats are detected promptly.

Automatic regulatory documentation

Generating and maintaining technical documentation is time-consuming but essential for compliance. EMETHRA automates Annex VII technical documentation generation, reducing the manual effort required. Templates for EU Declaration of Conformity ensure that all required elements are included. Cybersecurity risk assessment reports document the analysis performed. Evidence packages for notified bodies compile the information needed for conformity assessments.

Alert system for 24h reporting

The September 2026 deadline for vulnerability reporting requires manufacturers to have systems in place for rapid detection and notification. EMETHRA provides real-time CVE alerts integrated into CI/CD pipelines, ensuring that development teams are immediately aware of new vulnerabilities. Automatic preparation of CSIRT notifications reduces the time required to comply with reporting obligations. Vulnerability history for traceability supports ongoing compliance monitoring. The compliance status dashboard provides visibility into the organization's overall compliance posture.

CRA compliance checklist

Use this list to assess your current preparation level and identify areas requiring attention:

• Inventory of products with digital elements marketed in EU
• Product classification according to CRA risk categories
• SBOM generated for each product
• Documented cybersecurity risk assessment
• Vulnerability management process implemented
• Vulnerability reporting channel established
• Security update plan (minimum 5 years)
• Annex VII technical documentation prepared
• 10-year retention archive system
• EU Declaration of Conformity drafted
• CE marking planned
• 24h alert system for CSIRT reporting
• Team training on CRA requirements

Reviewing this checklist quarterly helps ensure that compliance activities remain on track and that emerging gaps are identified early.

---

Regulatory references:

• Cyber Resilience Act - EUR-Lex
• ENISA CRA Guide
• ISO 5962:2021 - SPDX