Die erste Frist des Cyber Resilience Act (CRA), die Produktteams betrifft, ist der 11. September 2026, wenn die Meldepflichten beginnen. Die Hauptpflichten folgen am 11. Dezember 2027. Die Meldung hängt von Prozessen und Personen ab, und beides lässt sich nur langsam aufbauen. Deshalb kommt sie vor allem anderen.
Was wann gilt
Der CRA ist die Verordnung (EU) 2024/2847. Laut der CRA-Seite der Europäischen Kommission legt er verbindliche Cybersicherheitsanforderungen für Hersteller fest, und zwar über Planung, Design, Entwicklung und Wartung von Produkten mit digitalen Elementen hinweg. Außerdem verpflichtet er Hersteller, Schwachstellen über den gesamten Produktlebenszyklus zu behandeln.
| Datum | Was passiert |
|---|---|
| 10. Dezember 2024 | CRA ist in Kraft getreten |
| 11. September 2026 | Meldepflichten gelten |
| 11. Dezember 2027 | Hauptpflichten gelten |
Konforme Produkte tragen die CE-Kennzeichnung, und die nationalen Marktüberwachungsbehörden setzen die Regeln durch. Manche Produkte mit besonderer Relevanz für die Cybersicherheit müssen vor dem Verkauf auf dem EU-Markt unter Umständen von einer benannten Stelle (Notified Body) durch Dritte bewertet werden. Klären Sie früh, auf welcher Seite dieser Grenze Ihr Produkt liegt, denn das beeinflusst Ihren Zeitplan.
Die Kommission hat am 27. Juli 2026 außerdem praktische Leitlinien für Hersteller veröffentlicht. Lesen Sie diese, bevor Sie sich bei einem der folgenden Prozesse auf ein Design festlegen.
Nachweise zur sicheren Entwicklung
Aufsichtsbehörden und Kunden werden fragen, was Sie getan haben. Erzeugen Sie die Nachweise deshalb als Nebenprodukt der normalen Arbeit, statt sie später mühsam zu rekonstruieren. Eine anerkannte Struktur hilft dabei.
Das NIST Secure Software Development Framework, SP 800-218, ist ein Kernsatz übergeordneter Praktiken, den Sie zu Ihrem bestehenden SDLC hinzufügen. Seine erklärten Ziele sind weniger Schwachstellen in ausgelieferter Software, geringere Auswirkungen der verbleibenden Schwachstellen und die Behebung von Grundursachen, damit sie nicht erneut auftreten. Zudem liefert es ein gemeinsames Vokabular für den Austausch mit Kunden und Lieferanten. Es ist ein US-Dokument und keine CRA-Checkliste. Betrachten Sie es daher als Gerüst.
Nachweise, die Sie pro Release aufbewahren sollten:
- das Threat Model oder Design-Review, das die Änderung abgedeckt hat
- Code-Review- und Testergebnisse, einschließlich Sicherheitstests
- Abhängigkeitslisten mit Versionen und Ihre Entscheidung zu bekannten Schwachstellen darin
- die Freigabe des Releases mit Name und Datum
Das Material der CISA zu Secure by Design ergänzt zwei praktische Punkte. Die Verantwortung sollte auf Führungsebene liegen, und Standardeinstellungen sind wichtig: MFA, Logging und SSO sollten ohne Aufpreis von Anfang an verfügbar sein. Wenn Ihr Produkt diese Funktionen als kostenpflichtige Zusatzoptionen verkauft, sollten Sie damit rechnen, dass dies hinterfragt wird. Die CISA veröffentlicht außerdem Leitlinien zu Memory-Safe-Roadmaps, die lesenswert sind, wenn Ihr Code in C oder C++ geschrieben ist.
Schwachstellenmanagement und Meldung
Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen melden, ebenso die übrigen Punkte, die auf der Meldeseite der Kommission aufgeführt sind. Prüfen Sie diese Seite auf den genauen Umfang und den zu nutzenden Meldekanal. Verlassen Sie sich nicht auf eine Zusammenfassung, auch nicht auf diese.
Was Sie intern brauchen, unabhängig von den endgültigen Details:
- Eine zentrale Anlaufstelle. Ein überwachter Security-Kontakt auf der Produktwebsite und in der Dokumentation, mit einer namentlich benannten verantwortlichen Person und einer Vertretung.
- Eine Triage-Routine. Jemand entscheidet innerhalb einer festgelegten Frist, ob eine Meldung berechtigt ist, ob die Schwachstelle ausgenutzt wird und welche Produkte und Versionen betroffen sind. Ein einheitlicher Schweregrad beschleunigt das; unser CVSS-Rechner hilft, Bewertungen im Team abzustimmen.
- Ein Entscheidungspfad für die Meldung. Halten Sie schriftlich fest, wer entscheidet, dass eine ausgenutzte Schwachstelle eine Meldung auslöst, und wer sie einreicht. Proben Sie das einmal mit einem fiktiven Fall, wenn nötig außerhalb der Bürozeiten, falls der Ernstfall dann wahrscheinlich eintritt.
- Eine Dokumentation jeder Entscheidung. Auch von Meldungen, die Sie als nicht relevant eingestuft haben, samt Begründung.
Eine Meldung kann nur funktionieren, wenn Sie wissen, was in Ihrem Produkt steckt. Führen Sie für jede ausgelieferte Version ein aktuelles Komponenteninventar, denn die Betroffenheit durch eine neue Schwachstelle lässt sich nicht aus dem Gedächtnis beurteilen.
Update-Prozesse
Die Kommission nennt fehlende zeitnahe Sicherheitsupdates als eines der Probleme, die der CRA adressiert. Produkte müssen so konzipiert, aktualisiert und gewartet werden, dass sie Nutzer schützen. In der Praxis bedeutet das, den Update-Pfad so ernsthaft zu testen wie Ihre Funktionen.
Prüfen Sie Folgendes für jede Produktlinie:
- Sie können einen Sicherheitsfix getrennt von einem Feature-Release ausliefern.
- Kunden erfahren, dass ein Update existiert, und für die Installation ist kein Anruf beim Support nötig.
- Ältere Versionen haben ein ausgewiesenes Support-Ende, das Kunden schon vor dem Kauf einsehen können.
- Bei Hardware haben Sie getestet, ein Gerät zu aktualisieren, das ein Jahr lang offline war, und ein Gerät wiederherzustellen, bei dem das Update auf halber Strecke fehlschlägt.
Die übliche Lücke liegt nicht in der Technik, sondern in der Zuständigkeit. Viele Teams können an einem Tag einen Patch bauen und brauchen dann drei Wochen, um herauszufinden, wer ihn freigeben darf.
Technische Dokumentation
Die von mir herangezogenen Quellen listen die erforderlichen Inhalte der technischen Dokumentation nicht auf. Entnehmen Sie diese daher dem Rechtstext und den Leitlinien der Kommission. Praktisch gilt: Die Dokumentation sollte fortlaufend aus den oben genannten Nachweisen zusammengestellt werden und nicht erst im letzten Quartal vor der Frist entstehen.
Richten Sie für jedes Produkt einen Dokumentationsordner oder einen Repository-Bereich mit einer verantwortlichen Person ein. Legen Sie dort Design und Risikobewertung, Komponenteninventar, Testergebnisse, das Verfahren zum Schwachstellenmanagement und die Update-Richtlinie ab. Versionieren Sie sie zusammen mit dem Produkt. Wenn eine Prüfstelle oder Behörde eine Akte anfordert, sollten Sie diese exportieren können, statt sie erst erstellen zu lassen.
Falls Sie außerdem unter die NIS2-Richtlinie fallen, die der CRA laut Kommission ergänzt, nutzen Sie dieselben Incident- und Schwachstellenprozesse wieder, anstatt zwei getrennte Verfahren zu pflegen.
Wo Sie anfangen
- Lesen Sie die Leitlinien der Kommission vom 27. Juli 2026 und die Meldeseite. Halten Sie schriftlich fest, welche Ihrer Produkte in den Anwendungsbereich fallen und ob manche eine benannte Stelle benötigen könnten.
- Benennen Sie eine verantwortliche Person für die Schwachstellen-Anlaufstelle und die Meldung ausgenutzter Schwachstellen, veröffentlichen Sie einen Security-Kontakt und führen Sie in diesem Quartal eine Übung durch.
- Erstellen Sie für jedes unterstützte Release ein Komponenteninventar und machen Sie dessen Erzeugung zu einem Teil Ihres Builds.
- Gleichen Sie Ihren aktuellen SDLC mit den SSDF-Praktiken ab, dokumentieren Sie die Lücken und beginnen Sie, Review-, Test- und Freigabenachweise pro Release aufzubewahren.
- Testen Sie Ihren Update-Pfad durchgängig und veröffentlichen Sie für jedes Produkt das Support-Ende.
- Legen Sie den Dokumentationsordner pro Produkt an und befüllen Sie ihn mit dem, was Sie bereits haben. Wenn Sie eine externe Sicht auf die Lücken wünschen, decken unsere Beratung und unser Angebot zur sicheren Softwareentwicklung genau das ab.
