CRA-Compliance in der Praxis
So gelingt der Weg zur Cyberresilienz
Viele Unternehmen haben sich noch nicht ausreichend auf die Veränderungen eingestellt, die der Cyber Resilience Act (CRA) ab Ende 2027 bringt. Software-Entwicklungsprozesse werden formaler, die Dokumentation auch im Open-Source-Umfeld anspruchsvoller. Besonders die geforderte Update-Fähigkeit stellt viele Hersteller vor Herausforderungen. 'CRA-ready'-Betriebssysteme und Komponenten können den Weg zur Compliance erheblich verkürzen.
Bild: Kontron Europe GmbHDer Cyber Resilience Act soll angesichts der zugespitzten Lage im Bereich Cybersicherheit dazu beitragen, das Sicherheitsniveau vernetzter Produkte in Europa deutlich zu erhöhen. Dafür müssen Hersteller Security systematisch in ihre Produkte integrieren - von 'Secure by Design' über Update-Fähigkeit bis hin zum kontinuierlichen Schließen von Schwachstellen. Ziel ist es, auch bereits länger am Markt befindliche Systeme resilient gegen Cyberangriffe zu machen.
Bild: Kontron Europe GmbHNormen, Zertifizierung und organisatorischer Umbau
Spätestens ab dem 11. Dezember 2027 dürfen nur noch CRA-konforme Produkte mit CE-Kennzeichnung in Verkehr gebracht werden. Damit wird Cybersecurity unmittelbar wettbewerbsrelevant. Viele Unternehmen unterschätzen jedoch noch immer die Tragweite der neuen Anforderungen. Anders als bei der NIS-2-Richtlinie geht es beim CRA nicht nur um organisatorische Maßnahmen, sondern um konkrete technische Vorgaben für Produkte, Komponenten und Entwicklungsprozesse. Wer Produkte auf den Markt bringt, haftet künftig für das Gesamtsystem - ein bloßes Weiterreichen der Verantwortung an Zulieferer reicht nicht mehr aus.
Für viele Unternehmen bedeutet das erhebliche organisatorische Veränderungen. Der CRA orientiert sich stark an bestehenden Standards wie IEC62443-4-1 und -4-2. Unternehmen, die sich bereits mit diesen Normen oder mit der EN18031 im Rahmen der Radio Equipment Directive beschäftigt haben, besitzen einen Vorteil. Trotzdem drängt die Zeit: Teile der relevanten Normen sind noch nicht final ausformuliert, gleichzeitig müssen Entwicklungs- und Zertifizierungsprozesse bereits heute angepasst werden.
Je nach Sicherheitsklasse eines Produkts werden künftig externe Prüforganisationen wie der TÜV eingebunden. Das erhöht den Aufwand zusätzlich. Gleichzeitig dürfte sich CRA-Konformität rasch als Standard in Ausschreibungen etablieren. Unternehmen müssen deshalb lernen, Risiken systematisch zu bewerten, technische Schutzmaßnahmen daraus abzuleiten und ihre Lieferketten in das Sicherheitskonzept einzubinden.
Bild: Kontron Europe GmbHDer Weg zur Compliance bleibt holprig
Besonders schwierig wird der Umstieg für Unternehmen, die bislang wenig Berührung mit Industrial Security hatten. Während bei bisherigen CE-Zertifizierungen häufig noch Spielräume bestanden, steigen die Anforderungen nun deutlich. Hinzu kommen offene Fragen: So verlangt die EN18031 eine Software Bill of Materials (SBOM), die auch Standardsoftware wie Windows berücksichtigen müsste. Für manche Komponenten fehlen bislang jedoch passende Konformitätserklärungen der Hersteller, was die Zertifizierung komplex macht.
Neue Anforderungen an Embedded-Systeme
Auch technisch steigen die Anforderungen erheblich. Gefordert wird u.a. eine Hardware Root of Trust bzw. Security, die sicherstellt, dass Bootloader, Firmware und Betriebssystem unverändert und authentisch sind. Software darf künftig nicht mehr beliebig nachinstalliert werden. Jede Änderung muss Teil des Sicherheitskonzepts sein. Gleichzeitig müssen Systeme Updates eigenständig validieren können, damit manipulierte Software ausgeschlossen wird. Hinzu kommt ein kontinuierliches Schwachstellen-Monitoring über den gesamten Produktlebenszyklus. Hersteller müssen Risiken in Komponenten und Gesamtsystemen überwachen und abhängig von der Sicherheitsklassifizierung regelmäßig Updates bereitstellen. Gerade bei älteren Produkten ist das oft schwierig umzusetzen.
Bild: Kontron Europe GmbHSecurity verändert die Software-Entwicklung
Besonders stark verändert der CRA die Software-Entwicklung. Unternehmen müssen z.B. nachverfolgen und dokumentieren (SBOM), welche Software-Komponenten im Einsatz sind und diese stetig bezüglich Vulnerabilitäten überwachen. Gleichzeitig steigen die Anforderungen an sichere Entwicklungsprozesse, Dokumentation und Testing deutlich. Security-by-Design wird zum verbindlichen Entwicklungsprinzip. Schnelle Ad-hoc-Releases oder kurzfristige Workarounds lassen sich unter diesen Rahmenbedingungen kaum noch realisieren. Auch externe Entwicklungspartner und Teams außerhalb der EU müssen in die Sicherheitsstrategie integriert werden. Definierte Schnittstellen, nachvollziehbare Prozesse und zusätzliche Schulungen gewinnen an Bedeutung. Insgesamt wird Software-Entwicklung formaler und strategischer. Kleine Sonderlösungen oder kurzfristige Individualprojekte dürften dadurch seltener werden.
Vorgefertigte Security-Bausteine gewinnen an Bedeutung
Um die Umsetzung zu beschleunigen und Entwicklungsaufwände deutlich zu reduzieren, setzen Unternehmen auf vorhandene Lösungen. CRA-ready-Produkte wie KontronOS integrieren Funktionen wie Secure Boot, sichere OTA-Updates und SBOM bereits im Betriebssystemumfeld. Device Management Lösungen wie KontronGrid ermöglichen das sichere und effektive Ausrollen von Security-Updates von Edge-Geräten. Gleichzeitig wächst die Nachfrage nach Beratungsleistungen rund um Embedded Linux und industrieller Cybersecurity. Auch für bestehende Systeme gibt es Ansätze. Sicherheits-Gateways wie KontronAIShield können als vorgeschaltete Firewall zwischen Netzwerk und Bestandssystem fungieren. Durch vorgeschaltete Sicherheits- und Hardwarelösungen können die Risiken älterer, nicht mehr updatefähiger Systeme reduziert werden.
Update-Fähigkeit wird zum kritischen Faktor
Ein zentraler Painpoint bleibt die langfristige Update-Fähigkeit. Der CRA fordert, Schwachstellen über mindestens fünf Jahre nach Auslieferung eines Produkts zu beheben. In der Industrie liegen reale Nutzungsdauern jedoch oft bei zehn bis 20 Jahren. Zwar können Hersteller eigener Betriebssysteme Updates meist selbst bereitstellen, doch bei BIOS, Firmware oder Prozessorplattformen bleiben sie von Zulieferern abhängig. Endet dort der Support, gerät die Updatefähigkeit des Gesamtsystems in Gefahr. Hinzu kommt die hohe Komplexität industrieller Updates. Maschinen und Anlagen bestehen meist aus Komponenten verschiedener Hersteller und Integratoren. Selbst wenn Updates verfügbar sind, müssen Betreiber und Partner diese prüfen, anpassen und freigeben. Der organisatorische Aufwand steigt dadurch erheblich.
Der Handlungsdruck wächst
Dass Handlungsbedarf besteht, zeigen aktuelle Zahlen des Bundesamts für Sicherheit in der Informationstechnik: Bis Mitte 2025 wurden täglich durchschnittlich 119 neue Schwachstellen registriert - rund 25 Prozent mehr als im Vorjahr. Der CRA dürfte damit weit mehr sein als eine regulatorische Pflicht: Er markiert den Übergang zu einem deutlich höheren Sicherheitsniveau in der industriellen Digitalisierung.
Viele Unternehmen haben sich noch nicht ausreichend auf die Veränderungen eingestellt, die der Cyber Resilience Act (CRA) ab Ende 2027 bringt. Software-Entwicklungsprozesse werden formaler, die Dokumentation auch im Open-Source-Umfeld anspruchsvoller. Besonders die geforderte Update-Fähigkeit stellt viele Hersteller vor Herausforderungen. 'CRA-ready'-Betriebssysteme und Komponenten können den Weg zur Compliance erheblich verkürzen.
Bild: Kontron Europe GmbHDer Cyber Resilience Act soll angesichts der zugespitzten Lage im Bereich Cybersicherheit dazu beitragen, das Sicherheitsniveau vernetzter Produkte in Europa deutlich zu erhöhen. Dafür müssen Hersteller Security systematisch in ihre Produkte integrieren - von 'Secure by Design' über Update-Fähigkeit bis hin zum kontinuierlichen Schließen von Schwachstellen. Ziel ist es, auch bereits länger am Markt befindliche Systeme resilient gegen Cyberangriffe zu machen.
Kontron Europe GmbH
Dieser Artikel erschien in SPS-MAGAZIN 6 (Juni) 2026 - 25.06.26.Für weitere Artikel besuchen Sie www.sps-magazin.de
