Cyber Resilience Act: Die Nachweise entstehen beim Bauen oder gar nicht
Seit dem 11. September 2026 haben Hersteller vernetzter Produkte 24 Stunden Zeit, eine aktiv ausgenutzte Schwachstelle zu melden. Nach 72 Stunden sind weitere Angaben fällig, der Abschlussbericht folgt innerhalb von 14 Tagen nach dem Sicherheitsupdate.
Das ist die kleinere der beiden Fristen.
Die größere ist der 11. Dezember 2027. Ab dann muss jedes vernetzte Produkt, das in der EU neu in Verkehr gebracht wird, die Anforderungen des Cyber Resilience Act erfüllen: Sicherheit über den Lebenszyklus, eine Software Bill of Materials, CE-Kennzeichnung und eine technische Dokumentation, die das belegt.
Der entscheidende Teil steht nicht in den Anforderungen, sondern im letzten Wort. Belegt.
Was normalerweise passiert
Eine Frist mit Datum erzeugt ein Projekt. Jemand bekommt den Auftrag, bis 2027 CRA-Konformität herzustellen, holt sich Beratung dazu, und es entsteht ein Arbeitsstrang neben der Entwicklung.
Dieser Strang produziert Dokumente. Er rekonstruiert, was in den letzten Jahren gebaut wurde, welche Komponenten enthalten sind, welche Entscheidungen warum getroffen wurden und wer sie verantwortet hat.
Das ist Archäologie am eigenen Code, und sie ist aus einem Grund teuer, der nichts mit dem Aufwand zu tun hat: Die Antworten sind oft nicht mehr da. Wer vor drei Jahren entschieden hat, dass eine Komponente so und nicht anders eingebunden wird, arbeitet vielleicht nicht mehr im Haus. Was bleibt, ist der Code. Der zeigt, was gemacht wurde, und schweigt darüber, warum.
Und für ein Audit zählt das Warum.
Die Nachweise, die der CRA verlangt, kennt Ihre Entwicklung schon
Sehen Sie sich an, was in einem Revisionsordner landen muss.
Eine Beschreibung dessen, was das Produkt tun soll. Eine Aufstellung dessen, was tatsächlich drin ist. Ein Protokoll darüber, wo Soll und Ist auseinanderlaufen und wie damit umgegangen wurde. Ein Nachweis, dass geprüft wurde, und zwar von wem und wogegen. Eine benannte Verantwortung je Kontrolle.
Das ist keine Compliance-Liste. Das ist die Grundausstattung einer Entwicklung, die weiß, was sie tut.
In einem Modernisierungsvorhaben, das ich derzeit begleite, existieren diese Dinge, und keines davon wurde für ein Audit gebaut.
Eine fachliche Spezifikation liegt strukturiert und versioniert vor, und gegen sie wird entwickelt. Sie ist nicht Dokumentation für Menschen, sondern die Vorgabe, gegen die gebaut und geprüft wird.
Passen Code und Spezifikation nicht zusammen, wird die Spezifikation nicht stillschweigend nachgezogen. Der Unterschied landet in einem Abweichungsregister, mit Soll, Ist, Begründung und Codestelle, und wird mit dem Fachbereich geklärt.
Geprüft wird in mehreren Schichten, die verschiedene Fragen stellen: Stimmt der Code technisch, verhält sich das Verfahren richtig, und kann ein Anwender damit arbeiten.
Und es gibt eine Regel, die festlegt, wo ein Mensch entscheiden muss und an welcher Stelle keine Automatik weiterschieben darf.
Jedes dieser Artefakte ist zugleich ein Auditnachweis. Nicht weil jemand daran gedacht hätte, sondern weil ein Audit dieselbe Frage stellt wie eine gute Entwicklung: Woher wisst ihr, dass es stimmt?
Warum das mit KI im Engineering zwingend wird
Bis vor kurzem war die nachträgliche Rekonstruktion unangenehm und machbar. Ein Mensch, der Code schreibt, hinterlässt Spuren seiner Absicht darin. Variablennamen, Kommentare, Struktur, manchmal sogar die Umwege. Ein erfahrener Entwickler kann daraus zurücklesen, was gedacht war.
Bei maschinell erzeugtem Code funktioniert das schlechter.
Der Code ist sauber. Variablen heißen richtig, die Struktur passt zum übrigen Repository, die Tests sind grün. Was darin nicht steckt, ist eine Absicht, denn es gab keine. Es gab eine Vorgabe und eine Interpretation davon.
Wenn die Vorgabe nirgends festgehalten ist, lässt sich die Interpretation nicht mehr überprüfen. Der Code wird zur einzigen Quelle, und er bestätigt sich selbst.
Für ein Audit ist das der Unterschied zwischen einem Nachweis und einer Behauptung. Sie können zeigen, was das Produkt tut. Sie können nicht zeigen, dass es das tun soll.
Was das für eine Entscheidung heute bedeutet
Bis Dezember 2027 sind es gut vierzehn Monate. Für eine nachträgliche Rekonstruktion ist das wenig.
Die Frage, die ich an dieser Stelle stellen würde, ist nicht, wie man CRA-konform wird. Sie lautet:
Wenn morgen jemand fragt, warum Ihr Produkt sich an einer bestimmten Stelle so verhält und nicht anders, wo steht die Antwort?
Steht sie in einer Spezifikation, ist der Rest Fleißarbeit. Steht sie im Code, ist es ein Projekt. Steht sie in einem Kopf, ist es ein Risiko mit Kündigungsfrist.
In einem früheren Mandat habe ich ein IoT-Vorhaben mit rund fünfundfünfzig Beteiligten und drei Dienstleistern übernommen, das CE- und RoHS-Zertifizierung erreichen musste. Der aufwendigste Teil war nicht die Technik. Es war, nachträglich zu belegen, wer was wann entschieden hatte, über drei Firmengrenzen hinweg.
Das war vor dem CRA. Seitdem ist die Anforderung höher und die Frist fest.
Was ich nicht behaupte
Ich bin kein Rechtsberater. Was hier steht, ist eine Einordnung aus Produktsicht und ersetzt keine Prüfung Ihres konkreten Falls. Die Fristen und Pflichten sind der Verordnung (EU) 2024/2847 und den Veröffentlichungen des BSI zu entnehmen.
Ich habe kein Produkt durch eine CRA-Konformitätsbewertung geführt. Die Verordnung gilt in Teilen erst seit vier Wochen, und bis zur vollen Anwendung sind es über ein Jahr. Wer Ihnen heute Erfahrung damit verspricht, hat sie nicht.
Was ich beschreibe, ist die Arbeit davor: dass die Belege, die ein Audit verlangt, beim Bauen entstehen können statt danach. Dass das billiger ist, ist eine Einschätzung aus Erfahrung, keine gemessene Zahl.
Der Punkt
Ein Audit und eine gute Entwicklung stellen dieselbe Frage. Die eine prüft sie im Nachhinein, die andere beantwortet sie laufend.
Wer die Antwort laufend aufschreibt, hat den Revisionsordner nebenbei. Wer es nicht tut, baut ihn 2027 noch einmal, aus einem Code, der inzwischen nicht mehr sagen kann, warum er so aussieht.
Transparency: this text was revised with AI assistance for grammar and structure. The content, the figures and the decisions are mine.