Risk Assessment: The Core of CRA Compliance

In 2026, many embedded devices still have the following security vulnerabilities:

• The support staff can log in via ssh to all devices as root with the same global password, which is easy to guess.
• All applications run with root privileges.
• Major components like the Linux kernel, U-Boot, networking, multimedia, GUI and system libraries reached end of support some time ago.
• Users install updates from a USB drive on the device. As long as the filename of the update follows the right pattern, the update is installed in the root file system.
• Sensitive customer data, machine data and access tokens for cloud services are stored unencrypted on the device.
• When several devices communicate over CAN bus, each device can flood the bus with messages and knock out the other devices.
• When the terminal application hangs or crashes, users can’t continue with their work.

If your device has any of the above or similar vulnerabilities, it violates one or more essential product requirements of Annex I.I of the EU Cyber Resilience Act (CRA). Hence, you - the manufacturer - face heavy penalties and a sales ban.

Your out-of-jail card is to perform a risk assessment of the essential product requirements (Annex I.I). I’ll walk you through a risk assessment using the driver terminal of a harvester as an example.

• Guided by a data-flow diagram of the terminal’s ecosystem, we’ll identify the vulnerabilities. Any vulnerability violates one or more of the essential product requirements.
• We evaluate the risk of each vulnerability with a risk matrix. The risk is a combination of the damage caused by exploiting the vulnerability and the likelihood of the vulnerability being exploited.
• We sort the vulnerabilities by their risk. We mitigate or avoid the risk, if it is too high for us, and accept it, otherwise.
• For vulnerabilities with unacceptably high risk, we devise other mitigation options and re-evaluate the risk for each option. We can choose any option that brings the risk down to an acceptable level - with reasonable effort.
• We update the risk assessment for every new feature. We write tests to detect vulnerabilities early.

I’ll also show you how to document the risk assessment with architecture decision records (ADRs). You can just add the ADRs as-is to the Technical Documentation required by the CRA (Annex VII).

The risk assessment gives you a plan, which security measures to implement for your device. Implementing that plan takes a lot more time. So, you better act now. The closer 11 December 2027 (the date when the CRA fully applies) comes the harder it will be to find qualified and affordable help.

Go to Session

Extracting Microservices from a Ports-and-Adapters Architecture

A typical application controlling a machine interfaces with users, with the actuators and sensors of the machine, with cameras, with the IoT cloud, with local and remote databases, with a fleet management server, and with other system parts. The application core, which implements the business rules, must not know which technology components are used to communicate with the user, machine, cloud, or database. Well-defined ports (interfaces) hide the implementation of the adapters (components) from the core. This is the ports-and-adapters architecture in a nutshell.

The ports-and-adapters architecture leads to loosely coupled and cohesive components with well-defined interfaces. This sounds a lot like a microservice architecture, doesn’t it? It does, indeed—with one difference. Microservices run in their own processes (often on different computers) and talk to each other over a lightweight protocol. In contrast, the ports-and-adapters architecture is mostly implemented in a monolithic application running in a single process. The core and adapters communicate through function calls.

We can find good reasons to extract adapters from the monolithic application as services. The application keeps a proxy for the extracted service. The proxy and the service implement the same port. The proxy and service are very much like the two USB ports connected by a USB cable. Here are two examples.

These days, the main HMI application should have a component performing OTA updates of the embedded Linux system. OTA updates require root privileges. For security reasons, user applications should not have root privileges. If we extract an update service from the application, the application can run with user privileges and the service with root privileges. Only a properly authenticated application may use the service.

HMIs of agricultural and construction machines provide functionality for normal operation by the driver and for diagnosis by a support technician. When we split the monolith into two applications accordingly, we face a resource-sharing problem. If one application reads a message from the CAN bus, the other application will never see this message. The solution is the introduction of a service doing all the CAN message processing and replicating the messages for all the interested applications.

As long as it makes sense, we can transform the adapters from our applications into services. As the services will most likely implement the ports-and-adapters architecture, we may be able to identify even more services. The operating-system and hardware-abstraction layers are fertile ground for more services. The applications and services use inter-process communication like DBus or gRPC to talk to each other.

We have transformed a few monolithic applications into several smaller applications and services talking to each other over a lightweight protocol. In short, we end up with a microservice architecture, where each microservice (including applications) implements the ports-and-adapters architecture.

Go to Session

The Ports-and-Adapters Architecture for Embedded HMIs

The ports-and-adapters architecture (a.k.a. hexagonal architecture) is based on the same idea as USB ports and adapters. USB adapters enable PCs to communicate with embedded devices over CAN, RS232, (W)LAN or BLE. The USB port hides from the PC which technology is used for the communication - as a good interface should do. Different companies can manufacture the adapters as long as they comply with the USB interface.

A typical machine HMI has a UI, machine, accounting and monitoring port. These ports are the interface between the application core implementing the business rules and the adapters connecting the HMI to the user, the cloud, databases and the rest of the machine. Ports lift the abstraction level from concrete technologies like SQL, J1939, Qt and MQTT to the business domain.

The machine port, for example, hides from the core whether the machine adapter uses the J1939 or OpenCAN protocol over CAN bus or Ethernet. If the manufacturer decides in 5 years to switch from CAN to Ethernet, it can do so without impacting the core and the other adapters. The architecture becomes loosely coupled, cohesive and easy to extend.

Each port has at least two adapters: one for production and one for testing. Test adapters are either test cases or mocks. As the core, they are technology agnostic and I/O-free. We can write I/O-free tests for the core. Such tests are ideally suited for TDD or BDD.

Conway’s law tells us that the software architecture mirrors the organisation structure. So, it is not surprising that the architecture more often than not resembles a big ball of mud. We can avoid this by inverting Conway’s law. We map the core and adapters to separate teams. The ports become the team APIs. Some teams can be merged - especially if too small. Other teams should not be merged.

The ports-and-adapters architecture has gained a lot of traction in enterprise software, but is little known in the embedded world. This is unfortunate, because it is an excellent architecture not only for embedded HMIs but also for firmware.

Go to Session

Live Q&A - The Ports-and-Adapters Architecture for Embedded HMIs

Live Q&A with Burkhard Stubert for the talk titled The Ports-and-Adapters Architecture for Embedded HMIs

Go to Session