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 23. Juni 2026; vorheriger Prüfstand: 26. März 2026. Der Rechtsrahmen steht, während Leitlinien und harmonisierte Standards weiter konkretisiert werden. Seit dem 11. Juni 2026 gelten außerdem die CRA-Vorschriften für die Notifizierung von Konformitätsbewertungsstellen. Für Hersteller bleibt die operative Richtung klar: Produktinventar, Entwicklungsprozesse und Schwachstellenmanagement brauchen Vorlauf.
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 über den gesamten Produktlebenszyklus. 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 ein Konformitätsbewertungsverfahren mit externer Stelle vorgesehen.
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 ersten Meldung an die ENISA-Plattform (Single Reporting Platform), 72 Stunden bis zum vollständigen Bericht, 14 Tage nach Patch oder Workaround bis zum Abschlussbericht. Wer keine Meldeprozesse hat, wird das nicht einhalten können.
Zeitplan und Übergangsfristen
| Datum | Meilenstein |
|---|---|
| 10.12.2024 | CRA in Kraft |
| 03.02.2025 | Normungsauftrag an CEN/CENELEC/ETSI |
| 03.03.2026 | Entwurf Umsetzungsleitlinien veröffentlicht |
| 31.03.2026 | Ende der Konsultationsfrist |
| 11.06.2026 | Rahmen für notifizierte Konformitätsbewertungsstellen |
| 11.09.2026 | Meldepflichten für Schwachstellen & 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 — das dauert. Erfahrungsgemäß 18 bis 36 Monate bei Unternehmen, die heute bei null anfangen. Wer bis 2026 wartet, kommt nicht rechtzeitig durch.
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 | Alle vernetzten Produkte | Maschinen im Sinne der MVO |
| Schwerpunkt | Cybersicherheit des Produkts | Sicherheit + Cybersicherheit der Maschine |
| Gültig ab | 11. Dezember 2027 | 20. Januar 2027 |
| Selbstbewertung | Ja (Standardprodukte) | Ja (Risikoklassen abhängig) |
Hinweis: Auch am 23. Juni 2026 ist eine Verschiebung der MVO-Cybersicherheitsanforderungen auf den 11. Dezember 2027 lediglich eine Forderung aus der Industrie. Beschlossen ist sie nicht. Für die Planung bleibt deshalb 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 einrichten: 24-Stunden-Kette zur ENISA-Plattform funktionsfähig machen — vor dem 11. September 2026
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 gilt ausdrücklich auch für Software als eigenständiges Produkt mit digitalen Elementen. Ausgenommen sind nicht-kommerzielle Open-Source-Software sowie bestimmte Kategorien wie SaaS-Dienste, auf die separate Regelungen angewendet werden.
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?
Bereits ab 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 ab diesem Datum 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 eine externe Konformitätsbewertung vorgesehen. Die Einstufung sollte deshalb vor der Wahl des Verfahrens geprüft werden.