In diesem Beitrag
Am 10. Dezember 2024 trat der Cyber Resilience Act in Kraft — Verordnung (EU) 2024/2847, im Amtsblatt veröffentlicht, verbindlich. Für Maschinenbauer, Automatisierungsspezialisten und Hersteller von Hard- und Software mit digitalen Elementen ist das keine abstrakte Regulierungsnachricht. Es betrifft das Kerngeschäft — und die Uhr läuft.
Aktualisiert am 24. Oktober 2026. Die EU-Kommission veröffentlichte am 27. Juli 2026 ihre finalen CRA-Leitlinien und aktualisierte die FAQ zuletzt am 4. September 2026. Beide Dokumente helfen bei der praktischen Auslegung, ändern aber nicht den verbindlichen Verordnungstext. Seit dem 11. September 2026 gelten die Meldepflichten nach Artikel 14. Hersteller brauchen belastbare Meldewege; für die übrigen Pflichten bleiben Produktinventar, Entwicklungsprozesse und Schwachstellenmanagement die zentralen Vorarbeiten.
Was ist der Cyber Resilience Act?
Der CRA schreibt verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest. Darunter fällt alles, was direkt oder indirekt mit Netzwerken oder anderen Geräten kommunizieren kann — industrielle Steuerungen, IoT-Sensoren, Softwarepakete. Die Grenze ist breiter gezogen, als viele zunächst vermuten.
Das Kernprinzip: Security by Design. Cybersicherheit ist kein Nachrüstprojekt. Sie gehört in die Entwicklung — von der ersten Architekturentscheidung bis zum letzten Software-Release.
Neu und für viele Hersteller ungewohnt: Der CRA verpflichtet nicht nur zur sicheren Auslieferung, sondern zum aktiven Schwachstellenmanagement während des festgelegten Supportzeitraums. Das ist ein anderes Denkmuster als bisher.
Wen betrifft der CRA?
Kurze Antwort: deutlich mehr Unternehmen als zunächst gedacht. Der CRA gilt für alle Hersteller, Importeure und Händler, die vernetzte Produkte auf dem EU-Markt bereitstellen — Sitz in der EU ist keine Voraussetzung für die Pflicht.
Konkret betroffen:
- Hersteller von Industriemaschinen mit vernetzten Komponenten (SPS, HMI, Sensoren)
- Anbieter von SCADA- und Prozessleitsystemen
- Entwickler von Embedded Software und Firmware
- Hersteller von IoT-Geräten und Netzwerkkomponenten
- Anbieter von Software, die in kritische Infrastruktur eingebettet ist
Der CRA kennt drei Produktkategorien — und damit drei Anforderungsniveaus:
Standardprodukte machen die große Mehrheit aus. Selbstbewertung reicht.
Wichtige Produkte der Klasse I können bei vollständiger Anwendung einschlägiger harmonisierter Standards unter bestimmten Voraussetzungen intern bewertet werden. Fehlt diese Grundlage, ist eine Benannte Stelle einzubeziehen. Für wichtige Produkte der Klasse II und kritische Produkte ist grundsätzlich ein Konformitätsbewertungsverfahren mit externer Stelle vorgesehen. Artikel 32 Absatz 5 enthält unter seinen besonderen Voraussetzungen eine Ausnahme für freie und quelloffene Software der Klassen I und II. Der bloße Einbau einer Open-Source-Komponente eröffnet diese Ausnahme nicht für das gesamte Produkt.
Anforderungen des CRA im Überblick
Sicherheitsanforderungen für das Produkt
Produkte dürfen keine bekannten ausnutzbaren Schwachstellen enthalten, wenn sie in den Verkehr gebracht werden. Das ist der Maßstab — kein “best effort”, sondern ein nachweisbares Ergebnis.
Was das operativ bedeutet:
- Datenverschlüsselung, wo technisch sinnvoll
- Minimale Rechtevergabe als Konstruktionsprinzip
- Sichere Update-Mechanismen ab Werk
- Klares Verfahren zur Schwachstellenmeldung
- Eine Software Bill of Materials (SBOM) in einem gängigen maschinenlesbaren Format. Der CRA verlangt mindestens die direkten Abhängigkeiten; für das eigene Schwachstellenmanagement kann eine tiefere Auflösung sinnvoll sein.
Die SBOM ist für viele Hersteller das aufwendigste Element. Wer heute noch keinen Überblick über seine eingebetteten Open-Source-Komponenten hat, ahnt, was das bedeutet.
Schwachstellenmanagement über den Lebenszyklus
Der Hersteller muss einen Supportzeitraum festlegen, der die erwartete Nutzungsdauer des Produkts berücksichtigt. Grundsätzlich beträgt er mindestens fünf Jahre. Liegt die erwartete Nutzungsdauer unter fünf Jahren, darf der Supportzeitraum entsprechend kürzer sein. Während dieses Zeitraums müssen Schwachstellen wirksam behandelt und Sicherheitsupdates bereitgestellt werden.
Wird eine Schwachstelle aktiv ausgenutzt, läuft die Uhr: 24 Stunden bis zur Frühwarnung an die ENISA-Plattform (Single Reporting Platform), 72 Stunden bis zur Schwachstellenmeldung mit den bis dahin verfügbaren Informationen und grundsätzlich 14 Tage nach Verfügbarkeit einer Abhilfe- oder Risikominderungsmaßnahme bis zum Abschlussbericht. Für schwerwiegende Sicherheitsvorfälle gelten ein eigener 72-Stunden-Schritt und ein Abschlussbericht binnen eines Monats. Ohne vorbereitete Meldeprozesse sind diese Fristen kaum verlässlich einzuhalten.
Zeitplan und Übergangsfristen
| Datum | Meilenstein |
|---|---|
| 10.12.2024 | CRA in Kraft |
| 03.02.2025 | Normungsauftrag an CEN/CENELEC/ETSI |
| 11.06.2026 | Rahmen für notifizierte Konformitätsbewertungsstellen |
| 27.07.2026 | Finale CRA-Leitlinien C(2026) 5252 veröffentlicht |
| 04.09.2026 | Aktualisierte CRA-FAQ veröffentlicht |
| 11.09.2026 | Meldepflichten für Schwachstellen und Sicherheitsvorfälle |
| 11.12.2026 | Ausreichende Zahl notifizierter Stellen |
| 11.12.2027 | Alle CRA-Anforderungen vollständig anwendbar |
Der 11. Dezember 2027 klingt komfortabel. Ist er nicht. Security by Design in bestehende Entwicklungsprozesse zu integrieren, eine SBOM aufzubauen und Schwachstellenmanagement als Funktion zu etablieren, braucht Vorlauf. Wer erst kurz vor der vollständigen Anwendung beginnt, riskiert unnötigen Zeitdruck bei Technik, Dokumentation und Konformitätsbewertung.
CRA vs. Maschinenverordnung: Wo liegt der Unterschied?
Maschinenbauer stehen momentan vor mehreren Regelwerken gleichzeitig. Die Frage, welches Vorrang hat, geht am Problem vorbei. Beide gelten — parallel.
| Aspekt | CRA | Maschinenverordnung (MVO) |
|---|---|---|
| Anwendungsbereich | Produkte mit digitalen Elementen im CRA-Anwendungsbereich | Maschinen im Sinne der MVO |
| Schwerpunkt | Cybersicherheit des Produkts | Sicherheit + Cybersicherheit der Maschine |
| Vollständig anwendbar ab | 11. Dezember 2027 | 20. Januar 2027 |
| Selbstbewertung | Ja (Standardprodukte) | Ja (Risikoklassen abhängig) |
Hinweis: Eine Verschiebung der MVO-Anwendung auf den 11. Dezember 2027 ist in der Verordnung (EU) 2023/1230 auch nach der Änderung durch die Verordnung (EU) 2026/1744 nicht geregelt. Für die Planung bleibt der 20. Januar 2027 maßgeblich.
Der Entwurf prEN 50742 bleibt für die technische Vorbereitung relevant. Sein Status und die Grenzen der künftigen Konformitätsvermutung sind im Beitrag zu prEN 50742 und Maschinen-Cybersicherheit eingeordnet.
Was bedeutet das für Maschinenbauer konkret?
Drei Aufgaben, die jetzt anstehen:
- Produktbestandsaufnahme: Welche Produkte fallen unter den CRA? Welche Risikoklasse gilt?
- SBOM aufbauen: Alle Softwarekomponenten — Open Source, Eigenentwicklung, Drittanbieter — vollständig in SPDX oder CycloneDX erfassen
- Meldeprozesse betreiben: Die 24-Stunden-Kette zur ENISA Single Reporting Platform muss stehen. Der 11. September 2026 ist vorbei.
CRA-Beratung: Wie ich Maschinenbauer und Hersteller bei der CRA-Konformität begleite — SBOM, Schwachstellenmanagement, Konformitätsdokumentation — finden Sie unter CRA & Maschinenverordnung.
Häufige Fragen zum Cyber Resilience Act
Gilt der CRA auch für Software?
Ja. Der CRA erfasst auch Software, die als eigenständiges Produkt mit digitalen Elementen auf dem Markt bereitgestellt wird. Reine Online-Dienste fallen nicht allein deshalb unter den CRA. Eine entfernte Datenverarbeitungslösung kann jedoch zum Produkt gehören, wenn der Hersteller sie für das Produkt entworfen oder entwickelt hat und das Produkt ohne sie eine seiner Funktionen nicht erfüllen könnte. Für nicht kommerziell bereitgestellte freie und quelloffene Software sowie weitere ausdrücklich genannte Bereiche gelten Ausnahmen, die im Einzelfall geprüft werden müssen.
Was ist eine SBOM und welche Formate akzeptiert der CRA?
Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Verzeichnis der Softwarekomponenten und Abhängigkeiten. Der CRA verlangt mindestens die direkten Abhängigkeiten, schreibt aber kein konkretes Format vor. In der Praxis sind SPDX (ISO/IEC 5962) und CycloneDX verbreitet.
Was passiert bei Verstößen gegen den CRA?
Der CRA sieht Bußgelder bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes vor — je nachdem, welcher Betrag höher ist. Produkte ohne CRA-Konformität dürfen ab 11. Dezember 2027 nicht mehr erstmals auf den EU-Markt.
Ab wann gelten die Meldepflichten des CRA?
Seit dem 11. September 2026, also deutlich vor der vollständigen CRA-Anwendung im Dezember 2027. Wer aktiv ausgenutzte Schwachstellen oder schwerwiegende Sicherheitsvorfälle nicht innerhalb von 24 Stunden an die ENISA-Plattform meldet, verstößt gegen die Verordnung.
Kann ich die CRA-Konformität selbst bewerten?
Für Standardprodukte ist eine Selbstbewertung möglich. Bei wichtigen Produkten der Klasse I hängt der Bewertungsweg unter anderem davon ab, ob einschlägige harmonisierte Standards vollständig angewendet werden. Für Klasse II und kritische Produkte ist grundsätzlich eine externe Konformitätsbewertung vorgesehen. Die besondere OSS-Ausnahme nach Artikel 32 Absatz 5 ist anhand sämtlicher Voraussetzungen zu prüfen, nicht allein anhand eingebauter Open-Source-Komponenten. Die Einstufung sollte deshalb vor der Wahl des Verfahrens geprüft werden.