Ich leite bei TRIOVEGA die Produktentwicklung für OT-Security. Wir bauen Produkte, mit denen Betreiber ihre Maschinen absichern. Außerdem helfe ich Maschinenbauern und Softwareunternehmen, ihre eigenen Produkte so zu bauen, dass sie sicher und aktualisierbar bleiben, solange sie im Einsatz sind.
So lange baue ich schon vernetzte Geräte, von Linux-Gateways bis zur OT-Security.
Nach dieser Norm hat der TÜV den sicheren Entwicklungsprozess zertifiziert, den ich verantworte.
Ich bin Miterfinder eines sicheren OT-Gateways (EU, USA, Israel).
Ich bin Mitglied im Expertenkreis „Security Solutions for Industry“.
Was braucht man, um sichere Produkte zu entwickeln?
Produkte müssen sich am Nutzer ausrichten. So auch ihre Security, sonst wird sie umgangen. Klare Defense Lines in der Architektur und passende Lizenzmodelle helfen, Security auch langfristig aufrechtzuerhalten, ohne dass Kostenfallen entstehen.
Ein guter sicherer Entwicklungsprozess muss sich auf die Entwickler fokussieren und effizient bleiben – ansonsten akzeptieren diese ihn nicht und arbeiten dagegen. Zudem muss er im Audit bestehen. Unserer ist vom TÜV nach IEC 62443-4-1 ML-2 zertifiziert.
Sichere Produkte entstehen in kleinen, autonomen Teams mit klarer Verantwortung. Sie müssen verstehen, warum es eine Anforderung gibt – ansonsten bauen sie am Nutzer und an der Security vorbei. Entscheidend ist dabei, Innovation zu leben und Fehler offen ansprechen zu können.
Gute Security kann man nur gemeinsam bauen und nur in engem Austausch mit den Nutzern. Es braucht Partnerschaften über Firmengrenzen hinweg. Deshalb bringe ich mich im VDMA und in der CISO Alliance ein und teile Werkzeuge als Open Source.
Der Cyber Resilience Act (CRA) macht Security zur Pflicht für jedes Produkt mit digitalen Elementen, das in der EU verkauft wird. Für Maschinen, die viele Jahre laufen, ändert das nicht nur die Dokumentation, sondern auch die Architektur.
Jedes Projekt begann mit einem Problem, auf das ich immer wieder gestoßen bin. Alle Projekte →
Geräte im Feld brauchen zehn Jahre und länger Security-Updates. Jedes Update kann einen Ausfall verursachen. Deshalb werden Updates (gerade in der OT) gern aufgeschoben. CuOS macht sie systematisch und wiederholbar.
Das ganze Betriebssystem ist ein Container-Image. Ein Update tauscht es auf einmal aus und macht von selbst ein Rollback, wenn es zu Updateproblemen kommt. CuOS entstand 2025. Seit Anfang 2026 baut ein kommerzielles Produkt darauf auf.
KI-Agenten arbeiten am besten mit Dateien, die sie direkt lesen und schreiben können. Teams brauchen dafür eine gute Oberfläche. BrainDesk bringt beide in denselben Markdown-Dateien zusammen.
BrainDesk hält eine Wissensbasis in reinen Markdown-Dateien. Menschen und KI-Agenten lesen sie gleichermaßen.
Details →Bald
Energiemanagement braucht viele Daten und Steuerungsmöglichkeiten. Genau die können Angreifer ausnutzen. Deshalb macht osiota Daten vor Ort zugänglich und hält sie möglichst lokal.
osiota ist eine JavaScript-Plattform für verteilte IoT-Anwendungen und wird bis heute gepflegt.
Hier schreibe ich auf, was ich beim Bau sicherer Produkte lerne. Ich schreibe für die Menschen, die entscheiden. Alle Beiträge →
Der Artikel erklärt, was die Normenreihe IEC 62443 regelt und was sie für NIS-2 und CRA leistet und was nicht. Außerdem zeigt er, was ein zertifizierter Entwicklungsprozess für Kunden bedeutet.
Security wirkt als Prozess über den ganzen Entwicklungszyklus. Der Bericht zeigt, wie der Einstieg in die CRA-Konformität über eine Gap-Analyse entlang IEC 62443-4-1 gelingt.
An der TU Braunschweig habe ich Elektrotechnik studiert, acht Jahre zu verteiltem Energiemanagement und IoT geforscht und promoviert. Seit 2019 baue ich bei TRIOVEGA OT-Security-Produkte, die in den Produktionen unserer Kunden laufen – und regelmäßig automatisiert geupdatet werden.
Du baust Maschinen oder Software für die Industrie und fragst dich, was der CRA für deine Produktlinie bedeutet? Schreib mir oder vernetz dich mit mir. Ich tausche mich gern aus.