Cyber Resilience Act: What Changes for Firmware and IoT

The Cyber ​​Resilience Act will not yet come into full application on 11 September 2026. However, its first operational phase will begin: manufacturers will have to report actively exploited vulnerabilities and serious incidents that compromise the security of products with digital elements.

For a company that produces embedded devices, Linux gateways, IoT equipment or connected machines, the problem is not simply filling out a report. Before being able to communicate an event within the established deadlines, the company must know which products are involved, which firmware versions they use, which software components they contain, where they are installed and through what procedure they can be corrected.

If this information is scattered across outdated repositories, old development computers, Excel files, and technicians' personal knowledge, meeting a deadline of just a few hours becomes extremely difficult. The Cyber ​​Resilience Act therefore highlights a principle that has often been underestimated in the embedded sector: security does not end with the delivery of the product, but must be managed throughout its life cycle.

The Regulation (EU) 2024/2847, known as the Cyber ​​Resilience Act or CRA, does not mandate a single valid technical architecture for any device. However, it requires that hardware and software placed on the European market are designed, developed, documented, updated and maintained taking cybersecurity risks into account.

For a more specific overview of secure boot, updates and Linux systems, our in-depth analysis is also available on Secure embedded Linux, Cyber ​​Resilience Act, secure boot and OTA. In this article we instead analyze what concretely changes from September 2026, how to prepare for full application in 2027 and why the CRA represents above all a product engineering problem.

In summary

• The Cyber ​​Resilience Act went into effect on December 10, 2024.
• Reporting obligations for actively exploited vulnerabilities and serious incidents begin on September 11, 2026.
• The main provisions of the Regulation will apply from 11 December 2027.
• The reporting also concerns products already made available on the European market.
• Firmware, bootloader, software dependencies, updates, SBOM, diagnostics and support period become parts of regulated product management.

This article is for informational and technical purposes. The legal qualification of a specific product, the choice of conformity assessment procedure and the interpretation of the Regulation must be confirmed with competent legal professionals or compliance specialists.

The CRA brings cybersecurity into the product

For many years the cybersecurity of an embedded device has been treated as an additional feature. The product was designed to perform a function and, at a later stage, it was evaluated whether to add communication encryption, a password, an upgradeable bootloader or some access control.

This approach can work when security is viewed solely as a business benefit. It becomes much more fragile when the manufacturer must demonstrate that the risks have been assessed, that the technical choices are consistent with those risks, and that there is a process to manage vulnerabilities after the sale.

The CRA then moves the planning application.

It is no longer enough to ask:

“Does the device communicate and perform its function correctly?”

It becomes necessary to ask yourself:

“How will the device react if a credential is compromised, a library has a vulnerability, an update is interrupted, or a maintenance interface is used by an unauthorized person?”

This transformation directly affects firmware, bootloaders, operating systems, connected cloud services, production tools, support procedures and technical documentation.

Compliance cannot be built at the end of the project by adding a statement to the manual. It must derive from a coherent chain:

risk analysis → security requirements → architecture → implementation → verification → release → monitoring → update → support

The dates of the Cyber ​​Resilience Act should not be confused

One of the main sources of confusion is the presence of different deadlines. Saying generically that "the CRA comes into force in 2026" or that "everything will be mandatory in 2027" does not correctly describe the application path.

The Regulation has already entered into force on 10 December 2024. Some provisions have started to apply before full operation, while the main obligations will become applicable on 11 December 2027.

The distinction is important because September 11, 2026 does not represent the date by which each device will already have to complete the entire CRA compliance assessment process.

From that date, however, the manufacturer must be able to manage and notify certain security events. This means that part of the organization and technical architecture must be prepared before 2027.

The European Commission maintains a page dedicated to the status of implementation of the Cyber ​​Resilience Act, useful for following the progress of guidelines, application documents, standards and reporting infrastructures.

What must be reported from 11 September 2026

The CRA requires manufacturers to report two main categories of events: actively exploited vulnerabilities and serious incidents that impact product security.

This does not mean that any published bug, anomaly or vulnerability should automatically be reported.

An actively exploited vulnerability is one for which there is reliable evidence indicating actual, unauthorized malicious use. The mere presence of a CVE identifier or the publication of a vulnerability in a library used by the product does not demonstrate, in itself, that that vulnerability has been actively exploited in the context foreseen by the Regulation.

The manufacturer must still evaluate the problem, determine its impact and correct it when necessary. However, the reporting obligation of article 14 is triggered in the presence of the conditions established by the CRA, not for every security update available on the market.

The same principle applies to accidents. A reboot, communication failure, or temporary connection loss do not automatically become serious cybersecurity incidents. The nature, impact on safety, diffusion and consequences on the product and its users must be assessed.

The expected deadlines are particularly tight.

The initial alert does not necessarily presuppose that the entire investigation has already been concluded. It serves to quickly communicate the existence of the problem. The information can be completed during subsequent steps.

Notifications will be made through the ENISA Single Reporting Platform. The platform will forward the information to the competent CSIRT and, according to the methods established by the Regulation, to the other interested bodies.

The European Commission has published a page dedicated to Cyber ​​Resilience Act reporting requirements, while ENISA has already made available instructions for registering representatives and sending notifications.

Reporting also concerns products already on the market

One of the most relevant points for the industrial sector is that reporting obligations do not only concern new products designed with a view to 2027.

The Commission's official summary clarifies that the reporting applies to products with digital elements made available on the European market, including those released before 11 December 2027.

Let's consider an industrial gateway marketed in 2022 and still used by hundreds of customers. If the manufacturer becomes aware of an actively exploited vulnerability affecting the security of that gateway in 2026, the original design date does not automatically eliminate the reporting requirement.

This creates an important difference between two plans.

For products placed on the market before 11 December 2027, the full application of the CRA provisions is also linked to the presence of a subsequent substantial modification. Reporting, however, follows its own transitory discipline and also affects products already distributed.

A company should therefore not interpret 2027 as a reason to postpone any activity. Even before new products comply, it must understand which existing families are still supported, which versions are in the field and who is responsible for managing a possible incident.

Which embedded and IoT products can fall under the CRA

The Cyber ​​Resilience Act uses the definition of a product with digital elements. The definition includes software or hardware products and related remote data processing solutions, as well as separately marketed software or hardware components.

A product potentially enters the scope when it is made available on the market in the course of a commercial activity and its intended, or reasonably foreseeable, use includes a logical or physical connection, direct or indirect, with a device or network.

The connection therefore does not necessarily have to coincide with a direct connection to the Internet.

A controller can communicate with a machine via CAN, industrial Ethernet or serial. A card can be connected to a gateway. An application can depend on a remote service. A firmware can be marketed as a component to be integrated into a larger product.

This table does not replace a product analysis. Some sectors and some categories are governed by specific European regulations, while other products may be excluded from the CRA or subject to rules coordinated with other acts.

The design point is that it is not enough to check for the presence of a Wi-Fi port. How the product is marketed, its functions, the intended connection, remote dependencies and the entity bringing it to market must be considered.

Who is the manufacturer when the firmware is developed externally

In the embedded sector it is common for a company to outsource the development of firmware, embedded Linux, applications, PCBs or cloud services to a consultant or external supplier.

The CRA considers the manufacturer to be the person who develops or produces the product, or has it developed or produced, and subsequently markets it under his own name or brand.

Let's imagine that a company produces an automatic machine and entrusts Silicon Logix with the development of the controller firmware. The machine is then sold under the brand of the client company.

In this scenario, the customer normally remains the manufacturer who places the product on the market under its own brand. Outsourcing development does not automatically transfer all of the manufacturer's regulatory obligations to the consultant.

However, this does not mean that the relationship with the external developer can remain informal.

To prepare technical documentation, manage vulnerabilities and maintain the product, the manufacturer will need information and activities from the supply chain: component versions, dependencies, build procedures, update policies, interface documentation, test results and future availability of technical support.

Development contracts will therefore have to more precisely define ownership and delivery of materials, vulnerability management, intervention times, maintenance responsibilities, updates, source accessibility and preservation of the build environment.

However, if a company develops its own software platform or device and sells it under its own brand, that company can directly assume the role of CRA manufacturer.

The 24-hour deadline requires product visibility

The real problem with reporting is not the platform used to send the report. The problem is being able to produce reliable information in a very short time.

When a vulnerability emerges in a TLS library, Linux kernel, bootloader or networking stack, the manufacturer needs to be able to attach the component to its product range.

The information chain should look like this:

vulnerability → component and version → firmware build → hardware variant → affected products → deployed devices → impact → mitigation → update

If the company does not know which version of the library was included in a certain firmware, the investigation begins with an archaeological reconstruction. If the device does not reliably expose the installed version, it becomes difficult to understand which drives are affected. If there is no inventory of products yet supported, it is unclear which customers need to be notified.

Reporting therefore makes certain capabilities necessary that were often considered only internal development tools: unique identification of releases, traceability of builds, preservation of sources, association between firmware and hardware, management of security alerts and definition of an incident manager.

In many products, diagnostics capable of distinguishing a normal malfunction from potentially anomalous behavior will also be useful. The level of telemetry must however be proportionate to the risk, privacy and characteristics of the system.

A small battery-powered sensor doesn't necessarily have to produce the same logs as a Linux gateway. Both, however, should offer the manufacturer sufficient information to identify version, status and conditions relevant to safety.

The risk assessment is not a generic document

The CRA requires the manufacturer to carry out a cybersecurity risk assessment and use the results during planning, design, development, manufacturing, delivery and maintenance.

It is not a question of attaching a generic table to the documentation with items such as "hacker risk" or "data loss".

A useful evaluation must start from the concrete product.

An industrial sensor with LoRaWAN link has a different attack surface than a Linux gateway with remote access. A controller installed in an electrical panel has different conditions than a consumer device reachable from the Internet. A system that controls an engine must consider different consequences than a simple data logger.

The analysis should relate at least four elements: the resources to be protected, the exposed interfaces, the realistic threats and the consequences of a compromise.

Risk assessment must guide technical choices. Not every product will need the same secure element, the same cryptographic algorithm or the same OTA infrastructure.

What must be demonstrable is the coherence between risk, solution adopted and tests performed.

Secure by design doesn't mean adding TLS at the end

A product can use TLS and still be vulnerable.

Encrypted communication does not resolve a shared default password, unauthenticated firmware, a debug mode left accessible, an identical key on all drives, or a parser incapable of properly handling invalid data.

The cybersecurity of an embedded product derives from the entire architecture.

The boot chain, key generation and storage, device identity, user and service authentication, maintenance interface security, initial configuration, network exposure, error handling, and recovery capability must be evaluated.

Factory setup is also important. A product delivered with unnecessary services active, predictable credentials, or freely accessible diagnostic functionality transfers risk to the installer and user.

The default security principle instead requires that the product be delivered in a reasonably secure configuration, leaving the user the possibility to consciously enable any additional functions.

In the case of embedded Linux systems, security involves the bootloader, kernel, device tree, filesystem, system services, applications, privilege management, and the update process. Simply choosing a Linux distribution does not automatically make the product secure.

Secure boot and firmware signing: tools, not slogans

The CRA does not require that every device use the same secure boot implementation. In many products, however, the ability to verify the authenticity and integrity of the software before its execution represents a technical measure consistent with the risk.

Secure boot allows the device to verify that the code to boot comes from an authorized source and has not been altered.

However, the result depends on the entire chain of trust.

If the private key used to sign the firmware is stored without adequate protections, an attacker could produce seemingly valid images. If the bootloader can be replaced through an unsecured interface, the check can be bypassed. If the device accepts vulnerable older versions, a successful update can be undone through a downgrade attack.

A complete architecture can therefore include:

root of trust → verified bootloader → signed firmware → version control → key protection → recovery mode

The actual solution depends on the microcontroller, SoC, production volume, product criticality, and manufacturing process.

To learn more about this topic, the Silicon Logix pages dedicated to are available secure boot and embedded security and the comparison between bootloader for MCUs, embedded Linux and FPGAs.

Updates become part of the architecture

Managing a vulnerability also means being able to distribute a fix.

For many connected devices, a secure update mechanism therefore becomes a critical component. This doesn't mean that any card needs to be connected to a cloud service or automatically update via the Internet.

Isolated industrial equipment can use a signed local update, performed by authorized personnel. A gateway distributed across hundreds of locations may instead require remote infrastructure. A consumer device may have even different needs.

The correct question is not only:

“Can the firmware be updated?”

We need to ask ourselves:

“Can the device verify the authenticity of the update, recover from an outage, prevent the installation of unauthorized versions, and provide proof of which version was actually installed?”

A professional OTA system must consider signature, encryption when necessary, hardware compatibility, memory management, power control, progressive updates, recovery and traceability.

Rollback also needs to be carefully designed. Automatically rolling back to the previous version can restore functionality after a failed update, but should not allow you to reinstall a release containing a known vulnerability.

For this technical rollback and anti-downgrade protection must be coordinated.

Specific information is available in the article Secure OTA firmware update: architecture, signature and rollback and on the page dedicated to development of bootloaders and firmware updates.

The SBOM is the map of the software actually delivered

The Cyber ​​Resilience Act explicitly introduces the Software Bill of Materials, normally referred to as SBOM.

The SBOM describes the software components contained in the product and must be prepared in a commonly used and machine-readable format, covering at least the higher level dependencies required by the Regulation.

It should not be interpreted as a sheet compiled once and stored without connection to the development process.

An effective SBOM must correspond to a precise release.

A microcontroller's firmware may contain manufacturer HALs, RTOS, TCP/IP stack, TLS library, filesystem, bootloader, and proprietary components. In an embedded Linux system, package versions, kernel, bootloader, applications and distribution customizations must also be considered.

The useful relationship is therefore:

product → hardware variant → firmware release → reproducible build → SBOM → known vulnerabilities

If a library is updated, the new build must generate or update its own BOM. If there are different hardware variants, it must be clear which software is compatible with each variant.

The Regulation does not generally require that each SBOM be freely published online. The SBOM is part of the vulnerability management process and the documentation that must be available according to the conditions established by the CRA. Any publication obligations may depend on the product category or specific applicable procedures.

The true value of the SBOM is not administrative. When a vulnerability is published, it allows the manufacturer to quickly understand whether the affected component is present in their products.

Without this correlation, each vulnerability requires reopening the project, rebuilding the build environment, and manually analyzing the code.

The support period changes the economic model of the product

The manufacturer must establish a support period during which vulnerabilities will be effectively managed. The final date, including month and year, must be clearly communicated to the buyer.

The Regulation normally provides for a period of at least five years. When the product is intended to be used for less than five years, the support may correspond to the expected life of use.

However, five years should not automatically be read as the maximum duration.

A consumer gateway and a controller installed on an industrial machine can have very different usage expectations. When determining the period, the nature of the product, reasonably expected duration, dependencies and availability of updates must be considered.

For industrial equipment this point can have a significant impact. Many machines remain operational for ten or fifteen years, while the firmware is often considered finished a few months after delivery.

Maintaining a product means maintaining sufficient sources, documentation, keys, build environment, programming tools and skills to produce a new release.

It also means predicting the cost of monitoring vulnerabilities, testing, remediation and deploying updates.

The support period therefore becomes a technical and commercial characteristic of the product. It must be considered in pricing, maintenance contracts, component selection and resource planning.

Legacy firmware is the hardest problem

Companies starting a new project today can integrate security, upgradeability and traceability from the early stages.

The situation is more complex when the product uses firmware developed many years earlier.

A legacy project may depend on a no longer supported version of the compiler, on libraries without precise information, on a microcontroller nearing the end of its commercial life, or on sources that no longer produce the same binary.

In other cases the company only owns the executable file used in production, while the original developer is no longer available.

It is not always necessary to immediately rewrite the entire product. The decision must derive from a technical evaluation.

Stable, well-documented firmware can be brought under control by introducing versioning, component inventory, and an upgrade path. A project without sources, with shared credentials and exposed interfaces may require a more thorough review.

The economic question is not just how much it costs to change the firmware.

The cost of the intervention must be compared with the risk of maintaining a product on the market that cannot be analysed, updated or supported in a sustainable way.

Existing products and substantial modification

For products placed on the market before 11 December 2027, the Regulation provides for transitional regulations linked to the substantial modification.

Not every fix or update automatically becomes a breaking change.

The assessment must consider whether the change affects the conformity of the product with the essential requirements or changes its intended purpose. The addition of a new remote interface, a major transformation of functions, the replacement of the authentication architecture or the introduction of a cloud service may require a more in-depth evaluation.

Even the person who substantially modifies a product and makes it available again can assume obligations similar to those of the manufacturer.

This is why software change management must become more structured.

A release should not be described only as a “new version”. It should be accompanied by an evaluation of the change, updating the documentation and verifying the effect on the safety requirements and compliance procedure.

The European Commission has dedicated an important part of guidelines published on 27 July 2026 right to the scope, material changes, support periods, reporting and risk assessment.

The guidelines are an important interpretative tool, but they do not replace the text of the Regulation and are not binding.

Conformity assessment will not always require an external body

Another common misconception is that any connected device must be certified by a third-party laboratory.

The CRA distinguishes between products belonging to the predefined category and important or critical products, identified based on their main function.

For many products in the predefined category it will be possible to use an internal control procedure, i.e. a self-assessment by the manufacturer accompanied by the necessary documentation and tests.

The classification should not be inferred from the economic value of the product or from the fact that it is used in a factory. It depends on the main function and the categories defined in the CRA annexes.

The Commission has further clarified the technical descriptions through the Implementing Regulation (EU) 2025/2392.

Incorrect classification can lead to two opposite results: applying an excessively burdensome procedure to a common product or discovering too late that the product requires external evaluation.

For this reason, the framework must be carried out in the initial stages, relating the legal analysis, commercial description and technical function of the product.

Harmonized standards will help, but waiting for them is not a strategy

Technical standards will play an important role because they can transform the general CRA requirements into applicable specifications and offer a presumption of conformity for the covered requirements.

The Commission adopted standardization request M/606, which includes 41 horizontal and product category-specific standards.

The horizontal standards will address common topics such as vulnerability management, secure development and documentation. Vertical standards will be more oriented towards the characteristics of specific product families.

At the time of writing this article, in August 2026, the standardization process is still ongoing. This doesn't mean companies should put projects on hold until every document is published.

Product inventory, version control, risk assessment, dependency tracking, signed updates, and vulnerability management take time regardless of the final standard.

A fragile architecture does not automatically become compliant by applying a checklist a few months before the deadline.

The Commission page dedicated to standardization for the Cyber ​​Resilience Act allows you to follow the evolution of European documents and activities.

Open source does not transfer product responsibility

Linux, FreeRTOS, Zephyr, U-Boot, OpenSSL, Mbed TLS, lwIP, and numerous other open source components are used in commercial products.

The CRA recognizes the value of open source and provides specific treatment for non-commercialized free software and open-source software stewards.

An individual developer who contributes to an open source project does not automatically become responsible for the commercial products into which the code is integrated.

However, when a manufacturer inserts an open source component into its product, it remains responsible for evaluating the impact of that component on the safety of the final product.

Writing “the library is open source” in the documentation is no substitute for due diligence.

The manufacturer needs to know which version they use, how to receive alerts, what configurations are enabled, and how to distribute a fix.

Dependence can also be indirect. An application may depend on a package that itself incorporates other components. A Linux distribution can contain hundreds of packages, not all of which are necessarily used or exposed in the same way.

Reducing the number of unnecessary components decreases the attack surface and makes maintenance more sustainable.

The Commission has published a specific page on the application of the Cyber ​​Resilience Act to open source software.

A realistic case: controller and gateway for an industrial machine

Let's consider an industrial machine composed of an STM32 controller, an operator panel and a Linux gateway connected to the company network.

The controller manages sensors and actuators. The gateway collects data, exposes a web interface and communicates via MQTT with a remote assistance service.

The product works properly and has been sold for several years. The controller firmware can be updated via a service port, while the gateway uses a custom Linux distribution.

However, the company discovers that there is no complete correlation between serial numbers, gateway version and controller version. Some machines were updated in the field without recording the intervention. The version of the TLS library depends on the installed image, and the microcontroller bootloader does not verify the firmware signature.

As long as a problem does not emerge, this situation may appear manageable.

However, suppose that a vulnerability relating to a version of the library present on some gateways is published and actively exploited.

The manufacturer should quickly determine which images contain the library, which machines use those images, whether the configuration is vulnerable, and what mitigation can be applied.

If the investigation requires manually contacting each installer or connecting to machines individually, reporting deadlines become difficult to meet.

A more sustainable technical path could introduce unique release identification, SBOM associated with the build, installation inventory, signed update, version diagnostics and a documented procedure for receiving and evaluating reports.

The new chain would become:

source code → controlled build → SBOM → signed image → tracked installation → monitoring → vulnerability → update → verify

The value of this architecture is not just in compliance. The company also reduces assistance times, better understands its installed fleet and limits the risk of non-reproducible interventions.

A realistic path from August 2026 to December 2027

The CRA cannot be addressed with a single intervention performed a few days before the deadline.

It is more effective to divide the work into phases, distinguishing immediate preparation for reporting from the compliance of products that will be placed on the market after full implementation.

This is a possible technical roadmap, not a set of intermediate regulatory deadlines.

The actual order depends on the number of products, firmware status, source availability, CRA category and the company's business cycle.

A manufacturer with only one recent device can quickly complete the analysis. A company with twenty years of variants, different developers and products still in support must start from a broader mapping.

A CRA technical assessment should not just produce a checklist

A useful pre-test should not be limited to answering “present” or “absent” to a series of checks.

The first outcome should be understanding the product: functions, interfaces, variants, software, components, manufacturing process and how to upgrade.

From this basis it is possible to build a technical risk assessment and identify gaps that have a real impact.

An assessment can highlight, for example, that the product already has encrypted communications but uses the same credential on all units. Or it may detect that the update is signed, but there is no recovery mode in case of interruption.

The final result should link each problem to a priority and a possible intervention.

product and versions → attack surface → dependencies → technical gaps → risk → interventions → tests → documentation

For a legacy device, the first goal may be to make the build playable again. For a new project, this may include defining secure boot, key provisioning, and updating right from the start.

The assessment also allows us to distinguish necessary interventions from those that would be technically interesting but not proportionate to the risk.

This avoids turning the CRA into an oversized and expensive project.

How Silicon Logix can support businesses

Silicon Logix intervenes at the point where Cyber ​​Resilience Act requirements become real issues of firmware, embedded Linux, bootloaders, connectivity and product maintenance.

The activity can start with a technical evaluation of the existing architecture, checking exposed surfaces, update process, software dependencies, release traceability, key protection and the possibility of identifying the installed version.

In the case of legacy firmware, the analysis may include recovery and organization of the sources, reconstruction of the build environment, identification of libraries and definition of a realistic maintenance path.

For new products, Silicon Logix can support the design of embedded firmware, bootloader, signed updates, diagnostics, credential management and recovery mechanisms.

In more complex systems the platform can also be analyzed Embedded Linux based on Yocto or Buildroot, including packages, services, configuration, updates and generation of information necessary for the SBOM.

The goal is not to apply every available technology without distinction.

The project must identify measures proportionate to the product and build technical evidence that can be reused in the manufacturer's documentation and in the subsequent conformity assessment procedure.

Silicon Logix does not replace the legal advisor, notified body or professional responsible for regulatory compliance. However, it can support the company in the engineering part: firmware analysis, architecture definition, implementation of interventions and preparation of the necessary technical information.

Cyber Resilience Act FAQ for Firmware and IoT
Does the CRA apply to any embedded device?

No. Marketing, intended use, direct or indirect connections, product function and any applicable sector regulations must be evaluated. Many connected devices are potentially within the scope, but the presence of a microcontroller is not enough to establish this.

Will all products have to be compliant from 11 September 2026?

No. From 11 September 2026 the reporting obligations of article 14 will apply. The main provisions of the Regulation will become applicable from 11 December 2027.

Should any vulnerabilities in the firmware be reported?

No. The reporting requirement concerns actively exploited vulnerabilities and serious incidents that impact product security. Other vulnerabilities must still be assessed and managed during the support period.

Does the reporting also cover devices sold before 2027?

Yes. The Commission's official indications clarify that the reporting obligations also concern products already made available on the European market before 11 December 2027.

Is secure boot always mandatory?

The Regulation defines security requirements and objectives to be achieved, not a single architecture for each product. Secure boot and firmware signing can be appropriate measures when you need to protect the authenticity and integrity of the software you run.

Does the CRA make an OTA update via cloud mandatory?

Not necessarily. The product must be able to effectively manage vulnerabilities and security updates according to applicable conditions. The solution can be remote, local or based on assistance tools, as long as it is consistent with the risk and the expected life cycle.

Does the SBOM need to be published on the manufacturer's website?

Not in general. It must be prepared and managed according to the requirements of the CRA and applicable documentation. Posting may depend on the product category or specific conditions, but is not a universal requirement for any product.

Does using Linux or open source libraries exempt the manufacturer from liability?

No. The CRA protects normal open source contributors and distinguishes non-commercial activities. The manufacturer that integrates open source components into a commercial product must still evaluate them, document them and manage their vulnerabilities.

Does entrusting the firmware to a consultant transfer CRA obligations?

Normally not. The person who markets the product under his own name or brand generally remains the manufacturer. However, the supplier's technical and contractual responsibilities must be precisely defined.

Is the support period always exactly five years?

No. The Regulation normally establishes a minimum period of five years, except for products whose expected life is shorter. The determination must consider the nature and expected usage time of the product.

Is a notified body always necessary?

No. Many products in the default category will be able to use the manufacturer's internal control. For important and critical products, different procedures and, in certain cases, a third-party evaluation may be required.

Is a microbusiness completely exempt from the CRA?

No. The Regulation provides for proportionality, support tools and some specific provisions for micro and small businesses, but does not introduce a general exemption from the obligations applicable to the product.

Can Silicon Logix issue a CRA certification?

Silicon Logix can support the technical evaluation, design and adaptation of firmware and embedded architectures. The formal conformity procedure, the possible intervention of a notified body and the legal interpretation must be managed by the competent parties.

Conclusion

The Cyber ​​Resilience Act must not be read only as a new European requirement.

For the embedded sector it introduces a deeper change: the software becomes a part of the product that must be known, maintained and supported even after sale.

From September 2026, the manufacturer must be able to react quickly when it becomes aware of an actively exploited vulnerability or a serious incident. From December 2027 it will also have to demonstrate that new products have been designed, developed and maintained according to the applicable requirements.

This requires much more than encrypted communication.

You need identifiable versions, known dependencies, controlled builds, reliable updates, defined responsibilities, diagnostics and a sustainable support period.

The question is no longer just:

“Does the firmware work?”

The question becomes:

“Do we know what's in it, can we fix it, can we demonstrate how it was developed, and will we still be able to support it in a few years?”

Companies that start the journey starting from architecture will be able to transform the CRA into a concrete improvement in product quality.

Those who leave everything to the final documentation will instead risk discovering that the necessary information cannot be reconstructed without modifying firmware, tools and processes.

Official references

1. European Union, Regulation (EU) 2024/2847 – Cyber ​​Resilience Act, official text of the Regulation.
2. European Commission, Cyber ​​Resilience Act, official overview, purposes and application deadlines.
3. European Commission, The Cyber ​​Resilience Act – Summary of the legislative text, summary of scope, obligations, reporting and conformity assessment.
4. European Commission, Cyber ​​Resilience Act – Reporting obligations, deadlines and how notifications work.
5. ENISA, CRA Single Reporting Platform, platform and operational indications for reporting.
6. European Commission, Guidance on the application of the Cyber ​​Resilience Act, guidelines published on 27 July 2026.
7. European Commission, Cyber ​​Resilience Act – Conformity assessment, product categories and evaluation procedures.
8. European Commission, Cyber ​​Resilience Act – Standardisation, harmonized standards and request M/606.
9. European Commission, Cyber ​​Resilience Act – Open source, application of the CRA to free software and open-source software stewards.
10. European Union, Implementing Regulation (EU) 2025/2392, technical descriptions of important and critical product categories.
11. ENISA, SME Cyber ​​Resilience Maturity Assessment Model, a maturity assessment model dedicated to micro, small and medium-sized enterprises.

Is your product's firmware Cyber ​​Resilience Act ready?

Silicon Logix can perform a preliminary technical assessment of firmware, bootloaders, embedded Linux, updates, software dependencies and diagnostics, identifying key gaps with respect to secure lifecycle management.

The activity can start from an existing product or a new project and produce a map of the architecture, versions, components used and priority interventions.

When necessary, the path can continue with secure boot, firmware signing, secure updates, recovery, SBOM, logging and revision of communication interfaces.

Request a technical evaluation of your product

Originally published on Silicon LogiX.