Für viele Unternehmen klingt das Gesetz zur Cyber-Resilienz nach wie vor wie ein Problem des Jahres 2027.

Das ist nicht der Fall.

Das EU-Gesetz zur Cyber-Resilienz (CRA) führt verbindliche Anforderungen an die Cybersicherheit für Hardware- und Softwareprodukte ein, die auf dem EU-Markt in Verkehr gebracht werden. Während die wichtigsten Anforderungen erst ab dem 11. Dezember 2027 gelten, steht eine wichtige Frist bereits viel früher an: Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Sicherheitslücken und schwerwiegende Sicherheitsvorfälle, die ihre Produkte betreffen, melden.

Für Hersteller, Softwareentwicklungsunternehmen und Firmen, die vernetzte Produkte entwickeln, ist das Jahr 2026 somit der Zeitpunkt, an dem der Übergang vom Verständnis der CRA zur operativen Vorbereitung darauf erfolgen muss.

Es stellt sich die Frage: „Können wir nachweisen, wie unser Produkt während seines gesamten Lebenszyklus gesichert, gewartet und betreut wird?“

Was regelt das Gesetz zur Cyber-Resilienz?

Das CRA gilt im Allgemeinen für „Produkte mit digitalen Elementen“, die auf dem EU-Markt bereitgestellt werden. Dies umfasst sowohl Hardware als auch Software sowie separat verkaufte Komponenten.

Dazu können Anwendungen, vernetzte Geräte, eingebettete Software, industrielle Systeme, Netzwerkprodukte und viele der dahinterstehenden Softwarekomponenten gehören.

Die Verordnung rückt die Cybersicherheit näher an das Produkt selbst heran. Sicherheit wird nicht mehr nur auf der Ebene der Infrastruktur oder der Unternehmens-IT berücksichtigt. Von den Herstellern wird erwartet, dass sie die Cybersicherheit bereits bei der Planung, Konzeption, Entwicklung, Produktion, Auslieferung und Wartung berücksichtigen.

Mit anderen Worten: Mit der Markteinführung des Produkts endet die Verantwortung nicht.

Hersteller müssen zudem Schwachstellen beheben, Sicherheitsupdates bereitstellen und während des festgelegten Supportzeitraums des Produkts für angemessene Cybersicherheit sorgen.

Es gibt Ausnahmen und branchenspezifische Wechselwirkungen, insbesondere bei Produkten, die bereits unter andere EU-Rechtsrahmen fallen. Unternehmen sollten daher die genaue Einstufung ihrer Produkte mit qualifizierten Rechts- oder Compliance-Beratern abklären.

Der erste wichtige Termin: 11. September 2026

Ab dem 11. September 2026 sind Hersteller verpflichtet, aktiv ausgenutzte Sicherheitslücken und schwerwiegende Vorfälle, die die Sicherheit von Produkten mit digitalen Komponenten beeinträchtigen, zu melden.

Eine Erstmeldung muss in der Regel innerhalb von 24 Stunden nach Bekanntwerden des Vorfalls erfolgen, gefolgt von einer ausführlicheren Meldung innerhalb von 72 Stunden. Die weitere Berichterstattung richtet sich danach, ob es sich bei dem Vorfall um eine ausgenutzte Sicherheitslücke oder um einen schwerwiegenden Vorfall handelt.

Die Meldung erfolgt über die von der ENISA betriebene einheitliche Meldeplattform der EU.

Für ein Ingenieurbüro wirft dies praktische Fragen auf, die sich nicht dadurch lösen lassen, dass man eine Richtlinie erst in der Woche vor Ablauf der Frist verfasst.

Wer entdeckt die Sicherheitslücke? Wer ermittelt, welche Versionen betroffen sind? Wer hat Zugriff auf die entsprechenden Protokolle? Wer kontaktiert die Sicherheitsabteilung, die Geschäftsleitung und die Compliance-Abteilung? Kann das Team nachvollziehen, welche Änderungen in der letzten Version vorgenommen wurden? Gibt es einen klar definierten Verantwortlichen, der für die Einleitung des Meldeprozesses zuständig ist?

Sollte die Beantwortung dieser Fragen eine mehrtägige interne Untersuchung erfordern, handelt es sich um ein betriebliches und nicht um ein rechtliches Problem.

Was ändert sich im Dezember 2027?

Die Hersteller müssen nachweisen, dass Cybersicherheitsrisiken während des gesamten Lebenszyklus des Produkts berücksichtigt wurden.

Dazu gehören Grundsätze wie die Entwicklung nach dem „Secure-by-Design“-Prinzip, sichere Standardkonfigurationen, Zugriffskontrolle, der Schutz der Vertraulichkeit und Integrität, der Umgang mit Sicherheitslücken, sichere Updates sowie ein angemessener Schutz vor unbefugtem Zugriff.

Entwicklungsteams sind viele dieser Ideen bereits bekannt.

Der Unterschied besteht darin, dass Vorgehensweisen, die bisher als bewährte Verfahren im Ingenieurwesen galten, zunehmend Teil eines formellen Rahmens für die Produktkonformität werden.

Ein Produkt, das ordnungsgemäß funktioniert, ist daher nicht zwangsläufig ein Produkt, das für die CRA bereit ist.

Die Entwicklungsorganisation muss zudem ihre Abhängigkeiten verstehen, wissen, wie mit Schwachstellen umgegangen wird, eine angemessene technische Dokumentation führen und in der Lage sein, die dem System zugrunde liegenden Entscheidungen und Kontrollmaßnahmen nachzuweisen.

Was sollten Produktunternehmen ab sofort unternehmen?

Wenn man mit der Einführung dieser Verfahren bis 2027 wartet, entsteht unnötiger Druck.

Eine praxisorientierte Vorbereitung auf die CRA sollte bei den technischen Grundlagen ansetzen:

• Ermitteln Sie, welche Produkte und Versionen möglicherweise unter die CRA fallen
• Softwarekomponenten und deren Abhängigkeiten abbilden
• Verfahren zur Überwachung von Sicherheitslücken und zur Eskalation einrichten
• die Nachverfolgbarkeit der Entwicklungs- und Produktionszugriffe sicherstellen
• Dokumentarchitekturen und sicherheitsrelevante Entscheidungen
• wiederholbare Verfahren für die Installation von Patches und Updates einführen
• sicherzustellen, dass Releases nachvollziehbar und wiederherstellbar sind
• Festlegung der Zuständigkeiten für Vorfälle und die Meldung
• Überprüfung der Protokollierungs-, Überwachungs-, Sicherungs- und Wiederherstellungsverfahren
• die Bewertung von Cybersicherheitsrisiken in die Produktentwicklung integrieren

Das Ziel besteht nicht darin, Dokumentation um der Dokumentation willen zu erstellen.

Das Ziel besteht darin, das System so verständlich zu gestalten, dass das Entwicklerteam, wenn im Zusammenhang mit einer Sicherheitslücke, einer Kundenbefragung, einem Audit oder einer Anfrage der Aufsichtsbehörde Fragen aufkommen, diese mit Belegen beantworten kann, anstatt die Sachlage im Nachhinein rekonstruieren zu müssen.

Wo ein Softwareentwicklungspartner wie Ascendro ins Spiel kommt

Für Unternehmen, die auf externe Entwicklungsressourcen zurückgreifen, hat die CRA-Bereitschaft zudem Auswirkungen darauf, wie Softwarepartner bewertet werden sollten.

Technische Kompetenz ist nach wie vor wichtig, stellt jedoch nicht mehr das gesamte Bild dar.

Ein Entwicklungspartner sollte in der Lage sein, zu erläutern, wer Zugriff auf Ihre Systeme hat, wie dieser Zugriff kontrolliert wird, wie Codeänderungen nachverfolgt werden, wie Abhängigkeiten verwaltet werden, wie Vorfälle in der Produktion behandelt werden und welche Dokumentation hinter dem Produkt steht.

An dieser Stelle kommt die bestehende Arbeitsweise von Ascendro ins Spiel.

Wir entwickeln und betreiben Software in Branchen wie der Automobilindustrie, der Fertigungsindustrie, dem Fintech-Bereich und dem Gesundheitswesen, in denen Sicherheit, Rückverfolgbarkeit und kontrollierte Prozesse bereits seit Jahren fester Bestandteil der Kundenanforderungen sind.

Ascendro verfügt über Zertifizierungen nach ISO 27001, ISO 9001 und TISAX. Das bedeutet, dass dokumentierte Prozesse, Maßnahmen zur Informationssicherheit, kontrollierter Zugriff und überprüfbare Arbeitsabläufe keine Praktiken sind, die wir erst jetzt einführen, weil die CRA-Prüfung bevorsteht. Sie sind bereits fester Bestandteil des Umfelds, in dem unsere Teams Software bereitstellen.

Wenn wir ein Produkt entwickeln oder weiterentwickeln, erstreckt sich diese Disziplin auf die Architekturdokumentation, die Entwicklungsumgebungen, die Bereitstellungsprozesse, das Abhängigkeitsmanagement, die Überwachung, die Datensicherung und -wiederherstellung sowie den langfristigen Softwarebetrieb.

Wir sind weder Rechtsberater noch eine CRA-Zertifizierungsstelle. Fragen dazu, ob ein bestimmtes Produkt unter die CRA fällt oder welches Konformitätsverfahren anzuwenden ist, sollten mit den entsprechenden Rechts- und Regulierungsspezialisten geklärt werden.

Unsere Aufgabe liegt im technischen Bereich: Wir unterstützen bei der Entwicklung von Software, damit Sicherheit, Rückverfolgbarkeit und Wartbarkeit von Anfang an Teil des Produkts sind und nicht erst vor einem Audit nachträglich hergestellt werden müssen.

Dieser Artikel dient ausschließlich zu Informationszwecken und stellt keine rechtliche oder aufsichtsrechtliche Beratung dar. Die Verpflichtungen im Rahmen der CRA hängen vom jeweiligen Produkt, der jeweiligen Rolle und den jeweiligen Umständen ab. Unternehmen sollten sich hinsichtlich ihrer individuellen Verpflichtungen an qualifizierte EU-Rechts- oder Compliance-Experten wenden.