Cyber Resilience Act: Seid ihr Hersteller?
Der CRA macht Sicherheit zur Pflicht für Apps, Software und vernetzte Geräte. Viele kleine Unternehmen haben das noch nicht auf dem Schirm. Hier steht, was gilt und was zu tun ist.
Wenn ihr Software, eine App oder ein vernetztes Gerät in der EU verkauft oder unter eurem Namen anbietet, seid ihr sehr wahrscheinlich Hersteller im Sinne des CRA. Das gilt auch, wenn eine Agentur die App für euch entwickelt hat. Seit dem 11.09.2026 müsst ihr ausgenutzte Sicherheitslücken melden, ab dem 11.12.2027 gelten alle Pflichten.
Was ist der Cyber Resilience Act?
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist ein EU-Gesetz zur Produktsicherheit, ähnlich wie es sie für Spielzeug oder Elektrogeräte schon lange gibt. Nur geht es hier um Produkte mit digitalen Elementen: Desktop- und Mobile-Apps, installierbare Software, Firmware, Smart-Home-Geräte, Industriesteuerungen und vieles mehr.
Als Verordnung gilt der CRA direkt in allen EU-Staaten, ein deutsches Umsetzungsgesetz braucht es dafür nicht.
Die Fristen
| Datum | Was gilt |
|---|---|
| 10.12.2024 | Die Verordnung tritt in Kraft. |
| 11.09.2026 | Meldepflichten gelten: aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle müssen gemeldet werden, auch für Produkte, die schon auf dem Markt sind. |
| 11.12.2027 | Alle Pflichten gelten. Neue Produkte brauchen CE-Kennzeichnung, Konformitätserklärung und technische Dokumentation. |
Wer ist Hersteller?
Hersteller ist, wer ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke anbietet, kostenlos oder gegen Geld. Daraus folgt:
- Das kleine Softwarehaus, das eine eigene App verkauft, ist Hersteller.
- Der Händler, der sich eine Bestell-App bauen lässt und sie seinen Kunden anbietet, ist ebenfalls Hersteller.
- Die Agentur, die im Auftrag programmiert, ist meist nicht Hersteller. Sie muss euch aber liefern können, was ihr für die Pflichten braucht.
Auch Importeure und Händler haben Pflichten, wenn auch weniger umfangreiche.
Was Hersteller tun müssen
- Sicher entwickeln: Sicherheit muss von Anfang an eingeplant sein. Produkte dürfen bei Auslieferung keine bekannten ausnutzbaren Schwachstellen haben und müssen sicher voreingestellt sein.
- Schwachstellen managen: Ihr braucht eine Anlaufstelle, an die Sicherheitsforscher Lücken melden können, und einen Prozess, um diese zu beheben.
- SBOM führen: Eine Software-Stückliste (SBOM) dokumentiert, welche Bibliotheken und Komponenten in eurem Produkt stecken. Nur so wisst ihr, ob eine neue Lücke euch betrifft.
- Updates liefern: Sicherheitsupdates müsst ihr über einen festgelegten Supportzeitraum kostenlos bereitstellen. Der beträgt in der Regel mindestens fünf Jahre, außer das Produkt wird typischerweise kürzer genutzt.
- Melden: Aktiv ausgenutzte Schwachstellen und schwere Vorfälle meldet ihr über die Meldeplattform der ENISA: Frühwarnung in 24 Stunden, Meldung in 72 Stunden, Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur verfügbar ist, bei schweren Vorfällen einen Monat nach der Meldung.
- Dokumentieren und kennzeichnen: Technische Dokumentation, Risikobewertung, EU-Konformitätserklärung und CE-Kennzeichnung. Die Unterlagen müssen zehn Jahre aufbewahrt werden, oder für den Supportzeitraum, falls der länger ist.
Standard, wichtig oder kritisch?
Die meisten Produkte sind Standardprodukte. Für sie reicht eine Selbstbewertung, ihr bestätigt also selbst, dass ihr die Anforderungen erfüllt.
Strengere Regeln gelten für wichtige Produkte wie Passwortmanager, VPN-Software, Betriebssysteme oder Firewalls und für kritische Produkte wie Smartcards oder Smart-Meter-Gateways. Je nach Klasse sind harmonisierte Normen oder eine Prüfung durch eine externe Stelle nötig.
Die ersten Schritte
- Meldeprozess aufsetzen. Die Meldepflicht gilt schon. Legt fest, wer Sicherheitsmeldungen bewertet und wer innerhalb von 24 Stunden an die ENISA meldet.
- Kontaktstelle veröffentlichen. Eine
security.txtauf eurer Website und eine kurze Richtlinie zum Umgang mit gemeldeten Schwachstellen. - SBOM erzeugen. Am besten automatisch bei jedem Build in der CI/CD-Pipeline, zusammen mit einem Schwachstellenscan.
- Supportzeitraum festlegen und intern klären, wie lange ihr Updates liefern könnt.
- Mit eurer Agentur sprechen, falls die App extern entwickelt wird: Wer erzeugt die SBOM, wer reagiert auf Lücken, wer liefert Updates?
Wie Inova Digital unterstützt
Als Softwarehaus kennen wir die Anforderungen aus der Entwicklung. Für unsere Kunden richten wir SBOM-Erzeugung und Schwachstellenscans in der Build-Pipeline ein, schreiben die nötigen Richtlinien und übernehmen auf Wunsch die Sicherheitsupdates über den gesamten Supportzeitraum. Mehr auf unserer Seite IT-Sicherheit.
Dieser Artikel dient der Orientierung und ist keine Rechtsberatung. Stand: Oktober 2026.
Häufige Fragen zum CRA.
In der Regel ja. Hersteller ist, wer ein Produkt entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke anbietet. Die Agentur, die die App programmiert, ist es dann meist nicht. Die Verantwortung liegt bei euch, auch wenn die Umsetzung extern läuft.
Reine Software-as-a-Service fällt grundsätzlich nicht unter den CRA, dafür gelten andere Regeln, etwa aus dem BSI-Gesetz. Gehört aber ein Cloud-Backend zwingend zu einer App oder einem Gerät, damit es funktioniert, kann es als Teil des Produkts erfasst sein.
Open Source, die nicht kommerziell angeboten wird, ist ausgenommen. Wer Open-Source-Komponenten in ein kommerzielles Produkt einbaut, ist aber für das Gesamtprodukt verantwortlich, inklusive dieser Komponenten.
Ja, zumindest teilweise. Die Meldepflichten gelten seit dem 11. September 2026 auch für Produkte, die schon vorher verkauft wurden. Die übrigen Pflichten greifen für Altprodukte erst bei einer wesentlichen Änderung.
Bei Verstößen gegen die grundlegenden Anforderungen bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, was höher ist.
Ihr bietet eine App oder Software an?
Wir schauen gemeinsam, was der CRA für euer Produkt bedeutet und was bis Dezember 2027 passieren muss.