Risk Management for the Cyber Resilience Act

In my previous blog post, I introduced risk-based cybersecurity and how this represents a fundamental shift in how requirements are applied by the Cyber Resilience Act (CRA) compared to previous regulations. With CRA, it becomes the manufacturer’s responsibility to determine an appropriate level of cybersecurity for their product. Furthermore, the CRA requires manufacturers to perform a cybersecurity risk assessment to do this. This fact is clarified in several places of the regulation, e.g., in Annex I “Essential Cybersecurity Requirements”:

Risk-Based Cybersecurity for Products with Digital Elements

In my last post, I highlighted the rising number of daily vulnerability disclosures. Furthermore, for the vulnerabilities that are actually exploited, the Time-to-Exploit is projected to drop to an hour during 2026. This has been a trend for years, which motivates the EU’s Cyber Resilience Act (CRA): we need to act to build our infrastructure on resilient building blocks. In the context of CRA, these building blocks are called Products with Digital Elements and we need to understand the cybersecurity risks they entail. But what are Products with Digital Elements exactly? And what does risk-based cybersecurity mean?

The Cyber Resilience Act: Why It Matters to You

If you have some technical interest, you might have heard about the EU’s Cyber Resilience Act. No matter whether you are an end user, manufacturer, developer, importer, or distributor of a so-called product with digital elements¹ on the EU market, the CRA will impact you. As an increasing share of products we buy are products with digital elements, which include smart door locks, Wi-Fi routers, connected washing machines, mobile apps or computer games, virtually anyone will be impacted. But what does this mean and why should you care?

AI Agents Demystified

I keep thinking each post in this LLM series will be the last one, but the topic refuses to leave my head. I am especially impatient with the news and discussions surrounding generative AI to become more reasonable and less “in 3 to 6 months, AI will be writing 90% of the code software developers were in charge of” as Anthropic’s CEO said in March 2025. This is certainly true for some developers, but from my limited point of view from mostly working with safety-critical products I would definitely say the statement does not reflect the reality today, more than a year later.

llama.cpp for running local LLMs on Intel GPUs

As mentioned in my previous post, vLLM appears to be the official way forward for running LLMs on Intel GPUs. As described there, the supported models have good performance but the vLLM version lags behind and it can go months until a newly released model is supported. This can be a bit frustrating, when for example everyone is talking about GLM-4.7-Flash these days but you are not able to join in on the fun. Do not despair, llama.cpp comes to the rescue!

Running Local LLMs on Intel GPUs

I try to have a pragmatic view on Large Language Models (LLMs), which I summarized in a previous post. In any case, I am very much interested in the technology and, long story short, bought an Intel Arc Pro B60 GPU for my home server. It is “an extremely well-balanced workstation card that performs well in classic CAD environments as well as in modern AI and content creation scenarios” as Igor Wallossek puts it in his very detailed and thorough review. For currently around 800€, it is expensive but one of the cheapest graphic cards with 24 GB of VRAM, which is important for generative AI applications. I have different applications in mind like web desktops that can handle, e.g., video editing and gaming, but testing to run LLMs fully local was the first thing on my list.

NIS2 Technical Implementation: A Practical Guide to the Operational Layer

When I started writing my last post on the NIS2 Governance Layer, I originally gathered cybersecurity-relevant abbreviations like SIEM, XDR and IDS which belong to the operational layer. Quickly they became too many and I needed to split the posts.

So this post is a concise top-down guide on important operational concepts that you can encounter when implementing the “Network and Information Systems Directive 2” (Directive (EU) 2022/2555), or short NIS2, in an organisation. I had the idea when reading ENISA’s NIS2 Technical Implementation Guidance. This post (or series) does not provide a complete picture on NIS2 but can be seen as a cheat sheet when reading ENISA’s guidance.

A Sober Look at LLMs in Late 2025

The year of 2025 is getting close to its end. It has been almost exactly 3 years since ChatGPT was released, the application that made large language model (LLM) a term that is mentioned everywhere and in any context. Access to generative AI has become a commodity, or even pushed on users in many products.

But what does an LLM actually do and what is performed by the application around it? Where do we stand in the battle of private and open models, and what does this mean? Do I even need generative AI and do LLMs improve my productivity no matter what I am working on?

NIS2 Technical Implementation: A Practical Guide to the Governance Layer

Whether in business, technology or everyday life, abbreviations are ubiquitous. However, I personally think they are overused, spelled out too rarely, and inconsistent even within a given domain. Admittedly, abbreviations have their use cases like keeping complex tables concise. When reading ENISA’s NIS2 Technical Implementation Guidance, however, I became convinced that it might make sense to create an inventory of the most important abbreviations within the given security context.

To improve my own understanding, and perhaps yours, I will not only list the abbreviations but provide a bit of context, and explain how the concepts relate.

What is Safety Of The Intended Functionality (SOTIF)?

When working with embedded software or hardware, you might have come in contact with functional safety. Functional safety deals with getting the risk of malfunctioning behaviour of your systems to a level that you can accept. In essence, malfunctioning behaviour means that your system does not work as intended, and when this happens in a safety-critical system like a car, it can threaten lifes. Unfortunately, getting the risk of malfunctioning behaviour to acceptable levels is tough. This is why international standards govern how safety-critical systems are developed. Instead of vibe coding driver assistance systems, the ISO 26262 standard series “Road vehicles – Functional safety” describes how road vehicles (say car, bus, truck, …) and their subsystems are expected to be built. On over 800 pages in 12 parts, ISO 26262 details expected processes that car manufacturers and suppliers are required to have in place like risk assessments, traceability in their requirements or verification and validation activities.