The EU Cyber Resilience Act
How congatec helps customers build CRA-compliant products
aReady. building blocks and CRA compliance
The EU Cyber Resilience Act
The objective of the EU Cyber Resilience Act (CRA) is to ensure that all products with digital elements feature increased cybersecurity by design and remain secure throughout their entire lifecycle. Therefore, it introduces mandatory cybersecurity requirements for those products placed on the EU market. Full CRA compliance including CE marking for cybersecurity is mandatory from December 11th 2027.
This means, compliance is not an option, it is a must and affects hardware vendors, software publishers, and system integrators alike who want to sell their products on the European market, whether they originate from EMEA, Americas or Asia.
What does the CRA mean for embedded devices?
Key requirements at a glance
| CRA Requirement | Description | What this could mean in practice |
|---|---|---|
| Secure-by-design | Security must be built into products from the ground up, not added as an afterthought. | The data stored or transmitted with the product is encrypted and the attack surface is as small as possible to keep confidentiality & integrity. A TPM or comparable measures should be integrated. |
| Secure by Default | Products must ship with secure default configurations that minimize attack surfaces. | Debug ports or a Telnet connection should be disabled by default. Weak default logins and passwords (admin/admin) must be avoided. |
| Risk Assessment | A documented cybersecurity risk assessment must be performed before market placement. | Manufacturers have to test their products themselves or through a third party for compliance. For the majority of products manufacturers will be able to assess by themselves according to defined test specifications. |
| SBOM (Software Bill of Materials) | A machine-readable inventory of all software components and dependencies, required to trace and report vulnerabilities. | If a critical software vulnerability is disclosed for example, in a Linux kernel component or an open-source library this helps in checking if the product is affected. The SBOM is mandatory, but it does not have to be published. |
| Vulnerability Handling & Reporting | Security vulnerabilities and exploits must be reported, addressed and disclosed throughout the product lifecycle. | Exploited vulnerabilities and severe incidents have to be reported to ENISA and the relevant CSIRT, with an early warning within 24 hours. An internal process and contact point is to be defined. |
| Security Updates | The vendor has to provide timely security updates, ideally via over-the-air (OTA) delivery where applicable. | Updates have to be executed within a given time frame. OTA is ideal as a technician does not have to physically visit every machine on the factory floor with a USB stick when a fix is needed — updates can be rolled out remotely and verified as authentic before they are applied. This saves time and cost. |
The house of cyber security: based on aReady. building blocks
Cybersecurity and CRA compliance are always teamwork, leading to shared responsibilities. At congatec, we develop our hardware and software solutions developed in compliance with IEC 62443-4-2 and offer many more services - so customers can build their applications on an already secure foundation.
To make shared responsibility tangible, congatec uses the concept of the House of Cyber Security. It is not a single product or a checklist. It is a framework that illustrates how technical building blocks and organizational processes fit together.
At the top of the house sits the customer application. This is where cybersecurity requirements ultimately become visible, for example secure communication, protected data, and reliable operation in the field. The roof represents the outcome that users and operators experience. It depends entirely on the structure beneath it.
The house is supported by three pillars that span all layers of an embedded system.
- Confidentiality ensures that data is accessible only to authorized parties. This is supported by isolation mechanisms, secure storage, and key management.
- Integrity ensures that software and firmware remain authentic and untampered. This relies on Roots of Trust, secure boot mechanisms, and signed updates.
- Availability ensures that systems continue to operate reliably, even in demanding industrial environments, supported by robust hardware design and monitoring mechanisms.
No single layer can uphold these pillars on its own. They emerge only when hardware, firmware, software, and applications work together.
Want to learn more about Security of Embedded Systems and the House of Cybersecurity?
Read Blog
Three dangerous misconceptions with the CRA
The CRA only applies to networked or IoT connected devices
This is incorrect. The CRA applies to all products with digital elements (PDEs). Devices which are not connected to the IoT or to a local network are concerned too, as long as they feature a direct or indirect logical or physical data connection. This means, that systems with the potential of an external connection to a local network, other embedded platforms or digital systems or even a not connected maintenance or service interface are concerned.
The product can continue to be sold as long as it remains unchanged.
This stems from a misunderstanding of the terms “placed on the market” and “making available on the market”. For example, if a device is delivered to a distributor before December 11, 2027, that specific unit has been placed on the market in time. If the distributor sells it in 2028, this is merely making it available on the market. However, manufacturing a new unit of the same product line in 2028 and supplying it for the first time constitutes a new placement on the market. Even if the system was developed before December 11th 2027.
The product only needs to be supported while it remains on the roadmap.
Manufacturers are required to address vulnerabilities and provide security updates over a defined support period. This period must correspond to the expected product lifetime and is at least five years unless the expected usage period is shorter. Crucially, this obligation applies to each individual product placed on the market, not to product families, development generations, or marketing roadmaps. As an example: A PDE has been produced in 2028, was kept in the vendor’s stock until 2033 and is then placed on the market by the vendor. This means, it has to be supported at least until 2038.
congatec dedicated CRA support
congatec`s aReady. portfolio, application-ready hardware and software building blocks, is designed for secure environments and developed under a secure development process certified to IEC 62443-4-1. This standard's requirements substantially overlap with the CRA's obligations around Secure-by-design, vulnerability handling, and documentation.
- With aReady.COM hardware and software building blocks congatec provides a faster, easier way for OEMs to achieve CRA compliance in their end products as many CRA requirements are already implemented.
- Pairing modular hardware with structured software governance, security monitoring, and lifecycle management, reduces compliance complexity from day one without the need to build every security mechanism from scratch.
congatec CRA compliance features at a glance
| CRA Requirement | congatec Solution | Key Benefit |
|---|---|---|
| Secure-by-design / Default | BIOS Modification & Customization Services | Platform hardened to customer-specific security policy from day one |
| Secure hardware foundation | aReady.COM Computer-on-Modules | Off the Shelf or customized designs based on standardized COMs provide a long-lifecycle base with integrated security features |
| Root of Trust | COM Modules + BIOS Services | Hardware- and Software based trust at hardware and BIOS level, based on risk assessment |
| System Isolation | conga-zones hypervisor | Hardware-enforced separation of security domains on one platform |
Companies leveraging congatec's building blocks are positioning themselves early and efficiently to successfully manage the requirements of the CRA and comparable regulatory frameworks.
Secure-by-design and root of trust
The IEC 62443-4-1 certified scope includes congatec's application-ready building blocks and its aReady.COM technology stacks, which combine computer-on-modules with
- Licensed operating systems - including Ubuntu Pro designed according to IEC 62443-4-1 and the IEC 62443-4-2 certified ctrlX OS
- IoT connectivity conga-connect from aReady.IOT for security updates and health monitoring.
- Real-time capable hypervisor conga-zones and secure bootloader from aReady.VT, both IEC 62443-4-2 certified for confidentiality and integrity.
Our IEC 62443-4-1 certified design processes cover secure coding guidelines, verification and validation procedures, and structured management of vulnerabilities, patches, and obsolescence.
Secure-by-design building blocks
Secure hardware foundation
congatec aReady.COM Computer-on-Modules
All congatec cybersecurity services and solutions are built on our application-ready Computer-on-Modules (COMs). These are compact, application-ready processing units that integrate CPU, memory, storage, and security hardware on a single board.
Key advantages for CRA compliance:
- Module, security architecture, documentation, and update infrastructure has already been engineered in accordance to IEC 62443-4-1
- Standardized hardware enables re-use to simplify security certification and documentation
- Long-term availability ensures security updates can be delivered for a longer period, extending the lifecycle of the products
- Easy upgrades by a simple module exchange significantly optimizes the lifecycle, certification efforts and Return on Investment
- Integrated security features (TPM, Secure Boot support, silicon integrated security technologies) reduce the effort required to establish a root of trust
- Scalable across performance classes - from low-power edge devices to high-performance industrial controllers - reduces certification efforts by re-use
congatec BIOS Modification & Customization services
The foundation of a CRA-compliant product is a hardened firmware baseline. congatec offers tailored BIOS modification and customization services that allow customers to:
- Disable unused interfaces and peripherals to reduce the hardware attack surface
- Enforce Secure Boot to ensure only signed, trusted firmware and OS images are loaded
- Lock BIOS settings to prevent unauthorized configuration changes in the field
- Apply customer-specific security policies aligned with their individual risk assessment
- Configure the platform to a “secure by default” state at production time
These services are adapted to the specific application context and risk profile of each customer — ensuring that security measures are proportional and effective.
For more details visit: Security Page ↗
System Consolidation & Isolation: conga-zones Hypervisor
Modern embedded systems are very powerful and capable of consolidating multiple applications onto a single hardware platform. With the IEC 62443-4-2 certified congatec hypervisor conga-zones manufacturers can replace several systems by one module. The CRA requires that security domains are properly isolated to prevent a breach in one subsystem from compromising others.
In detail, congatec’s conga-zones hypervisor enables
- to run multiple operating systems and application domains on a single COM module reducing the system count from many to one.
- to strictly isolate security domains - e.g., separating a real-time control partition from a connected HMI partition.
- to efficiently leverage the complete performance of multi-core architectures of modern CPUs to run workloads in parallel without interference.
- to support mixed-criticality designs, keeping certified or safety-relevant code isolated from general-purpose software.
This approach reduces hardware complexity and cost while maintaining the security boundaries required by the CRA and related standards (e.g., IEC 62443).
More details about our building block aReady.VT ↗
A deeper dive into the Cyber Resilience Act (CRA)
The Regulation (EU) 2024/2847, known as the Cyber Resilience Act (CRA), is a horizontal regulatory framework of the European Union (EU), which applies to hardware and software products (“products with digital elements”) that are made available on the Union market. Such products include both final products and components placed separately on the market.
It aims to set the conditions for the development of secure hardware and software in the Union, in order to strengthen the EU approach to cybersecurity and improve the functioning of the internal market. It also empowers users to take cybersecurity into account when buying and using such products by ensuring that adequate information is made available to them.
The content of the CRA
| CRA Reference | CRA Obligation (simplified) | congatec provided solution |
|---|---|---|
| Annex I, Part I (1–2) | Products must be secure-by-design & default, free of known vulnerabilities, with secure configuration | Secure-by-design modules with TPM 2.0, Hardware Root of Trust implementation, ruggedized hardware, secure boot loader |
| Annex I, Part I (c) | Ensure vulnerabilities can be fixed via security updates | Regular BIOS/firmware updates, LTS kernel support, coordinated security advisories |
| Annex I, Part II (1–8) | Vulnerability handling | Vulnerability disclosure policy, CVE tracking, customer-facing contact, secure update distribution, public advisories |
| Article 13 & Annex I | Risk assessment must guide design | Threat modeling, structured risk & threat analyse (IEC 62443-4-1) |
| Article 31 & Annex VII | Maintain and update technical documentation | Ready-to-use documentation packages (risk assessment, update policies) |
| Article 13(8); Recital 13 | Define & respect a support period | Long-term roadmaps, guaranteed support periods, patch availability across lifecycle |
Useful links
Access the Cyber Resilience Act in all European Union's official languages
Find more information about the Cyber Resilience Act implementation here
A comprehensive FAQ by the European Union on CRA implementation can be found here
