Modular Embedded Architectures under the CRA: What Computer-on-Modules Can Do
A Computer-on-Module approach can reduce the effort involved in platform changes by separating the computing unit from the application-specific carrier board design. Under suitable conditions, the carrier board and parts of the system architecture can therefore be reused across several compatible module generations.
This does not make a Computer-on-Module automatically CRA-compliant. However, a modular architecture can help structure documentation, update processes and lifecycle management more clearly. A modular architecture does not change the manufacturer’s responsibility for the conformity of the end product placed on the market under its own name or trademark.
This article is intended as a technical orientation only. It does not constitute legal advice or a complete technical or regulatory conformity assessment. The suitability of a specific architecture and its CRA implications must be assessed for the individual product and use case.
We covered the key CRA deadlines and requirements in the first article of this series. Part 2 provides a structured CRA readiness self-assessment. This article looks at the topic from a system architecture perspective.
How does a Computer-on-Module separate the computing unit from the system design?
A Computer-on-Module, or COM, integrates core computing functions such as the processor, memory and basic interfaces on a compact module. With standardised form factors such as COM Express or COM-HPC, the module connects to an application-specific carrier board through defined interfaces.
This allows application-specific functions on the carrier board and parts of the system design to be separated from the underlying processor platform. As a result, moving to a newer compatible module often affects a smaller part of the hardware design than with a fully customised board.
The application does not become completely independent, however. Operating system integration, BIOS or firmware, drivers, power consumption, cooling and security functions must still be checked for compatibility and for their impact on the overall system whenever the module is changed.
With a fully customised board, the processor, memory and core I/O functions are integrated directly into the board design. A platform change therefore often affects a larger part of the hardware development and system validation. Unchanged software and documentation components may still be reusable, but the migration effort is often higher.
Where can a COM help structure documentation and reassessment?
Depending on the supplier and product, module-level documentation may include:
- SBOM data
- security advisories
- information on BIOS, firmware and the Board Support Package (BSP)
- details of available security features
- support and lifecycle information
This information can feed into the technical documentation and cybersecurity risk assessment of the end product. It does not replace the assessment of the overall system.
With a compatible module change, parts of the existing technical documentation may remain applicable where the underlying design and relevant assumptions have not changed. The documentation should nevertheless be reviewed and updated wherever the module change affects the product or its cybersecurity assessment.
The impact of the new module on the attack surface, drivers, firmware, update process, power consumption, thermal design and interfaces must still be assessed.
For changes to products that have already been placed on the market, it must also be assessed whether they constitute a “substantial modification” within the meaning of Article 3(30) CRA.
The main advantage of a modular architecture is the clearer separation of technical layers. This can make it easier to identify which parts remain unchanged and which parts need to be reassessed.
How can a common platform support updates and lifecycle management?
If several end products use the same module and software base, a common update infrastructure can be established. Processes for signing, distribution, versioning and recovery do not necessarily have to be developed completely from scratch for every product line.
Get Aaronn Electronic GmbH’s stories in your inbox
Join Medium for free to get updates from this writer.
Product-specific testing, approvals and rollout rules are still required. Different operating system versions, configurations or deployment environments may also require separate validation even when the hardware base is shared.
A common platform can also make it easier to identify affected product variants when a new vulnerability is discovered and to coordinate corrective measures across related products. The statutory reporting obligations remain unchanged.
A COM can also offer advantages for lifecycle management. If a processor, firmware or operating system platform is discontinued or no longer receives security updates during the planned support period, migrating to a newer, still-supported module can be one possible strategy.
Standardised module and carrier board interfaces can create the basis for reusing a carrier board across several compatible module generations. Whether this is possible in a specific project depends, among other things, on pinout, power consumption, cooling, firmware, drivers and the required I/Os.
Which security concepts can be standardised?
Security concepts such as Secure Boot, Hardware Root of Trust or signed updates can build on a common system architecture. Parts of the update and key management processes can therefore be standardised across several product variants.
When changing a module, however, it is necessary to check which parts of the chain of trust actually remain unchanged. Secure Boot, for example, involves not only the carrier board, but also the processor platform, BIOS or UEFI, bootloader, key management and operating system.
A security architecture defined early in the development process can make migration easier. It does not replace renewed validation of the components that have changed.
Who is responsible for which CRA obligations?
A COM approach can make the technical and organisational allocation of tasks clearer.
The module supplier may provide updates and information for module-specific components such as BIOS, firmware or the Board Support Package. The manufacturer of the end product must assess the relevant information, incorporate it into the system design where appropriate and reflect it in its own technical documentation.
A system integrator can provide technical support in this process.
The manufacturer remains responsible for the conformity of the end product placed on the market under its own name or trademark. Selecting a module does not transfer this responsibility to the supplier.
Technical compatibility is only one factor in module selection. Supplier information on SBOM data, security advisories, support periods and updates throughout the planned product lifecycle is equally relevant.
How does the CRA influence platform strategy?
For a given end product, choosing a COM, SBC or custom design does not in itself change the CRA’s fundamental cybersecurity requirements. The differences lie mainly in technical implementation, supplier dependencies and the effort required for maintenance and future platform migration.
A COM can be a good fit when a custom carrier board is required and the computing unit should remain replaceable later on. An SBC provides a more highly integrated standard platform, while a custom design offers the greatest degree of freedom but usually requires greater upfront development and validation effort.
The key factors in the decision therefore remain product lifetime, volume, degree of customisation, available security information and the effort required for future platform changes.
Aaronn at the Elektronik Solution Day
At the Elektronik Solution Day in September 2026, Managing Director Florian Haidn, together with our technology partner congatec, will show what role modular system architectures can play in update capability, platform maintenance and long-term lifecycle management in embedded systems. Planning to attend? With the discount code ESD26DC20, you receive 20% off the conference ticket.
Register here with the discount already applied.
