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.

What this presentation is about and why it matters

How do you turn the Cyber Resilience Act into a practical engineering process instead of a heavy compliance exercise? Burkhard Stubert approaches that tension with a lightweight, opinionated walkthrough built around threat modeling, risk assessment, and the technical documentation you need to maintain. He grounds the discussion in embedded product examples, especially a harvester with SSH access, CAN bus interactions, and update paths that make the abstract requirements feel concrete. This session is useful if you need to understand how security decisions, architecture records, and release changes fit together in a way that is workable for real embedded teams.

Who will benefit the most from this presentation

• Embedded software engineers who need to support CRA compliance for connected products
• System or security architects who must document security decisions and tradeoffs
• Engineering managers who want a process that is lighter than traditional security frameworks
• Developers working on agricultural, industrial, or other field-deployed machines with remote access
• Teams that already use user stories or architecture decision records and want to extend them to security

What you need to know

Helpful context for this talk includes:

• Basic familiarity with embedded systems and product lifecycles
• A working understanding of user stories or system interactions
• Some exposure to threat modeling or risk-based thinking, though not required
• Awareness that the Cyber Resilience Act and technical documentation are compliance concerns

Glossary (terms used in this talk)

• Cyber Resilience Act (CRA): A European Union regulation focused on cybersecurity requirements for products with digital elements. It drives manufacturers to assess risks, implement security measures, and keep documentation aligned with product changes.
• Threat modeling: A structured way to identify what can go wrong in a system, what assets or properties are affected, and what mitigations are available. It is often used to prioritize security work before implementation decisions are made.
• Architecture Decision Record (ADR): A short, written record of an architecture or design decision, including context, alternatives, and consequences. ADRs help preserve the reasoning behind choices so they can be reviewed later.
• Security Decision Record (SDR): A decision record focused on security tradeoffs and mitigations, often modeled after an ADR. It captures the context, options considered, the chosen decision, and the consequences for risk.
• Technical documentation: The documented evidence that describes a product, its architecture, and the rationale behind important design and security choices. It is used to support review, maintenance, and regulatory scrutiny.
• MQTT (Message Queuing Telemetry Transport): A lightweight publish-subscribe messaging protocol commonly used to connect devices, automation systems, and scripts. It is often chosen for simple control and status flows across mixed hardware and software.
• Adam Shostack's four-question framework: A lightweight threat-modeling structure that asks what you are working on, what can go wrong, what to do about it, and whether the result is good enough.
• TLS: A cryptographic protocol that provides secure communication over a network by encrypting traffic and authenticating peers. It is widely used to protect application data in transit.

Toolbox (mentioned in this talk)

• Git: A distributed version control system for tracking changes in source code and coordinating collaborative development.
• Linux: A family of open-source operating systems widely used as a host environment for embedded development, servers, and development tools. It provides a broad base of runtime services, libraries, and utilities for building and running software.
• CAN bus: A robust in-vehicle network commonly used for communication between embedded controllers. It supports multi-node messaging over a shared bus and is widely used in industrial and automotive systems.
• SSH: Secure Shell (SSH) is a network protocol and suite of tools for secure remote login and command execution on networked devices. Implementations such as OpenSSH are commonly used on embedded devices and servers.
• CAN XL: CAN XL is the next-generation CAN bus standard that extends bandwidth and adds features including options for built-in encryption and enhanced functionality for automotive and industrial ECUs.

Final thoughts

Practical and process-oriented, this talk gives you a usable way to think about security work without turning it into an abstract policy exercise. The main value is a clearer mental model for connecting product interactions, risk decisions, and documentation into something you can carry into a real project. It will help embedded developers, architects, and compliance-minded teams who need to make security work traceable. The overall spirit is simple: make security decisions explicit, keep them current, and let the system tell its own story.

This overview is AI-generated from the session transcript. Spot an issue? Let us know.