Cyber Resilience Act: ab 11. September gilt die Meldepflicht

Der Cyber Resilience Act ist seit Ende 2024 in Kraft, wirkte bisher aber weit weg: Die eigentlichen Pflichten greifen erst Ende 2027. Am 11. September 2026 ändert sich das für einen Teil davon, die Meldepflichten werden verbindlich, und sie sind knapp getaktet.

Stand 19.08.2026 · keine Rechtsberatung

Dieser Beitrag ordnet ein, was aus Verordnungstext und Berichterstattung hervorgeht. Ob und wie du betroffen bist, klärt eine Rechtsberatung, nicht ein Serverblog. Die Fristen und Beträge unten stammen aus der Verordnung und werden von Aufsichtsstellen so kommuniziert.

Was ab September gilt#

Wer ein „Produkt mit digitalen Elementen“ in der EU auf den Markt bringt, muss ab dem 11.09.2026 melden, wenn eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Sicherheitsvorfall bekannt wird:

Frist	Was
24 Stunden	Frühwarnung an ENISA und die zuständige Stelle (in Deutschland CERT-Bund)
72 Stunden	ausführlichere Meldung mit Bewertung
14 Tage	Abschlussbericht nach Bereitstellung von Update oder Umgehungslösung
1 Monat	bei Vorfällen: Abschlussbericht nach der Erstmeldung

Verstöße können mit bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes geahndet werden, der jeweils höhere Wert.

Der Rest des CRA folgt am 11.12.2027: Sicherheitsanforderungen an das Produkt selbst, Konformitätsbewertung, CE-Kennzeichnung, Stückliste der Bestandteile und eine Update-Zusage über den Unterstützungszeitraum.

Wer betroffen ist und wer nicht#

Das ist die Frage, die im Netz am schlechtesten beantwortet wird. Grob:

Betroffen sind Hersteller, also alle, die Software oder vernetzte Geräte unter eigenem Namen in der EU auf den Markt bringen, verkauft oder kostenlos, solange es im Rahmen einer wirtschaftlichen Tätigkeit geschieht. Auch Importeure und Händler haben Pflichten.

Nicht betroffen sind unter anderem:

Der eigene Betrieb. Wer Software nur für sich selbst betreibt, den VPS mit Nextcloud, den Spielserver, das Heimnetz, ist kein Hersteller.
Nicht-kommerzielle freie Software. Rein ehrenamtliche Projekte fallen heraus; für „Open-Source-Verwalter“ (Stewards), die Entwicklung nachhaltig unterstützen, gilt ein abgeschwächter Satz an Pflichten.
Bereiche mit eigener Regulierung, etwa Medizinprodukte, Luftfahrt und Kraftfahrzeuge.

Die Grauzone, die viele betrifft

Zwischen „nur für mich“ und „Produkt“ liegt vieles: das Plugin, das man für kleines Geld verkauft; der Discord-Bot mit Bezahlfunktion; die App mit eigenem Backend; die weitergegebene Appliance. Ob reine Online-Dienste erfasst sind, hängt daran, ob die Fernverarbeitung Teil des Produkts ist, genau diese Abgrenzung gehört in eine Beratung und nicht in eine Faustregel.

Was das für einen Serverbetreiber praktisch heißt#

Auch wer selbst kein Hersteller ist, merkt den CRA, von der anderen Seite:

1. Du bekommst mehr Meldungen. Hersteller müssen ausgenutzte Lücken melden und ihre Nutzer informieren. Das ist gut, erzeugt aber einen Strom von Hinweisen, den jemand lesen muss.

2. Du brauchst eine Adresse, an die man dich erreicht. Wer Software verteilt, braucht eine Anlaufstelle für Sicherheitsmeldungen. Das kostet zehn Minuten:

# /.well-known/security.txt
Contact: mailto:[email protected]
Expires: 2027-12-31T23:59:59.000Z
Preferred-Languages: de, en

3. Du solltest wissen, was du betreibst. Die Stückliste ist ab 2027 eine Herstellerpflicht, für dich ist sie schlicht praktisch, weil du bei der nächsten Lücke in einer verbreiteten Bibliothek in Minuten weißt, ob du betroffen bist.

# Container: was steckt drin?
docker sbom <image>            # bzw. syft <image>
# System: welche Pakete, welche Versionen?
dpkg -l > /opt/doku/pakete-$(date +%F).txt

4. Update-Prozess statt Update-Reflex. Wer in 24 Stunden reagieren können muss, als Hersteller verpflichtend, als Betreiber sinnvoll, braucht einen geübten Weg: Sicherung, Snapshot, Update, Prüfung, Rückweg. Das ist derselbe Ablauf wie in Container-Updates und Datenbank zurückspielen, nur mit Uhr daneben.

Was jetzt konkret zu tun ist#

Prüfen, ob du Hersteller bist. Wenn du irgendetwas Digitales gegen Geld weitergibst: nachfragen, nicht annehmen.
Kontaktweg einrichten (security.txt, Postfach, das jemand liest).
Bestandsliste erzeugen, Pakete, Container-Abbilder, Bibliotheken, Versionen.
Quellen abonnieren für das, was du wirklich betreibst. Ein Sicherheitshinweis nützt nichts, wenn er in einem Postfach landet, das niemand öffnet.
Einen Update-Durchlauf üben, mit Stoppuhr. Die Zahl, die dabei herauskommt, ist deine ehrliche Reaktionszeit.

Häufige Fragen#

Betrifft mich das, wenn ich nur einen VPS für mich betreibe?#

Als Hersteller nein. Als Betreiber bekommst du mehr Meldungen und solltest sie verarbeiten können, mehr nicht.

Ich verkaufe ein kleines Plugin. Bin ich Hersteller?#

Möglicherweise ja. Sobald etwas im Rahmen einer wirtschaftlichen Tätigkeit auf den Markt kommt, ist die Frage ernst zu nehmen. Das ist der Punkt, an dem eine Beratung günstiger ist als ein Bußgeldbescheid.

Gilt der CRA für reine Webdienste?#

Reine Dienste sind grundsätzlich nicht das Ziel der Verordnung, sie zielt auf Produkte. Sobald aber Fernverarbeitung fester Bestandteil eines Produkts ist, wird sie miterfasst. Die Abgrenzung ist Einzelfallfrage.

Was ist mit meinem Open-Source-Projekt?#

Nicht-kommerzielle Projekte sind ausgenommen. Wer daran verdient oder es als Steward professionell trägt, hat abgestufte Pflichten.

Ändert sich am 11. September etwas an meinen Servern?#

Technisch nichts. Was sich ändert, ist die Erwartung an Reaktionszeiten und der Umfang dessen, was gemeldet wird und bei dir ankommt.

Kurz gesagt#

11.09.2026: Meldepflicht für aktiv ausgenutzte Lücken, 24 h, 72 h, 14 Tage.
11.12.2027: der Rest, inklusive CE-Kennzeichnung und Stückliste.
Eigener Betrieb ≠ Hersteller. Verkauf, auch im Kleinen, ändert das möglicherweise.
Jetzt sinnvoll: Kontaktweg, Bestandsliste, geübter Update-Durchlauf.
Bußgeldrahmen bis 15 Mio. € oder 2,5 %, Grund genug, die Frage einmal sauber zu klären.