Das Unternehmen ABCDE ist Hersteller eines Produkts/einer Anlage mit digitalen Elementen. Das Unternehmen greift jedoch nur auf CRA-konforme Komponenten namhafter Hersteller zurück. Die Steuerung (SPS) stellt einen Teil der Gesamtanlage dar. Die Gesamtanlage wird mit einer CE-Konformitätserklärung in herkömmlichen Sinn ausgeliefert.
Stand: 23. Juli 2026
Fällt die Anlage unter die Verpflichtungen des CRA?
Selbst wenn die Maschine aus lauter konformen „Einzelteilen“ besteht, sollten bei der Einschätzung der Verpflichtungsaufwände nachstehende Überlegungen angestellt werden: Beispiele der Verwendung für standardisierte Komponenten sind etwa (SPS-getriebene) Steuerungen unterschiedlicher Funktionsweisen, Frequenzumrichter und/oder Netzwerkschnittstellen etc. In einer Maschine können diese für sich genommen CRA-konform und mit einem CE-Siegel ausgestattet sein, denn sie haben jeweils eigene Hersteller, und von einer gewissen Komplexität an unterliegen sie dem CRA. Ein Gehäuse zählt nicht dazu, wohl aber eine Netzwerkkarte oder ein Bluetooth-Chip. Das Unternehmen, das die Anlagen baut, integriert diese. Die Integration ist mit technischem Aufwand verbunden, damit der Zweck der Integration ermöglicht wird. Angenommen, ich baue ein fernsteuerbares Heiz- oder Klimasystem für Großveranstaltungen. Alles Komponenten sind CRA-konform. Der Anlagenbauer jedoch integriert und realisiert Steuerung lokal und aus der Ferne. Dazu müssen Systembestandteile eigens programmiert werden. Spätestens dann ist etwas Neues, nämlich ein eigenständiges Produkt mit digitalen Elementen entstanden. Das Ganze, könnte man demgemäß sagen, ist mehr als die Summe seiner Teile. Und mit der Netzwerkschnittstelle wird die Maschine zu einem Produkt mit digitalen Elementen und damit schon anhand dieses Kriteriums CRA-relevant. Die Kritikalitätsklasse richtet sich dann nach dem Kontext und nicht nach dem verbauten Modul. Wenn das Produkt Krankenhäuser oder Kraftwerksleitstände versorgt, ist das etwas anderes als ein Autohaus.
Reicht es aus, wenn die eingesetzten Komponenten CRA-konform sind, oder müssen wir zusätzlich die gesamte Anlage als System betrachten und bewerten?
Gemäß dem derzeitigen Kenntnisstand sind Anlagen Produkte. Wenn Sie aus unterschiedlichen Komponenten eine Anlage herstellen und dem Kunden verkaufen, ist das Gesamtsystem das Produkt. Wenn es digitale Elemente gemäß CRA-Definition enthält, ist die Anlage als ein Ganzes ein Produkt mit digitalen Elementen und fällt unter die Regulierung des CRA.
Wo endet unsere Verantwortung und wo beginnt die Verantwortung des Anlagenbetreibers bzw. Endkunden?
Das ist eine Frage, die der CRA meines Wissens nicht explizit beantwortet bzw. reguliert. Grundsätzlich ist der CRA ein Gesetz, das darauf abzielt, das Niveau an Cybersicherheit in Produkte mit digitalen Elementen zu erhöhen. Leitend ist dabei das Datum, wann das Produkt auf den europäischen Binnenmarkt kommt. Wenn Sie die Anforderungen und Pflichten ignorieren, machen Sie sich strafbar. Aber es steht Ihnen natürlich frei, sich so zu entscheiden, auch wenn es nicht gerade der Stil ist, der uns in Deutschland und Europa auszeichnet. Mein Plädoyer: Safety und Security sind das neue Made in Germany. Wenn es uns gelingt, das als Alleinstellungsmerkmal zu vermarkten, klappt’s auch mit den Umsätzen. Wir brauchen hier eine andere Story als die alte Leier von den teuren Strafen der EU. Angst baut keine sicheren Geräte. Das bekommen wir nur hin, wenn wir Prinzipien, die im Gesetz verankert sind, beherzigen. Ergänzend kann man sagen, dass die Pflichten zwar nicht definieren, was dem Kunden an Verantwortung aufzubürden ist. Der CRA beschreibt aber ziemlich genau, was Hersteller, In-Verkehr-Bringende oder Importeure für Aufgaben hinsichtlich Produkte mit digitalen Elementen hat. Ein Beispiel: Im Kontext der Anlagensteuerung eines Produkts unserer Firma ABCDE ermächtigen Sie Käufer:innen, dass sie Temperaturen, Tagespläne oder andere Betriebsparameter über eine eigene App steuern können. Allerdings werden Sie den Kund:innen sicher keinen Zugriff auf den Quellcode der Steuerungssoftware geben. Im Kontext von Open Source wäre das natürlich möglich. Tun Sie’s jedoch nicht, bleibt jedwede Verantwortung des CRA bei Ihnen (etwa SBOM, Risikomanagement, Dokumentationspflichten etc.).
Welche Anforderungen ergeben sich aus unseren Fernwartungs- und Überwachungszugängen? Sind wir für deren vollständige Absicherung verantwortlich oder liegt ein Teil (bzw. die Gesamtverantwortung für die Einhaltung der CRA) der Verantwortung beim Betreiber?
Ja, sicher. Verantwortung kann nicht delegiert werden. Systeme verhalten sich nämlich in verschiedenen Kontexten jeweils anders. Die Fernwartung gehört zum Produkt. Ebenso jeder Überwachungsübergang. Stichwort ist hier Datenfernübertragung. Das erzeugt die Relevanz und Verantwortung. Sie müssen diese Verantwortung in der Regel nach bestem Wissen wahrnehmen und Ihr Produkt entsprechend dokumentieren. Denn die Maßnahmen zur Absicherung müssen Sie dem Kunden transparent machen. Generell: Stücklisten helfen, den Stand der Dinge zu dokumentieren. Das ist eine Kernanforderung des Gesetzes: SBOM. Im Kontext des Schwachstellenmanagements schaffen Sie sich Klarheit über die fremden Objekte innerhalb Ihres Produktkosmos. Und wenn Sie feststellen, dass Library xyz in Version 1.2 einen kritischen Score auf einer Schwachstelle im CVE hat, die aktiv ausgenutzt wurde und wird, müssen Sie schnell updaten und dann deployen und ausliefern. Mit einer automatisierten Stückliste bekommen Sie das in den Griff (s. https://easycra.net/2026/05/04/alles-sbom-oder-was/).
Welche technischen und organisatorischen Maßnahmen müssen wir im eigenen Unternehmen etablieren, um den CRA-Anforderungen zu entsprechen?
Sollten Sie nach IEC62443 zertifiziert sein, ist das Security Risk Assessment (IEC 62443-3-2) perfekt. Damit ist eine wichtige Hürde im CRA genommen. Alles Handeln definiert sich aus dem Risikodenken bzw. leitet sich daraus ab: Die Produkte müssen daraufhin analysiert werden. Das wäre dann, wenn Sie Produktionsstätten schon im Risikomanagement haben, eine Übertragung auf die Produkte.
Welche Anforderungen ergeben sich für die Entwicklung und Pflege von SPS-Programmen sowie für die Verwaltung von Softwareständen und Updates?
Wie oben angedeutet, müssen Sie Ihre Software-Landschaft überschauen (können). Das geht am besten mit der Pflege von SBOMs. Tools und Standards finden Sie im Blog-Artikel. Stellen Sie eine ausgenutzte Schwachstelle fest, wird sie innerhalb von 24 Stunden gemeldet. Die Meldung geht an die ENISA vom 11.09.2026 an. Die ENISA ist eine Single Reporting Platform. Sie leitet je nach nationaler Zuständigkeit die Meldung an die national zuständige Behörde, in Deutschland ist dies das Bundesamt für Sicherheit in der Informationssicherheit, BSI, weiter. Nach 72 Stunden wird ein ausführlicher Bericht fällig. Dann haben Sie für die Zeit nach Mitigierung bzw. das Patchen oder ein Update. Ist der Vorgang abgeschlossen, müssen Sie innerhalb von 14 Tagen den Schlussbericht einreichen, in dem die Wege zur Verbesserung aufgezeigt werden. Aus dem CRA geht nicht hervor, für welches Environment (Echtzeit, Industriesteuerung oder Consumer Electronics und deren Sprachen) und mit welcher Sprache die Software geschrieben wurde.
Ist eine Trennung von Entwicklungs- und Produktivumgebungen erforderlich und welche Anforderungen bestehen hierbei an die IT-Sicherheit?
Davon ist dem CRA nichts zu entnehmen. Man sollte sich daher an den Best Practices der Branche orientieren. Im Feld der Cybersecurity sollte man immer ein wenig strenger sein, als mir lieb wäre. Verfolgen Sie die klassischen Schutzziele der Informationssicherheit, Arbeiten Sie redundant und damit ausfallsicher. Stellen Sie Notfallpläne auf, damit Sie weiter produzieren und Services leisten können. Überwachen Sie die Lieferkette und sichern Sie dort Integrität.
Welche Anforderungen bestehen hinsichtlich Schwachstellenmanagement, Dokumentation und Meldepflichten für Anlagenbauer wie uns?
Meldepflichten sollten für Anlagenbauer genauso wie für reine Softwareentwickler gelten. Das Gesetz unterscheidet hier nicht. Es ist der Definition nach horizontal, also über die meisten Branchen hinweg gültig und wirksam (vollumfänglich vom 11.12.2027 an).
Was wird dokumentiert?
Risikomanagement: Art. 13 Abs 2: Die Bewertung eines Cybersicherheitsrisikos wird dokumentiert. Abs 4 besagt, dass Gründe dokumentiert werden müssen, wenn Cybersicherheitsanforderungen nicht erfüllt werden. Abs 7 verlangt systematische Dokumentation von Cybersicherheitsrisiken. Dokumentiert werden Schwachstellen und Informationen, die von Dritten bereitgestellt werden. Dann gibt es die technische Dokumentation (Art 31, auch Art. 13 Abs 12), in der ablesbar sein soll, wie der Hersteller die Cybersicherheitsanforderungen einhält. Sie ist für das Erlangen der Konformitätserklärung notwendig. Dokumentationen müssen aktuell gehalten werden. Es gibt eine Aufbewahrungspflicht von zehn Jahren für die techn. Dokumentation (Abs 13). Die Bewertung der Cyberrisiken ist in die Doku aufzunehmen.