Für Dr. Matthias Meyer, Bereichsleiter Softwaretechnik und IT-Sicherheit am Fraunhofer IEM, drängt die Zeit: „Die Übergangsfrist, bis der CRA 2027 voll erfüllt werden muss ist kurz. Unternehmen müssen sich in vielen Bereichen neu aufstellen – angefangen von der Durchführung von Security-Risikoanalysen über kurzfristige Meldepflichten bei Bekanntwerden von Schwachstellen bis hin zu kostenfreien Security-Updates während der erwarteten Lebensdauer des Produkts. Und Aufschieben gilt nicht, denn bei Nichteinhaltung des CRA drohen Strafzahlungen in Millionenhöhe.“
Das Forschungsinstitut empfiehlt Unternehmen jetzt drei Maßnahmen zu ergreifen, um den Weg zur CRA-konformen Produktentwicklung zu beginnen. „Die schnelle Reaktion auf das Bekanntwerden von Schwachstellen und systematische Risikoanalysen sind essenzielle Maßnahmen zur Erfüllung der CRA-Anforderungen: Unternehmen, die diese Maßnahmen jetzt angehen, sind schon gut unterwegs. Zusätzlich bringt eine Ist-Stands-Analyse im Hinblick auf die Produkte und Prozesse Klarheit für das weitere Vorgehen“, betont Dr. Meyer. Git, CI/CD-Pipelines, automatisierte Builds, Code-Reviews im Team: in der Softwareentwicklung seit Jahren Standard, in der SPS-Programmierung bisher kaum umsetzbar. ‣ weiterlesen
SPS-Entwicklung trifft DevOps: Wie CODESYS 4 IT-Methoden in die Automatisierung bringt
Aufbau eines Schnelleinsatzteams für den Ernstfall
Werden Hersteller gewahr, dass Schwachstellen in ihren Produkten ausgenutzt werden, müssen sie künftig die Agentur der Europäischen Union für Cybersicherheit (ENISA) umgehend informieren: Innerhalb von 24 Stunden müssen sie eine erste Warnung geben und innerhalb von 72 Stunden weitere Details zur Art der Schwachstelle, möglichen Gegenmaßnahmen und mehr liefern. Abgesehen davon müssen sie jederzeit ansprechbar sein für Personen, die Sicherheitslücken melden möchten, und im Blick behalten, ob Schwachstellen in einem zugelieferten Softwarebestandteil bekannt werden. Dies gehört zu den Aufgaben eines Product Security Incident Response Teams (PSIRT): Hersteller, die noch kein PSIRT etabliert haben, sollten sich dringend damit befassen, denn die genannten Pflichten sind bereits ab August 2026 zu erfüllen, und zwar für alle Produkte auf dem Markt, auch solche, die lange vor Inkrafttreten des CRA lanciert wurden.
Regelmäßige Bedrohungs- und Risikoanalysen
Im Kern verlangt der CRA, dass Hersteller ihre Produkte regelmäßig auf Sicherheitsrisiken analysieren und an diese Risiken angepasste Sicherheitsmaßnahmen integrieren. Unternehmen müssen das Durchführen von Bedrohungs- und Risikoanalysen für alle Produkte fest in den Entwicklungsprozess integrieren: So identifizieren sie systematisch Bedrohungen, bewerten das jeweilige Sicherheitsrisiko und leiten informiert und gezielt Schutz- und Gegenmaßnahmen ab. Das Sicherheitsniveau der Software kann somit kontinuierlich und vor allem angemessen erhöht werden. Entwickler:innen erlangen ein neues Sicherheitsbewusstsein und teure, aber eigentlich unnötige Maßnahmen werden sogar vermieden. Maschinen kommunizieren, reagieren und steuern Prozesse. Nur ihr Licht wird oft noch als passive Komponente behandelt. Dabei zeigen SPS-Anbindung, IO-Link und Signalfunktionen: Intelligentes Licht kann längst mehr als leuchten. ‣ weiterlesen
Wie intelligent ist Licht?
Überblick durch Ist-Stand-Analyse
Die ersten beiden Maßnahmen sind wichtig, werden aber nicht ausreichen: Unternehmen müssen sich ein Bild davon machen, welche Anforderungen des CRA sie erfüllen, und zwar sowohl bezüglich ihrer Prozesse im Produktlebenszyklus als auch der konkreten Produkte. Auch wenn noch keine harmonisierten Normen zum CRA vorliegen, ist einhellige Expertenmeinung, dass der bereits existierende Standard für industrielle Cybersicherheit IEC 62443 eine sehr gute Orientierung gibt. Unternehmen müssen also nicht warten, sondern können schon jetzt Ist-Stands-Analysen für ihre Prozesse und Produkte durchführen und Maßnahmen ableiten und somit wertvolle Zeit bei der Umsetzung des CRA gewinnen.
