Cyber Resilience Act: Meldepflichten ab September 2026 vorbereiten

BornCity verweist am 16. August auf neue Unterlagen von ENISA und BSI. Der regulatorische Stichtag für erste CRA-Meldepflichten ist der 11. September 2026.

Aktuelle Meldung

Die aktuelle Meldung macht deutlich, dass technische Entscheidungen nur mit sauberem Inventar, klarer Zuständigkeit und dokumentierter Nachkontrolle belastbar bleiben.

Für den Betrieb zählt nicht die Schlagzeile allein. Die Meldung sollte in den eigenen Bestand, in Verträge und in bestehende Betriebsabläufe eingeordnet werden. Erst danach lässt sich entscheiden, welche Maßnahmen sofort nötig sind und welche regulär geplant werden können.

Einordnung für Unternehmen

Die Verordnung richtet sich primär an Hersteller von Produkten mit digitalen Elementen. Betreiber profitieren dennoch, wenn sie Lieferanten, Supportzusagen und Sicherheitsmeldungen nachvollziehbar bewerten können.

Ein belastbarer Prozess trennt Fakten, Annahmen und Entscheidungen. Quellen liefern den Anlass. Das eigene Inventar, die technische Architektur und dokumentierte Verantwortlichkeiten bestimmen dagegen, ob eine Organisation tatsächlich betroffen ist und wer handeln muss.

Betroffenheit prüfen

Beginnen Sie mit einer vollständigen Sicht auf Produktiv-, Test- und Wiederherstellungsumgebungen. Berücksichtigen Sie dabei Endgeräte, Server, Cloud-Dienste, Dienstkonten und externe Dienstleister. Ein einzelnes Werkzeug liefert selten das ganze Bild; Inventar, zentrale Verwaltung und Vertragsunterlagen ergänzen sich.

1. Produktivsysteme und externe Dienste erfassen.
2. Test-, Staging- und Notfallumgebungen einbeziehen.
3. Privilegierte Konten und Dienstkonten zuordnen.
4. Versionen, Konfigurationen und Updatekanäle abgleichen.
5. Abhängigkeiten zu Lieferanten und Cloud-Diensten dokumentieren.
6. Rückfalloptionen und Wiederherstellungswege prüfen.

Schritt für Schritt umsetzen

1. Produktportfolio und eingesetzte Software mit Verantwortlichen erfassen.
2. Herstellerrolle, Importrolle und Betreiberrolle voneinander trennen.
3. Kontaktweg für Sicherheitsmeldungen und Eskalationen dokumentieren.
4. Schwachstellenmeldungen nach Kritikalität und Ausnutzbarkeit bewerten.
5. Eine 24-Stunden-Erstmeldung organisatorisch vorbereiten.
6. Nachweisbare Freigaben für Updates und Konfigurationsänderungen festlegen.
7. Lieferanten nach Security-Kontakt, Supportzeit und Updateprozess fragen.
8. Software-Stücklisten und Abhängigkeiten dort pflegen, wo sie verfügbar sind.
9. Incident-Übungen mit Technik, Recht und Kundenkommunikation durchführen.
10. Entscheidungen, Zeitstempel und Nachweise revisionsfähig ablegen.

Betrieb und Nachkontrolle

Nach jeder Änderung gehören Funktionstest, Log-Prüfung und eine nachvollziehbare Dokumentation zum Abschluss. Ein Update, eine neue Regel oder ein neues Tool gilt erst dann als sauber umgesetzt, wenn der gewünschte Zustand nachweisbar ist und der Rückweg bekannt bleibt. Kritische Beobachtungen sollten in bestehende Tickets und nicht in private Notizen wandern.

Bewahren Sie die Entscheidung zusammen mit Quelle, Versionsstand, Testumfang und Ergebnis auf. Das spart bei Rückfragen Zeit und hilft bei der nächsten Bewertung. Wenn ein Hersteller seine Hinweise ergänzt, kann das Team den ursprünglichen Kontext nachvollziehen, statt die Änderung aus einzelnen E-Mails und Chat-Nachrichten rekonstruieren zu müssen.

1. Änderung mit Datum und verantwortlicher Person festhalten.
2. Geschäftsfunktionen nach dem Eingriff testen.
3. Fehler- und Sicherheitsprotokolle kontrollieren.
4. Rückmeldungen des Service-Desks erfassen.
5. Offene Restrisiken terminieren und nachverfolgen.

Passende Anleitungen auf S-EDV

1. Kimsuky setzt auf lokale KI: Was Phishing-Schutz jetzt leisten muss
2. OWASP GenAI LLM Top 10 2026: Die zehn größten Sicherheitsrisiken für KI-Anwendungen

Quellen

1. BornCity, 16. August 2026
2. BSI: Cyber Resilience Act
3. EUR-Lex: Verordnung (EU) 2024/2847