CRA in Embedded Projects: What Manufacturers Need to Do Now to Prepare Technically

The CRA is an EU regulation for “products with digital elements.” This refers to hardware and software products that are, or can be, directly or indirectly connected to a device or network. This also includes remote data processing solutions if the manufacturer is responsible for them and the product would no longer function without them. This is particularly relevant for many embedded products because today, it is no longer just the device itself that is considered, but also its app, its backend, or its cloud-based additional functions.

It is important to note that the CRA is fundamentally market-oriented. It applies to products made available on the EU market as part of a commercial activity. Certain product groups are exempt if they are already covered by other EU regulations with their own cybersecurity requirements, such as in parts of medical, aviation, or automotive regulations. For manufacturers, this means: Not every digital product automatically falls under the same CRA framework, but a great many embedded products are directly covered by it.

The embedded environment is characterized by long product lifecycles, specialized hardware, legacy platforms, proprietary interfaces, and third-party components. This is precisely where the CRA comes into play: In the future, manufacturers must be able to demonstrate that they systematically assess cyber risks, technically implement security requirements, and address vulnerabilities throughout the product’s lifecycle. The CRA thus complements other regulations such as NIS2: While NIS2 primarily addresses organizations and their operational processes, the CRA focuses on the product itself.

For embedded projects, this means a clear shift in practice: Security is transitioning from an additional requirement to an integral part of product development. Those who add security mechanisms only shortly before market launch will usually be too late in the future. This is because the CRA requires a cybersecurity risk assessment that encompasses the planning, design, development, production, delivery, and maintenance of the product. This is not merely a compliance appendix but equally affects architecture, component selection, update strategy, logging, hardening, and subsequent operational capability.

Essentially, the CRA requires that products containing digital elements be designed and operated with appropriate cybersecurity features. The European Commission specifies the following guidelines, among others:

• Security by Default
• Access Control
• Use of Cryptography
• Updatability

Before placing a product on the market, manufacturers must also follow several traceable steps:

1. Risk assessment of the product

2. Preparation of technical documentation

3. Conducting the conformity assessment procedure

4. EU Declaration of Conformity

5. CE marking

In addition, there is an obligation to specify a support period and to effectively address vulnerabilities during this period. This period is based on the expected service life of the product. Especially for long-lasting embedded devices, this can result in a support requirement spanning several years—often for a period of at least five years.

Manufacturers must also provide information and instructions that enable the safe installation, configuration, use, and maintenance of the product. This is a key point, particularly for embedded devices with a long service life, because security does not end with delivery.

The reporting requirements, which take effect as early as September 11, 2026, are particularly often underestimated. Strict deadlines will then apply to actively exploited vulnerabilities and serious security incidents:

• Early warning within 24 hours of becoming aware
• Report within 72 hours
• Final report in accordance with further defined procedures

​​​​​​​It is important to note that these reporting obligations also apply to products with digital elements that were made available on the EU market prior to December 11, 2027. Therefore, anyone who believes they only need to address this issue shortly before the end of 2027 is unnecessarily putting themselves under time pressure.

The CRA distinguishes between standard products and important and critical product categories. For many products, a manufacturer’s self-declaration remains an option in principle. However, stricter conformity assessment requirements apply to certain product classes with higher cybersecurity relevance. The Commission cites operating systems, routers, and firewalls as examples of important products; and secure elements and smart meter gateways as examples of critical products. For embedded manufacturers, early classification is therefore important because it directly influences the effort involved, the documentation required, and the potential involvement of a notified body.

Open source is not a blanket exception under the CRA either. The Commission clarifies: Free and open-source software falls within the scope of application if it is brought to market as part of a commercial activity. For embedded products with Linux, Yocto, Buildroot, or other open-source components, this means: It is not the open-source nature alone that is decisive, but rather the specific role it plays in the commercial product.

The CRA is not merely a matter of documentation or compliance. For embedded projects, it primarily means being able to address security-related technical questions early on and in a transparent manner: What are the potential attack vectors? Which interfaces and services are active? How are permissions protected? And how can security updates be reliably deployed in the field?

This is particularly challenging with more complex software stacks, such as those involving Embedded Linux, Android, drivers, middleware, open-source packages, and proprietary application logic. In the future, vulnerabilities must be assessed in a more structured manner, and affected product variants must be identified more quickly.

This requires one thing above all else: transparency regarding components, versions, dependencies, and configurations. Without this foundation, it is nearly impossible to reliably manage the scope of impact, corrective actions, and updates.

In practice, three typical vulnerabilities emerge:

• Unclear product boundaries
  Devices, firmware, apps, web interfaces, and the cloud are often developed separately from an organizational standpoint, but are not necessarily treated as separate entities from a regulatory perspective. This creates gaps in responsibilities, assessment, and documentation.

• Insufficiently robust update paths
  A product can only be operated securely over the years if updates are technically planned, tested, documented, and managed effectively. Without this foundation, effectively addressing vulnerabilities quickly becomes a problem.

• Too Slow Incident and Vulnerability Response
  In many companies, there are still too many manual steps between identifying a vulnerability and the ability to systematically manage impact, risk, countermeasures, and communication. The CRA’s short reporting deadlines further exacerbate this gap.

If you want to prepare the CRA properly, you should start with a product inventory rather than the CE documentation. The first step is to clarify which products are actually covered by the CRA, which functions would not be executable without remote processing, and which variants or assemblies must be considered separately. This is followed by the technical classification: product category, attack surfaces, interfaces, user roles, update paths, third-party components, and support model. Only on this basis does a robust risk assessment make sense.

The next step should involve reviewing development and operational processes: secure default settings, hardening, cryptography, authentication, role and permission models, logging, update mechanisms, vulnerability management, and technical documentation. At the same time, it is worthwhile to establish a clear reporting process for actively exploited vulnerabilities and serious incidents, as this requirement takes effect as early as 2026. This point is important: even though harmonized standards are still being developed, the regulatory direction has long been set. In 2025, the Commission launched a standardization mandate comprising 41 standardization projects, and in 2026 it published additional guidelines for consultation, including on support periods and interaction with other EU regulations. Waiting for finalized standards is therefore not a sensible strategy.

For embedded manufacturers, the CRA is, above all, a matter of architecture, lifecycle, and process. Anyone who focuses solely on the eventual declaration of conformity is missing the bigger picture. What matters most is whether products are technically designed in such a way that risks can be assessed early on, components managed transparently, updates rolled out securely, and vulnerabilities reliably addressed over the years. This is precisely where, in practice, compliance on paper diverges from true product maturity. We are happy to support you in the technical implementation of CRA-compliant embedded projects.

For many companies, now is the right time to reassess existing platforms, redesigns, and ongoing embedded projects from a CRA perspective. While the deadlines may seem far off at first glance, they will impact development, maintenance, documentation, and reporting processes much sooner than many roadmaps currently indicate. This article does not replace a legal case-by-case review, but technically the direction is clear: Security-by-Design, robust update capabilities, and clean vulnerability management processes are becoming key factors for market access.