Was sich mit dem Cyber Resilience Act (CRA) wirklich ändert
Die meisten Maschinenbauer sind Weltklasse darin, robuste Produkte zu entwickeln. Jahrzehntelang war „Zuverlässigkeit“ das wichtigste Qualitätsversprechen. Doch genau dieses Erfolgsmodell gerät unter Druck, wenn Maschinen heute Software enthalten, vernetzt sind – und damit angreifbar werden.
Der Cyber Resilience Act (CRA) macht daraus keine freiwillige Kür mehr, sondern eine verbindliche Herstellerpflicht: Wer Produkte mit digitalen Elementen in Verkehr bringt, muss Cybersicherheit systematisch nachweisen, pflegen und im Betrieb beherrschbar machen. Das betrifft in der Praxis viele Maschinen, Anlagen und Komponenten – unabhängig davon, ob sie „ständig online“ sind.
Viele Organisationen behandeln Security heute noch als „IT-Thema“. Im Maschinenbau liegt die Wahrheit aber oft woanders:
Software steckt im Produkt, nicht nur im Netzwerk.
Updates laufen über Wartungsfenster und Serviceprozesse, nicht über Windows Update.
Lieferketten (Libraries, Embedded-Stacks, Third-Party-Komponenten) sind längst Realität.
Der CRA verschiebt Verantwortung genau dorthin: zum Hersteller – entlang des gesamten Produktlebenszyklus.
Die CRA Zeitachse: Ab wann wird es verbindlich?
Wichtig sind zwei Zeitpunkte, die in vielen Roadmaps aktuell noch fehlen:
| Stichtag | Was wird relevant? | Was Sie bis dahin fertig haben sollten: |
|---|---|---|
| 11.09.2026 | Reporting aktiv ausgenutzter Schwachstellen & schwerer Incidents | Meldeprozess, Rollen, Datenlage (SBOM/Versionen), „Early Warning“ Ablauf |
| 11.12.2027 | CRA-Pflichten vollständig anwendbar | Security by Design & Nachweiskette in Entwicklung/Release/Service |
Quelle: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Das klingt „weit weg“, ist es aber nicht: Wenn Sie SBOM, Patch-Prozess, Release-Gates, Dokumentation und Rollen erst 2027 anfangen aufzubauen, endet das in hektischen Nacharbeiten – genau dann, wenn Sie eigentlich liefern müssen.
Die CRA Pflichten – übersetzt in Maschinenbau-Realität
1. Security by Design: nicht „nachträglich absichern“, sondern einplanen
Beim Cyber Resilience Act müssen Produkte mit digitalen Elementen so entworfen und entwickelt werden, dass Cybersecurity von Anfang an berücksichtigt ist – nicht erst als „Härtung“ kurz vor Auslieferung. Praktisch heißt das:
- sichere Defaults,
- robuste Authentisierung/Autorisierung,
- Angriffsflächen minimieren, und
- Sicherheitsanforderungen als echte Engineering-Kriterien behandeln.
Unserer Perspektive
Security by Design scheitert selten am „Wissen“, sondern an fehlenden Engineering-Haltepunkten: Architekturentscheidungen, Coding-Guidelines, Threat-Workshops und klare Release-Gates. Wir empfehlen, Security-by-Design messbar zu machen (z. B. Definition of Done + Security-Gates) und das Ganze so in den Entwicklungsfluss zu integrieren, dass es nicht als Zusatzprojekt „nebenher“ läuft.
2. Risikobewertung & Dokumentation: wiederholbar statt einmalig
Der CRA verlangt eine nachvollziehbare Risikobewertung und eine passende technische Dokumentation, damit Konformität und Sicherheitsüberlegungen prüfbar sind und über Produktänderungen hinweg konsistent bleiben.
Entscheidend ist dabei nicht nur die Erstbewertung, sondern die Fähigkeit, die Bewertung bei neuen Versionen, neuen Komponenten oder neuen Bedrohungen fortzuschreiben.
Unserer Perspektive
Risikobewertung darf im Maschinenbau nicht zur „jährlichen Dokumentationsübung“ werden, sonst ist sie im Ernstfall veraltet. Wir sehen gute Ergebnisse, wenn Risikobewertung als Bestandteil des Release-Managements etabliert wird: Änderungen an Architektur/Komponenten lösen automatisch ein Update der Risikoartefakte aus (leichtgewichtig, aber verbindlich).
3. SBOM: ohne Software-Stückliste keine Reaktionsfähigkeit
Die SBOM ist die „Teileliste“ Ihrer Software: Sie macht transparent, welche Bibliotheken, Abhängigkeiten und Komponenten (inkl. Open Source und Third Party) in welchem Produkt und welcher Version stecken.
Ohne SBOM können Sie bei neuen Schwachstellen kaum verlässlich beantworten, ob und wo Sie betroffen sind – und wie schnell Sie reagieren müssen.
Unserer Perspektive
SBOM ist nur dann wirklich wirksam, wenn sie automatisiert entsteht (z. B. in Build/CI) und als versioniertes Release-Artefakt behandelt wird. Zusätzlich sollte die SBOM in Ihre Vulnerability-Prozesse einzahlen: „CVE trifft SBOM → betroffene Produkte/Versionen → Patch-Backlog → Release“.
4. Update-Management: Patchfähigkeit wird zur Produktfunktion
Der CRA verlangt, dass Hersteller Sicherheitslücken handhaben und Sicherheitsupdates bereitstellen – typischerweise für die erwartete Produktlebensdauer oder fünf Jahre, je nachdem was kürzer ist.
Das ist nicht nur eine technische Forderung (Updatefähigkeit), sondern auch eine organisatorische: Priorisierung, Tests, sichere Verteilung und Kundeninformation müssen zuverlässig funktionieren.
Unserer Perspektive
Update-Management ist im Maschinenbau ein Zusammenspiel aus Produktarchitektur, Serviceprozessen und Release-Disziplin – nicht „nur ein Tool“. Wir empfehlen eine klare Trennung zwischen Security-Fixes und Feature-Changes (wo möglich) sowie einen reproduzierbaren Patch-Prozess (inkl. Rollback-Strategie, Signierung, Nachweisführung), damit Updates im Feld planbar und auditierbar sind.
5. Incident Reporting: Prozesse statt Panik
Der CRA führt konkrete Reporting-Pflichten ein: Bei aktiv ausgenutzten Schwachstellen und schweren Incidents ist eine Frühwarnung innerhalb von 24 Stunden nach Kenntnis gefordert, gefolgt von weitergehenden Meldungen (z. B. vollständig innerhalb von 72 Stunden und ein Abschlussbericht).
Dabei spielt auch die Kommunikation an zuständige Stellen wie ENISA und nationale CSIRTs eine Rolle
Unserer Perspektive
Die größte Hürde ist fast nie das Ausfüllen der Meldung, sondern die Fähigkeit, in kurzer Zeit saubere Fakten zu liefern (Betroffenheit, Impact, Workarounds, Fix-Plan). Deshalb brauchen Hersteller ein Incident-Playbook: klare Rollen (Engineering, Security, Legal, Kommunikation), Eskalationswege, und eine technische „Beweiskette“ (Logs, SBOM, Versionsstände), damit Reporting nicht im Chaos endet.
Warum Cyber Resilience Act (CRA) nicht nur Risiko ist, sondern ein Wettbewerbsvorteil sein kann!
Viele sehen Vernetzung/IoT zunächst als Angriffsfläche. Der CRA dreht die Perspektive: Ohne praktikable Mechanismen für Update und Nachweis wird Compliance schwierig. Vernetzung (sicher umgesetzt) kann damit zum Enabler für:
schnelleres Patchen,
höhere Verfügbarkeit,
nachvollziehbare Nachweise und
ein neues Serviceversprechen
(„Wir halten Ihre Anlage sicher und aktuell“).
Beginnen Sie mit dem 30 Tage Quick-Start-Guide der Comquent Academy!
Wenn Sie nicht mit einem Mammutprojekt starten wollen, unterstützen wir Sie mit einem pragmatischen Einstieg:
- Produkt- und Software-Inventar (wo läuft was – inkl. Lieferkette?)
- SBOM-Fähigkeit in Build/CI verankern (automatisiert, versioniert, archiviert)
- Update-/Patch-Prozess definieren (Release-Gates, Wartungsfenster, Kundenkommunikation)
- Incident-Playbook + Rollen (RACI) (Meldung, Bewertung, Fix, Kommunikation)
- Roadmap bis 2027 mit Verantwortlichkeiten und klaren Deliverables
Quellen & Stand
Stand: 02.02.2026. Änderungen an Rechtsakten, Leitlinien oder harmonisierten Normen können die Einordnung beeinflussen. Dieser Beitrag dient der technischen Orientierung und ersetzt keine Rechtsberatung.
- Rechtsgrundlage: Verordnung (EU) 2024/2847 – Cyber Resilience Act (EUR-Lex)
- Überblick (EU): European Commission – Cyber Resilience Act (Policy/Overview)
- Meldepflichten (EU): European Commission – CRA Reporting (Meldeprozess & Fristen)
- Nationale Einordnung (DE): BSI – Cyber Resilience Act (Hinweise & Einordnung)
