Cyber Resilience Act (CRA) in
gewachsener Gerätesoftware umsetzen
Einordnung, Konzept und technische Umsetzung aus einer Hand –
für Hersteller, deren Software über Jahre gewachsen ist.
Der CRA verlangt von Gerätesoftware Eigenschaften, für die sie nie gebaut wurde.
Software-Stückliste, sicherer Update-Weg, ein Prozess für Schwachstellen und Sicherheitsupdates über die gesamte Nutzungsdauer: Das sind keine Formalien auf Papier, sondern Eigenschaften der Software selbst. In Steuerungen, Bediengeräten und Embedded-Systemen, die über zehn oder zwanzig Jahre gewachsen sind, fehlen sie oft – nicht aus Nachlässigkeit, sondern weil sie bisher niemand verlangt hat.
Die meisten Hersteller wissen inzwischen, dass sie handeln müssen. Unklar ist, womit sie anfangen sollen und wie aus regulatorischen Anforderungen konkrete Arbeit an der Software wird.
Qwasaa hilft auf beiden Ebenen. Wir klären mit Ihnen, ob und wie der CRA Ihre Produkte betrifft, und erarbeiten ein Umsetzungskonzept. Und wir passen die Software selbst so an, dass sie die Anforderungen tragen kann.
Was der CRA von Herstellern verlangt
Der Cyber Resilience Act – Verordnung (EU) 2024/2847 – gilt für Produkte mit digitalen Elementen: Hardware und Software, die direkt oder indirekt mit einem Gerät oder Netz verbunden wird. Als Verordnung gilt er unmittelbar in allen EU-Mitgliedstaaten.
Hersteller müssen ihre Produkte über den gesamten Lebenszyklus absichern. Sie dürfen sie nur ohne bekannte ausnutzbare Schwachstellen auf den Markt bringen, müssen Schwachstellen während des Unterstützungszeitraums beheben, eine technische Dokumentation führen und die Konformität mit der CE-Kennzeichnung erklären.
Drei Termine
- 11. Juni 2026: Die Regeln für notifizierte Stellen gelten.
- 11. September 2026: Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle.
- 11. Dezember 2027: Alle Anforderungen gelten. Produkte, die ab dann in Verkehr gebracht werden, brauchen die CE-Kennzeichnung nach CRA.
Eine ausführliche Einführung bietet das Bundesamt für Sicherheit in der Informationstechnik.
Gilt der CRA auch für Geräte, die schon verkauft sind?
Auf den ersten Blick nicht: Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen nur dann unter die Anforderungen, wenn sie danach wesentlich geändert werden (Art. 69 Abs. 2). Für Produktlinien, die seit Jahren gebaut und verkauft werden, greift das aber zu kurz – aus zwei Gründen.
Die Meldepflichten gelten schon jetzt, auch für Bestandsgeräte. Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden – ausdrücklich auch für Produkte, die vor Dezember 2027 auf den Markt kamen (Art. 69 Abs. 3). Wer Geräte im Feld hat, braucht also heute einen Weg, Schwachstellen zu erkennen, zu bewerten und fristgerecht zu melden.
Es zählt jedes einzelne Gerät, nicht das Modell. Die Anforderungen gelten für jedes Produkt in dem Moment, in dem es in Verkehr gebracht wird (Erwägungsgrund 38). Ein Gerätemodell, das seit Jahren gebaut wird und nach dem 11. Dezember 2027 weiter verkauft wird, muss ab dann Stück für Stück den Anforderungen entsprechen.
Für die meisten Hersteller lautet die Frage deshalb nicht, ob der CRA ihre Bestandsprodukte betrifft, sondern welche, in welchem Umfang und bis wann.
Was der CRA in gewachsener Software bedeutet
Die Verordnung legt fest, was erreicht werden muss. Wie das in einer Codebasis gelingt,
die über Jahre gewachsen ist, ist die eigentliche Arbeit und genau die übernehmen wir.
Der CRA verlangt eine Software-Stückliste (SBOM) in einem gängigen maschinenlesbaren Format, mindestens mit den obersten Abhängigkeiten. Sie gehört zur technischen Dokumentation und wird der Marktüberwachung auf Verlangen vorgelegt; veröffentlichen müssen Sie sie nicht. Aufwendig ist selten das Format, sondern das Herausfinden: kopierter Open-Source-Code, Bibliotheken ohne Paketverwaltung, Eigenbauten aus früheren Projektphasen. Wir erfassen, was tatsächlich in Ihrer Software steckt, und richten die SBOM-Erstellung so ein, dass sie mit jedem Build aktuell bleibt.
Schwachstellen müssen sich durch Sicherheitsupdates beheben lassen, Updates müssen sicher verteilt werden, beides unverzüglich, kostenlos und, wo technisch machbar, getrennt von Funktions-Updates. Viele Bestandsgeräte haben dafür keinen vorgesehenen Weg: Updates laufen über den Servicetechniker, einen USB-Stick oder gar nicht. Wir rüsten einen Update-Mechanismus nach, der zu Ihrer Hardware und Ihrem Betrieb passt, zum Beispiel mit signierten Update-Paketen, damit nur freigegebene Software auf das Gerät gelangt.
Produkte dürfen nicht mit bekannten ausnutzbaren Schwachstellen auf den Markt kommen. In gewachsener Software stecken oft Komponenten, für die es keine regulären Sicherheitsupdates mehr gibt. Ein verbreitetes Beispiel: Für Qt 5.15 endete der Standard-Support am 26. Mai 2025; seitdem gibt es nur noch kostenpflichtige Sicherheitspatches für die meisten Qt-Bibliotheken, ohne Drittkomponenten. Wir aktualisieren oder ersetzen solche Abhängigkeiten Schritt für Schritt, bei Qt etwa durch die Migration auf Qt 6.
Hersteller müssen ihre Produkte regelmäßig testen, Schwachstellen unverzüglich beheben, behobene Schwachstellen veröffentlichen und eine Kontaktadresse für Meldungen anbieten. Ein Patch nützt aber nur, wenn er schnell und ohne Nebenwirkungen ausgeliefert werden kann. Dafür gleichen wir neu bekannt werdende Schwachstellen laufend mit Ihrer SBOM ab und sichern Änderungen mit automatisierten Tests ab, damit ein Sicherheitsupdate nicht selbst zum Risiko für die Funktion wird.
Der Unterstützungszeitraum soll widerspiegeln, wie lange ein Produkt voraussichtlich genutzt wird, und beträgt mindestens fünf Jahre. Das Enddatum müssen Sie Ihren Kunden mitteilen, und jedes Sicherheitsupdate muss danach mindestens zehn Jahre verfügbar bleiben. Bei Maschinen und Anlagen, die zehn oder zwanzig Jahre laufen, wird daraus eine technische Frage: Lässt sich die Software in fünfzehn Jahren noch bauen, testen und ausliefern? Wir sichern Build-Umgebung, Werkzeugkette und Abhängigkeiten so, dass die Antwort Ja lautet.
Produkte müssen mit einer sicheren Standardkonfiguration ausgeliefert werden, sich in den Ursprungszustand zurücksetzen lassen, vor unbefugtem Zugriff schützen und möglichst wenig Angriffsfläche bieten, auch an externen Schnittstellen. In älteren Geräten finden sich typischerweise feste Standardpasswörter, offene Debug- und Servicezugänge oder Dienste, die niemand mehr braucht. Wir finden solche Stellen und schließen sie, ohne Service und Wartung im Feld zu blockieren.
CRA-Einordnung und Umsetzungskonzept
Am Anfang steht die Frage, ob und wie der CRA Ihr Unternehmen und Ihre Produkte betrifft. Wir erfassen mit Ihnen den Produktumfang, ordnen die Produkte voraussichtlich ein, zeigen die wichtigsten Lücken und Risiken und erarbeiten gemeinsam ein Konzept, in welcher Reihenfolge Sie vorgehen.
Der Einstieg ist der CRA-Quickstart: in 14 Tagen zum klaren Überblick – mit strukturierter Erfassung des Produktumfangs, voraussichtlicher Einordnung und priorisierten Lücken.
Zur Einordnung: Wir geben eine fachliche Einschätzung und erarbeiten das Konzept mit Ihnen. Eine Rechtsberatung, eine rechtssichere Abnahme oder eine Konformitätsbewertung ersetzt das nicht.
Software CRA-fähig machen
Aus dem Konzept wird Arbeit an der Software. Wir passen Ihre Gerätesoftware an und modernisieren sie dort, wo sie die Anforderungen sonst nicht tragen kann: SBOM, Update-Mechanismus, veraltete Abhängigkeiten, Testabsicherung und sichere Grundeinstellungen.
Wer das Konzept mit Ihnen erarbeitet, kann es danach auch umsetzen. So entsteht kein Bruch zwischen Papier und Code.
Wenn Sie zuerst wissen möchten, wo Ihre Software technisch steht, ist ein Technisches Assessment der passende Einstieg. Wie wir veraltete Abhängigkeiten wie Qt 5 ablösen, lesen Sie unter Softwaremodernisierung, wie wir Änderungen absichern, unter Testautomatisierung.
In welcher Reihenfolge Sie den CRA angehen
Der CRA lässt sich in Etappen umsetzen. Nicht alles muss sofort passieren, einiges ist aber schon fällig.
Produktliste und CRA-Umfang erfassen, Verantwortlichkeiten je Produkt klären, die Ausgangslage belastbar einordnen.
Produkte voraussichtlich einordnen: von Standard, wichtig (Klasse I oder II) oder kritisch, den Konformitätsweg festlegen und weitere geltende Regulierungen berücksichtigen.
Ist und Soll abgleichen, die größten Lücken und Risiken priorisieren und daraus Maßnahmen mit Verantwortlichen und Zeitplan ableiten.
Prozesse für Schwachstellen, Meldungen und Updates aufsetzen, die Software anpassen, Werkzeuge und Schulungen verankern.
Technische Dokumentation und Nachweise strukturieren, die SBOM-Erstellung als laufenden Prozess etablieren.
Konformitätserklärung und Unterlagen vorbereiten und auditfähig ablegen. Die Konformitätsbewertung selbst liegt beim Hersteller und, je nach Produktklasse, bei einer notifizierten Stelle.
Schwachstellen überwachen, Updates bereitstellen, Meldewege einhalten, interne Audits durchführen, damit der CRA nicht nur erreicht, sondern dauerhaft betrieben wird.
Womit anfangen, was kann warten
Schon fällig: ein funktionierender Meldeweg für Schwachstellen und Sicherheitsvorfälle, eine Kontaktadresse für Schwachstellenmeldungen und die Kenntnis der zuständigen Meldestelle. Die Meldepflichten gelten seit dem 11. September 2026.
Jetzt beginnen: Betroffenheit klären, Produkte einordnen, Verantwortliche benennen, die SBOM aufbauen. Bis 11. Dezember 2027: sichere Entwicklung verankern, technische Dokumentation erstellen, Konformitätsbewertung durchführen.
CRA-Fahrplan als PDF herunterladen
Was Ihr Produkt davon hat
Richtig angegangen ist der CRA mehr als Pflichterfüllung. Wer Updates planbar ausliefern kann, muss im Feld seltener improvisieren. Wer seine Abhängigkeiten kennt, kann Software länger pflegen und Geräte länger verkaufen. Eine saubere technische Dokumentation wird zum Nachschlagewerk für das eigene Team, auch wenn Personen wechseln. Und ein nachweislich sicheres, langlebiges Produkt ist im Vertrieb ein Argument, gerade gegenüber Kunden aus kritischen Branchen.
Häufige Fragen zum Cyber Resilience Act
Gilt der CRA für mein Produkt?
Der CRA erfasst Produkte mit digitalen Elementen, deren Zweck eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz einschließt – von vernetzten Geräten über Steuerungen bis zu eigenständiger Software. Ausgenommen sind Produkte, für die eigene EU-Regeln gelten, etwa Medizinprodukte, In-vitro-Diagnostika, Kraftfahrzeuge, nach EU-Luftfahrtrecht zertifizierte Produkte und Schiffsausrüstung. Ob und wie Ihr konkretes Produkt betroffen ist, klären wir im Erstgespräch.
Gilt der CRA auch für Geräte, die schon verkauft sind?
Teilweise. Die Meldepflichten gelten seit dem 11. September 2026 auch für Bestandsgeräte. Die übrigen Anforderungen greifen für Geräte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, nur bei einer wesentlichen Änderung, jedes danach verkaufte Exemplar muss sie aber erfüllen, auch wenn das Modell älter ist.
Was muss in eine SBOM?
Bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen muss innerhalb von 24 Stunden eine Frühwarnung und innerhalb von 72 Stunden eine Meldung erfolgen. Danach folgt ein Abschlussbericht: bei Schwachstellen spätestens 14 Tage, nachdem eine Korrektur verfügbar ist, bei Vorfällen innerhalb eines Monats. Alle Meldungen gehen an das zuständige CSIRT und die ENISA.
Wie lange muss ich Sicherheitsupdates liefern?
Während des Unterstützungszeitraums, den Sie selbst festlegen. Er soll der voraussichtlichen Nutzungsdauer des Produkts entsprechen und beträgt mindestens fünf Jahre. Jedes bereitgestellte Sicherheitsupdate muss danach mindestens zehn Jahre verfügbar bleiben.
Was muss ich seit dem 11. September 2026 melden?
Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle: eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht, bei Schwachstellen spätestens 14 Tage, nachdem eine Korrektur verfügbar ist, bei Vorfällen innerhalb eines Monats. Gemeldet wird an das zuständige CSIRT und die ENISA.
Übernimmt Qwasaa die Konformitätsbewertung?
Nein. Die Konformitätsbewertung liegt beim Hersteller und, je nach Produktklasse, bei einer notifizierten Stelle. Wir schaffen die technischen Voraussetzungen und bereiten die Unterlagen mit Ihnen vor. Eine Rechtsberatung oder rechtssichere Abnahme bieten wir nicht an.
30 Minuten CRA-Einordnung
Buchen Sie einen 30-minütigen Termin. Danach wissen Sie:
- ob der CRA für Ihr Produkt relevant ist,
- ob es für Sie ein überschaubares Thema oder ein echtes Projekt ist,
- wo erfahrungsgemäß die größten Risiken liegen,
- ob und wie ein strukturierter Einstieg sinnvoll ist.
Kein Audit, keine Detailanalyse, sondern eine ehrliche Einordnung. Wenn es passt, starten wir danach gemeinsam in den CRA-Quickstart.
Gemeinsam Klarheit schaffen
Wir klären gemeinsam, ob und wie der CRA Ihre Produkte betrifft, wo Ihre Software heute steht und welcher nächste Schritt sinnvoll ist.
Frank Rub
Chief Executive Officer
Sebastian Kratz
Head of Innovation
Lassen Sie uns starten
Wir freuen uns auf Ihre Anfrage und melden uns innerhalb eines Werktages bei Ihnen.
Mit Betätigung des Absenden-Buttons bestätigen Sie, dass Sie unserer Datenschutzerklärung zustimmen.
Hier finden Sie uns
Unser Zuhause ist die 13. Etage des Jentowers im Herzen der schönen Saalestadt Jena.
Kommen Sie vorbei, wir freuen uns auf Sie.
Karte anzeigen