Cyber Resilience Act (CRA)

What it means for product development, engineering and compliance

Insights of the interview

What is the Cyber Resilience Act?

The Cyber Resilience Act is a European regulation introducing binding cybersecurity requirements for products with digital components. Its core objective is to reduce cyber risks across the European market and strengthen the resilience of digital products.

The CRA pursues three main goals:

• Strengthening product security across the entire lifecycle
• Standardising cybersecurity requirements across the EU
• Improving response capabilities to security incidents

The CRA applies to almost all products with digital elements, including:

The exact scope is defined in Article 2 of the regulation. 

A core element of the CRA is the risk-based classification of products, which determines the level of regulatory requirements.

Group I: standard products
According to market studies to date, approximately 90% of all affected products are likely to fall into the Standard category, such as consumer IoT or basic software solutions.

Key characteristics:

• Low to moderate cybersecurity risk  
• Reduced regulatory requirements  
• Self-declaration possible  

Group II & III: important products (Class 1 & 2)

This category includes products with higher security risk, such as:

• Password managers
• Firewalls
• Operating Systems
• Microprocessors

These products require stronger focus on:

• Secure devlopment processes
• Vulnerability management
• Technical documentation and evidence

Group IV: critical products

Critical products are typically used in safety-relevant infrastructure, such as energy systems, industrial control environments or critical IT systems. They are subject to stricter requirements:

• Mandatory external certification  
• Comprehensive security assessments  
• Enhanced documentation and verification obligations  

A key aspect of the Cyber Resilience Act is that it affects two different perspectives at the same time.

In practice, the biggest challenge related to the Cyber Resilience Act is not the regulation itself, but how organisations are structured internally.

Many companies approach the CRA either from a pure compliance perspective or from a purely technical engineering perspective. This separation often leads to friction in day-to-day execution.

While compliance teams focus on documentation, classification and regulatory reporting, engineering teams focus on architecture, implementation and system design. Both perspectives are valid, but insufficient when applied in isolation.

Problems arise particularly when security requirements are introduced too late in the development process or when technical risks are not properly translated into regulatory assessments. This creates a gap between technical reality and formal compliance.

The CRA therefore forces organisations to bridge this gap and treat security as an integral part of the entire product lifecycle.

For product and engineering teams, the CRA fundamentally changes the development paradigm. Security is no longer a post-development validation step but an inherent part of architectural and design decisions.

Security by Design
Security requirements must be considered at the architectural stage, including system design, interfaces and attack surface reduction.

Update and Patch Capability
Products must be designed to allow long-term, secure and traceable deployment of security updates.

Third-Party Components and Dependencies
Modern products rely heavily on external components. The CRA requires full transparency and continuous risk evaluation of these dependencies.
Practical Context

In real-world environments, this becomes especially visible in security-critical systems. For example, if a firewall system in a banking environment is compromised, the impact is not limited to a single product but may affect multiple interconnected systems.

In such cases, a chain of actions is triggered: engineering or security teams first detect and analyse the anomaly, compliance evaluates the regulatory implications, and management decides on escalation and potential reporting obligations.

The CRA also applies to existing stock if products are placed on the market after 2027.

Legacy Products

• Products must be CRA-compliant before market placement
• historical production alone is not sufficient
• reassessment may be required  

This introduces direct implications for supply chain and lifecycle management.
  
Spare Parts

Spare parts are assessed differently depending on their nature:

• Identical components are generally exempt
• functionally equivalent components may also be exempt
• modified or redesigned components may be classified as new products  

This area requires close coordination between engineering, procurement and compliance.

The Cyber Resilience Act is less a technical or purely regulatory challenge and more an organizational transformation.
Its success depends on early and structured collaboration between:

• Product development
• Engineering
• Security  
• Compliance  

Organizations that integrate these disciplines early not only reduce regulatory risk but also significantly improve product security and development efficiency.

The expert interview highlights that the Cyber Resilience Act is relatively compact in its regulatory structure. However, its real complexity only becomes visible during implementation within organizations.

Many companies initially underestimate the effort because the CRA is perceived as a purely compliance-driven regulation. In reality, the challenge lies in integrating its requirements into existing development, product and organizational structures.

A key aspect is early product classification. This is not a formal administrative step but the foundation for all subsequent technical and regulatory decisions.

The CRA also cannot be treated as an isolated compliance topic. Instead, it must be understood as a cross-functional framework spanning development, product management, security, and compliance.