Cyber Resilience Act: Warum die erste Frist schon im September 2026 fällig ist

Eine Fehleinschätzung hält sich hartnäckig: Der Cyber Resilience Act betreffe Hersteller erst ab Ende 2027. Das stimmt für einen Teil der Pflichten — aber nicht für die erste, und die ist die unangenehmste. Sie greift bereits am 11. September 2026. Das ist, während ich dies schreibe, weniger als ein Vierteljahr entfernt.

Ich halte den CRA nicht für Bürokratie um ihrer selbst willen. Er zwingt eine Branche, die Sicherheit jahrzehntelang als optionales Extra behandelt hat, zu etwas, das in sicherheitskritischen Bereichen längst selbstverständlich ist: nachzuweisen, was man tut. Trotzdem unterschätzen viele, wie früh die Uhr losläuft. Darum dieser Artikel.

Was der CRA verlangt — und ab wann

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist seit Dezember 2024 in Kraft. Er schreibt vor, wie sicher „Produkte mit digitalen Elementen" gegen Angriffe sein müssen — also alles, was Software enthält oder sich mit einem Netzwerk verbindet. Vom smarten Thermostat bis zur Industriesteuerung. Es gibt zwei Stichtage, und man sollte sie nicht verwechseln:

11. September 2026 — die Meldepflicht. Ab diesem Datum muss ich jede aktiv ausgenutzte Schwachstelle und jeden schweren Sicherheitsvorfall innerhalb von 24 Stunden an die zuständigen Stellen melden — an die EU-Agentur ENISA und die nationalen Notfallteams (CSIRTs). Das gilt auch für Produkte, die längst auf dem Markt sind und noch im Support stehen.

11. Dezember 2027 — der Rest. Ab dann muss das Produkt von Grund auf sicher konstruiert sein, über seine Lebensdauer Sicherheitsupdates bekommen, eine vollständige Software-Stückliste vorweisen, eine Konformitätsbewertung durchlaufen und das CE-Zeichen tragen.

Wer beide Daten nebeneinanderlegt, sieht das eigentliche Problem: Melden kann nur, wer weiß, was in seinem Produkt steckt. Und das führt direkt zur unterschätzten Hürde.

Warum die Meldepflicht die eigentliche Hürde ist

Eine Schwachstelle innerhalb von 24 Stunden zu melden klingt nach einer organisatorischen Kleinigkeit. Sie ist es nicht. Um überhaupt beurteilen zu können, ob eine gerade öffentlich gewordene Lücke das eigene Produkt betrifft, brauche ich eine vollständige Liste aller verbauten Software-Bestandteile — die sogenannte SBOM (Software Bill of Materials), die Stückliste für Programmcode. Ohne sie sitze ich bei jeder neuen Schwachstellenmeldung im Dunkeln und rate, ob eine meiner Komponenten betroffen ist.

Das heißt: Die SBOM, die offiziell erst 2027 Pflicht wird, brauche ich faktisch schon im September 2026. Wer erst dann anfängt, seine Abhängigkeiten zu inventarisieren, hat den ersten Ernstfall bereits verloren. Hinzu kommt die schlichte Logistik: Wer bemerkt eine ausgenutzte Lücke, wer bewertet sie, wer meldet sie — und funktioniert diese Kette auch an einem Samstagabend? 24 Stunden sind 24 Stunden.

Ausfallsicherheit und Angriffssicherheit wachsen zusammen

An dieser Stelle wird es für meine Kernarbeit interessant. Ich entwickle seit über drei Jahrzehnten sicherheitskritische Embedded-Software, ein großer Teil davon nach ISO 26262 — der Norm für funktionale Sicherheit in Fahrzeugen. Funktionale Sicherheit fragt: Was passiert, wenn ein Bauteil ausfällt? Der CRA stellt eine zweite Frage daneben: Was passiert, wenn jemand das Gerät absichtlich angreift?

Diese beiden Fragen waren lange getrennte Welten. Sie sind es nicht mehr. Ein anschauliches Beispiel ist der ferngesteuerte Eingriff in einen Jeep Cherokee 2015: Zwei Sicherheitsforscher übernahmen über eine Lücke im Infotainment-System die Kontrolle über Bremsen und Getriebe — aus der Ferne, über das Mobilfunknetz. 1,4 Millionen Fahrzeuge mussten zurückgerufen werden. Jeder Sicherheitsnachweis über die Bremse war damit wertlos, denn die Bremse versagte nicht zufällig, sondern auf Befehl eines Angreifers. Eine Schwachstelle in der Software war zu einem Sicherheitsproblem im Wortsinn geworden.

Genau hier entstehen heute die teuren Lücken: bei Herstellern, die ihre Ausfallsicherheit im Griff haben, die Angriffsseite aber nie systematisch betrachtet haben. Wer ISO 26262 ohne flankierende Security-Betrachtung denkt, schließt seine Argumentationskette nicht mehr.

Was sich in der Firmware konkret ändert

Der CRA wird gern als Juristenthema abgetan. Das halte ich für einen Fehler. Hinter den Vorgaben stehen sehr konkrete Aufgaben für die Firmware — die Steuerungssoftware, die fest im Gerät sitzt. Vier Punkte sind aus meiner Sicht zentral:

Die Software muss verschlüsselt im Gerät liegen. Wer den Programmcode unverschlüsselt aus dem Flash auslesen kann, hat eine offene Tür. Moderne Mikrocontroller bieten dafür Schutzmechanismen — sicheres Auslese-Sperren, signierter Start, schlüsselgebundene Speicherbereiche. Entscheidend ist, sie auch in der Fertigung sauber zu verwalten, statt die Schlüssel auf dem Weg zu verlieren.

Updates müssen fälschungssicher sein. Ein Gerät muss über seine gesamte Lebensdauer Sicherheitsupdates erhalten können — und zwar so, dass niemand untergeschobene Software einspielen kann. Ein Produkt ohne signierten, geprüften Update-Pfad ist ab 2027 schlicht nicht mehr marktfähig.

Jeder Baustein muss bekannt und beobachtet sein. Jede zugekaufte Bibliothek, jeder Baustein des Echtzeit-Betriebssystems, jeder Krypto-Stack gehört in die Stückliste und muss auf bekannte Schwachstellen überwacht werden. Dazu gehört, veraltete Komponenten zu erkennen, die vom ursprünglichen Anbieter nicht mehr gepflegt werden — bevor es eine Behörde tut.

Sauberer Code zahlt sich aus. In sicherheitskritischen Projekten entwickle ich nach strengen Programmierregeln, etwa MISRA-C. Viele dieser Regeln eliminieren genau die undefinierten Verhaltensweisen, aus denen sich später Exploits bauen lassen. Wer von Anfang an so arbeitet, hat einen Teil der CRA-Hausaufgaben bereits erledigt — sollte das aber auch belegen können.

Auch der kleine Hersteller ist „Hersteller"

Ein verbreiteter Trugschluss lautet: Das betrifft nur Konzerne. Falsch. Der CRA gilt für jeden, der ein Produkt mit digitalen Elementen auf dem EU-Markt anbietet — vom Mittelständler bis zum spezialisierten Einzelentwickler. Auch wer Geräte importiert oder weiterverkauft, trägt eigene Pflichten. Und die Bußgelder sind kein Schreckgespenst: Sie reichen bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

Wer bisher dachte, Sicherheit sei eine Option für „spätere Produktversionen", hat diese Wahl nicht mehr.

Was ich Herstellern jetzt rate

Die nächsten Monate entscheiden, ob im September 2026 ein geordneter Ablauf steht oder hektisch improvisiert wird. Mein Rat ist unspektakulär, aber er funktioniert: anfangen. Eine Bestandsaufnahme, welche Produkte betroffen sind und noch betreut werden. Eine erste Software-Stückliste je Produkt. Ein definierter Meldeweg, der die 24-Stunden-Frist organisatorisch wirklich trägt. Und parallel die Firmware härten — als durchdachte Architektur, nicht als nachträglicher Flicken.

Eine ehrliche Selbsteinordnung zum Schluss: Wer einen Stempel sucht, der bescheinigt, dass schon alles passt, ist bei mir falsch. Wer wissen will, wo seine Produkte im September 2026 tatsächlich stehen und was bis dahin in der Firmware zu tun ist, ist richtig.

Fazit

Der CRA ist kein fernes Problem für übermorgen. Die erste verbindliche Frist liegt im September 2026, und sie setzt voraus, dass ich heute schon weiß, was in meinen Produkten steckt. Wer früh anfängt, verteilt die Arbeit und vermeidet teure Schnellschüsse kurz vor der Frist.

Der größte Hebel liegt dabei selten in der Technik allein. Er liegt im sauberen Zusammenspiel von Stückliste, Meldeprozess und Geräte-Absicherung — und darin, Ausfallsicherheit und Angriffssicherheit endlich als ein gemeinsames Konzept zu denken, nicht als zwei getrennte Schubladen. Genau das ist die Brücke, an der ich am liebsten arbeite.