Cyber Resilience Act (CRA): Was Software-Hersteller bis 2027 umsetzen müssen

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist die erste EU-weite Verordnung, die ein Mindestmaß an Cybersicherheit für alle Produkte mit digitalen Elementen festlegt. Darunter fällt jede Hard- und Software, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden werden kann und auf dem EU-Markt bereitgestellt wird (BSI: Cyber Resilience Act). Entscheidend ist also nicht die Branche, sondern das Produkt: Vom günstigen Verbraucher-Gadget über B2B-Software bis zur komplexen Industrieanlage greift dieselbe Logik.

Die meisten Produkte gelten als Standardprodukte, für die eine Selbstbewertung ausreicht. Sicherheitskritischere Kategorien führt die Verordnung in den Anhängen III und IV als wichtige und kritische Produkte, etwa Passwortmanager, Firewalls, Smartcard-Lesegeräte oder Smart-Meter-Gateways. Für sie gelten strengere Konformitätsverfahren. Ausgenommen sind Produkte, die bereits anderweitig EU-reguliert sind, beispielsweise Medizinprodukte, Kraftfahrzeuge, Produkte der zivilen Luftfahrt und Schiffsausrüstung.

Wichtig für die Praxis rund um CRA und Software: Auch kommerzielle Open-Source-Software fällt vollständig unter die Verordnung. Lediglich nicht-kommerzielle Open-Source-Projekte sind ausgenommen. Wer Open-Source-Komponenten in kommerzielle Produkte integriert, trägt also Verantwortung für deren Sicherheit mit.

Der CRA ist Ende 2024 in Kraft getreten, entfaltet seine Wirkung aber gestaffelt. Diese Staffelung ist die eigentliche gute Nachricht, denn sie verschafft Herstellern eine klar umrissene Vorbereitungszeit. Drei Daten sollten im Projektkalender stehen (Europäische Kommission: CRA-Zusammenfassung):

• Juni 2026: Die Regelungen zu den Konformitätsbewertungsstellen (notified bodies) werden wirksam. Die Mitgliedstaaten benennen die Stellen, die später die Konformität anspruchsvollerer Produkte prüfen dürfen.
• September 2026: Die Meldepflichten greifen. Ab diesem Tag müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden.
• Dezember 2027: Die Verordnung gilt vollumfänglich. Neu in Verkehr gebrachte Produkte müssen alle CRA-Anforderungen erfüllen und das CE-Kennzeichen tragen, das künftig auch Cybersicherheit bestätigt.

Drei Jahre klingen nach viel Zeit. In der Realität komplexer, langlebiger Softwaresysteme sind sie das selten. Security-Anforderungen lassen sich nicht zuverlässig nachrüsten, ohne Architektur und Releaseplanung zu berühren. Wer erst 2027 beginnt, läuft Gefahr, ganze Produktlinien unter Zeitdruck umbauen zu müssen.

Die CRA-Pflichten lassen sich auf einen einfachen Grundsatz zurückführen: Cybersicherheit muss über den gesamten Lebenszyklus eines Produkts gewährleistet und nachgewiesen werden, von der Planung über Entwicklung und Auslieferung bis zum Betrieb. Konkret bedeutet das fünf eng verzahnte Aufgabenfelder.

Bislang war Security by Design eine Best Practice, mit dem CRA wird daraus eine Security-by-Design-Pflicht. Produkte müssen von der ersten Entwurfsphase an nach dem Prinzip „Secure by Default“ entstehen. Das schließt eine minimale Angriffsfläche ein, sichere Standardkonfigurationen, verschlüsselte Kommunikation, den Verzicht auf hartcodierte Passwörter und belastbare, signierte Update-Mechanismen. Sicherheit ist damit kein Feature, das man später ergänzt, sondern eine Eigenschaft der Architektur.

Am Anfang steht die Risikobewertung. Für jedes Produkt mit digitalen Elementen muss der Hersteller die Cybersicherheitsrisiken analysieren und die Ergebnisse in allen Lebenszyklusphasen berücksichtigen. Darauf baut die Software Bill of Materials (SBOM) auf, ein strukturiertes Verzeichnis aller eingesetzten Komponenten und Abhängigkeiten. Die SBOM ist verpflichtend, muss aber nicht veröffentlicht werden. Ihr Nutzen ist praktisch: Taucht eine neue Schwachstelle in einer Bibliothek auf, lässt sich binnen Minuten statt Tagen feststellen, welche Produkte betroffen sind.

In unseren Projekten gehört eine gepflegte SBOM ohnehin zum Standard, und automatisierte Security-Scans sind fester Bestandteil unserer CI/CD-Pipelines, teils KI-gestützt. Transparenz über alle eingesetzten Komponenten ist bei uns damit kein Sonderaufwand für den CRA, sondern Teil des normalen Entwicklungsprozesses.

Mit dem Verkauf endet die Verantwortung nicht. Über den gesamten Support-Zeitraum, der in der Regel mindestens fünf Jahre beträgt und vom Hersteller transparent kommuniziert werden muss, sind Sicherheitsupdates bereitzustellen und ein kontinuierliches Schwachstellenmanagement zu betreiben. In der Organisation bündelt sich diese Aufgabe sinnvollerweise in einem PSIRT (Product Security Incident Response Team), das Schwachstellen aufnimmt, bewertet und koordiniert behebt.

Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über eine zentrale Plattform der EU-Cybersicherheitsagentur ENISA gemeldet werden. Der Ablauf ist eng getaktet: eine erste Frühwarnung innerhalb von 24 Stunden, ergänzende Informationen innerhalb von 72 Stunden und ein Abschlussbericht spätestens 14 Tage nach Bereitstellung eines Sicherheitsupdates beziehungsweise einen Monat nach der Erstmeldung bei Vorfällen. Wer diese Prozesse erst im Ernstfall aufsetzt, verliert wertvolle Stunden.

Hinzu kommen die formalen Nachweise: technische Dokumentation, Konformitätsbewertung und CE-Kennzeichnung, die über den gesamten Support-Zeitraum aktuell zu halten sind (Europäische Kommission: Konformitätsbewertung).

Der CRA ist kein zahnloses Regelwerk. Verstöße gegen die grundlegenden Sicherheitsanforderungen aus Anhang I sowie gegen die Melde- und Bewertungspflichten können mit Bußgeldern von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist. Für die Verletzung anderer Pflichten sind bis zu 10 Millionen Euro oder 2 Prozent des Umsatzes vorgesehen, für falsche oder irreführende Angaben gegenüber Behörden bis zu 5 Millionen Euro oder 1 Prozent.

Neben dem finanziellen Risiko steht der Marktzugang auf dem Spiel: Produkte, die ab Dezember 2027 nicht CRA-konform sind, dürfen in der EU nicht mehr in Verkehr gebracht werden. Hinzu kommt der schwer bezifferbare, aber reale Imageschaden, wenn ein Produkt öffentlich als unsicher gilt.

Besonders spürbar wird der CRA dort, wo physische Produkte und Software zusammenwachsen. Im Maschinen- und Anlagenbau sind Steuerungen heute vernetzt, im Smart-Home-Segment kommuniziert nahezu jedes Gerät mit der Cloud. Genau diese vernetzten Produkte stehen im Fokus der Verordnung, und gerade hier sind Update-Mechanismen und Schwachstellenmanagement über lange Produktlebenszyklen anspruchsvoll.

Für kleine und mittlere Unternehmen ist die Botschaft unbequem, aber klar: Der CRA fragt nicht nach der Unternehmensgröße. Wer vernetzte Produkte anbietet, muss frühzeitig Strukturen für Risikoanalyse, Updates und Meldewege aufbauen. Der Aufwand verteilt sich deutlich besser, wenn er in laufende Entwicklungszyklen integriert wird, statt als Sonderprojekt kurz vor der Frist zu starten.

Künstliche Intelligenz kann diesen Aufwand spürbar senken. In der Risikoanalyse und beim Threat Modeling, bei automatisierten Security-Scans und beim Sichten von Abhängigkeiten für die SBOM unterstützt KI heute zuverlässig.

Bei BAYOOTEC entsteht ein erheblicher Teil des neuen Codes KI-gestützt, und wir nutzen KI-Automatisierungen unter anderem für Pull-Request-Reviews und Security-Scans. Damit KI auch in regulierten Umfeldern regelkonform bleibt, haben wir einen internen KI-Compliance-Verantwortlichen mit TÜV-Qualifikation etabliert, der den Einsatz absichert. So lässt sich die CRA-Umsetzung beschleunigen, ohne die Kontrolle über Sicherheit und Nachvollziehbarkeit aufzugeben.

So aufwendig die Umsetzung ist, der CRA hat eine strategische Kehrseite. Wer Sicherheit nachweisbar in seine Produkte einbaut, kann das künftig als Qualitätsmerkmal ausspielen. In einem Markt, in dem Einkäufer und Auftraggeber zunehmend Sicherheitsnachweise verlangen, wird CRA-Konformität zum Differenzierungsmerkmal. Das CE-Zeichen für Cybersicherheit signalisiert dann nicht nur Rechtskonformität, sondern belastbare Produktqualität „made for Europe“.

Diese Sicht deckt sich mit unserer Projekterfahrung: Sicherheit von Beginn an mitzudenken erzeugt nicht nur Compliance, sondern stabilere, wartbarere und langlebigere Systeme. Genau das ist der Kern von Security by Design.

Der Cyber Resilience Act verändert, wie Software in Europa entwickelt, betrieben und in Verkehr gebracht wird. Die zentralen CRA-Pflichten – Risikoanalyse, Security by Design, SBOM, Updates über den Support-Zeitraum, PSIRT und Meldepflichten an die ENISA – sind anspruchsvoll, aber planbar. Wer den Zeitplan mit den Stichtagen im September 2026 und Dezember 2027 ernst nimmt und früh beginnt, vermeidet teure Nacharbeit und macht Sicherheit zum Vorteil statt zur Last.

Ein guter Einstieg ist oft eine kompakte Risikoanalyse oder eine klar abgegrenzte Discovery-Phase, mit der sich Handlungsbedarf und Aufwand mit überschaubarem Einsatz greifbar machen lassen, bevor das große Programm startet.

Wir bei BAYOOTEC verbinden Security by Design mit über 25 Jahren Erfahrung in regulierten und sicherheitskritischen Umfeldern, von der Risikoanalyse über die Architektur bis zum sicheren Betrieb. Hinzu kommt eine außergewöhnlich hohe Umsetzungssicherheit: Alle bislang begonnenen Projekte haben wir erfolgreich in den produktiven Betrieb überführt. Nimm gerne Kontakt mit uns auf und wir vereinbaren einen Termin zum ersten Kennenlernen.