Through the CRA, embedded Linux, systems engineering, and security engineering come together successfully

The Cyber Resilience Act (CRA) comes into force in December 2027. Given the scale of disruption it brings, the time available is fairly tight. At the same time, not all the implementing regulations have yet been finalised. Two things, however, will need to be taken into account in every case:

■  the fundamental requirement for a security-by-design approach
■   the requirement for lifecycle maintenance that ensures the security level, once achieved, is maintained throughout the lifecycle.

Both requirements are already found in existing industrial security standards, to which the CRA is expected to delegate implementation – IEC 62443, for example.

Clause (1) in Annex I of the CRA requires that an appropriate level of cybersecurity be ensured in view of the specific risks involved. Conversely, this means there can be no single, generic way of implementing the CRA that amounts to a checklist to be ticked off.

Even secure boot, used to prevent the execution of malicious software, is not, contrary to how it is sometimes portrayed, strictly required by the CRA – even though it will be part of the security concept in most cases. Whether that is so must be established through a product-specific risk analysis and assessment, which as standard identifies the assets to be protected and the attack vectors, and evaluates the associated risk in order to arrive at suitable mitigations – or indeed at a well-founded decision that no measures need to be taken against a specific risk.

In effect, the CRA calls for a classic systems engineering approach. And this brings us to a particular characteristic of using embedded operating systems in general, and Embedded Linux in particular. Until now, engineering teams in product development have often treated an Embedded Linux system (like other full-featured operating systems) as something of an afterthought.

Not infrequently, it entered product development as part of the hardware platform and was barely adapted – often for the entire product lifecycle. In many cases it was treated as a closed component, essentially firmware belonging to the hardware. As a result, some systems that have already been in the field for years have neither a traceable Software Bill of Materials (SBOM) nor have they received any security- or function-relevant software updates. Manufacturers and economic operators sometimes know little more about the operating system layer than that it is “a Linux system”.

A great deal is changing here at the moment. That said, there is still a wish to source the Embedded Linux system from the hardware manufacturer already fully aligned with CRA requirements, and to delegate lifecycle maintenance to them as well. This is understandable, in that quite a lot can, at first glance, be prepared in a standardised way: for example, a robust SBOM for the Embedded Linux board support package, up-to-date component versions – ideally the latest LTS version – a prepared secure boot mechanism, and a template-style update concept based on standard functions.

However, this does not replace security engineering specific to the particular product and its context of use, nor the adaptation of the prepared mechanisms.

This can be illustrated well using the example of a secure update concept. Signature verification of the software to be installed via the update is an obvious requirement, as is an A/B swap update. However, this does not address who performs the update (role concept), in what environment (secured or freely accessible), over what infrastructure (OTA, USB stick, etc.), or at what phase of the product lifecycle (initial commissioning update, regular update in the field). Nor does it address which assets must be protected against which attack vectors in each case. To respond appropriately to a risk, that risk must first be known and its criticality assessed (see clause (1) in Annex I of the CRA, mentioned above).

The risk analysis mentioned at the outset does not take place at the level of the operating system, but at that of the overall system. The cybersecurity requirements derived from it must be implemented across the overall system. This is another reason why there cannot be a single “correct” way of implementing the CRA for an Embedded Linux system: a security risk can be mitigated at different levels (defence-in-depth concept). For example, the USB interface can be secured simply by disabling it.

As a rule, at least some security requirements cannot be met in isolation at a single “level” of the software stack. The measures involved typically span both the application and operating system layers, for example. Here too, a secure update concept is a good illustration.

Yet the security-by-design approach is by no means only a burden. It can just as well be a benefit. Depending on the product, the application and integration context, and various other “environmental factors”, the risk analysis can also produce a valid argument for why certain measures – regularly cited as a “must have” in the context of the CRA – do not need to be taken. Ultimately, as mentioned at the outset, this also applies to a secure boot mechanism.

For many industrial components and devices that are not used in critical contexts, the end result is a reduced set of mitigations tailored to specific use cases. Investing in a risk analysis, however, pays off not only technically but also economically.

This is especially true with regard to lifecycle maintenance, which is mandatory under the CRA. Given that embedded devices often have product lifetimes well beyond ten years, a reduced and “decluttered” operating system layer significantly lowers total cost of ownership (TCO).

Consistent security engineering fundamentally results in a hardened system: only what is called for by a requirement should be present in the system. This applies to hardware interfaces (such as USB) just as much as to the software stack, and here to the components that make up the operating system layer. With this hardening, the overall system also consists, from a maintenance perspective, of a minimum set of “components” that need to be maintained.

For an Embedded Linux system, deliberately choosing components and their versions, together with the secure configuration of these software packages, significantly reduces maintenance effort. A traceable SBOM is not only a requirement in terms of open source compliance, but also an almost mandatory requirement for the vast majority of companies placing these systems on the market. The SBOM is, moreover, at the heart of open source governance, with the aim of being able to take responsibility for the risks and maintenance of the software used (a requirement that, incidentally, NIS2 also imposes).

If all of this has been taken into account during development, the associated duties of care (also relevant, incidentally, under the updated Product Liability Act) can be met far more efficiently. For an Embedded Linux system, this means that all relevant potential sources of reported security issues must be checked regularly against the SBOM. The primary source is the NVD database, but there are also various other sources that provide good access to newly discovered vulnerabilities.

The process of filtering identified security issues against the SBOM, the system configuration and a number of other parameters can largely be automated. What genuinely calls for in-depth Linux and kernel expertise, above all, is the expert assessment required by the standards, which is in turn highly specific to the particular system and its context of use. This effort decreases in near-linear fashion with the number of software components that actually need to be monitored.

The Cyber Resilience Act makes sound systems and security engineering mandatory at the level of the Embedded Linux system too. At first glance, this may appear to involve considerable effort. Ultimately, however, it ensures that Linux-based systems can be developed, further developed and operated not only more securely, but also more efficiently and more cost-effectively over their lifecycle.