Am 11. September 2026 greift die erste verbindliche Stufe des Cyber Resilience Act. Das BSI formuliert es unmissverständlich: „Eine erste Stufe des Cyber Resilience Acts greift bereits am 11. September 2026. Dann müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf das Produkt melden.“ [13]
Der teure Irrtum liegt in der Jahreszahl. Viele Hersteller haben sich den 11. Dezember 2027 notiert und planen bis dahin. Artikel 14 gilt aber schon 15 Monate früher — und er gilt nicht nur für neue Produkte. Er erfasst Ihre bereits ausgelieferte Basis. Wer 2019 eine vernetzte Steuerung in den Markt gebracht hat, muss ab September 2026 eine aktiv ausgenutzte Schwachstelle darin innerhalb von 24 Stunden melden.
Für deutsche Hersteller kommt eine zweite Schicht hinzu: Viele von ihnen sind seit dem NIS2-Umsetzungsgesetz zugleich wichtige oder besonders wichtige Einrichtung. Dann laufen zwei Meldepflichten mit zwei 24-Stunden-Uhren nebeneinander. Dieser Leitfaden ordnet beide Regime, zeigt, welcher Vorfall welchen Meldeweg auslöst, und welche NIS2-Arbeit für den CRA wiederverwendbar ist.
Fallen Sie unter beide Regelwerke? Der Schnelltest
Kurz gesagt: NIS2 knüpft an Ihre Größe und Ihre Branche an. Der CRA knüpft an Ihr Produkt an. Beides kann gleichzeitig zutreffen — und das ist bei Maschinen-, Anlagen- und Komponentenherstellern eher die Regel als die Ausnahme.
Lesen Sie sich gerade in NIS2 ein? Prüfen Sie Ihre Lücken direkt mit.
Die kostenlose NIS2-Selbsteinschätzung — über 90 prüfbare Punkte zu Art. 21 / § 30 BSIG. Sofort als PDF.
Der CRA definiert „Hersteller“ weit. Erfasst ist, wer Produkte mit digitalen Elementen entwickelt oder entwickeln lässt und sie unter eigenem Namen oder eigener Marke vermarktet — laut Artikel 3 Nummer 13 ausdrücklich auch dann, wenn dies unentgeltlich geschieht [7]. Ein „Produkt mit digitalen Elementen“ ist jedes Hard- oder Softwareprodukt, dessen bestimmungsgemäße Nutzung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz einschließt [8]. Wer eine Komponente unter fremder Marke zuliefert, ist insoweit nicht Hersteller im Sinne des CRA — die Pflicht trifft den, dessen Name auf dem Produkt steht.
| Prüffrage | Trifft zu? | Folge |
|---|---|---|
| Vermarkten Sie ein Hard- oder Softwareprodukt mit Datenverbindung unter eigenem Namen in der EU? | Ja | CRA-Herstellerpflichten (Art. 13, 14, Anhang I) |
| Fällt Ihr Unternehmen unter Anlage 1 oder 2 BSIG und überschreitet die Größenschwellen? | Ja | NIS2-Pflichten (§ 30 ff. BSIG) |
| Beides? | Ja | Zwei parallele Regime, zwei Meldewege — siehe unten |
| Nur Zulieferer unter fremder Marke, kein eigenes Endprodukt? | Ja | Kein CRA-Hersteller; aber Art. 13 Abs. 6 verpflichtet Ihre Abnehmer, Schwachstellen an Sie zu melden |
Artikel 2 nimmt einige Produktwelten ausdrücklich aus: Medizinprodukte nach den Verordnungen (EU) 2017/745 und 2017/746, Kraftfahrzeuge nach der Verordnung (EU) 2019/2144, Zivilluftfahrt nach der Verordnung (EU) 2018/1139, Schiffsausrüstung nach der Richtlinie 2014/90/EU sowie Ersatzteile, die nach denselben Spezifikationen wie das ersetzte Bauteil gefertigt werden [8]. Wer in diesen Sektoren produziert, prüft die sektorspezifische Regelung — nicht den CRA.
NIS2 und CRA im direkten Vergleich
Die beiden Rechtsakte regeln unterschiedliche Ebenen desselben Risikos. NIS2 fragt: Ist Ihre Organisation widerstandsfähig? Der CRA fragt: Ist Ihr Produkt es? Wer die Unterscheidung sauber zieht, spart sich später die teuersten Fehler — nämlich die doppelte oder die unterbliebene Meldung.
| Kriterium | NIS2 / BSIG | Cyber Resilience Act |
|---|---|---|
| Rechtsnatur | Richtlinie, national umgesetzt (NIS2UmsuCG, BSIG) | Verordnung (EU) 2024/2847 — unmittelbar geltend [12] |
| Regelungsgegenstand | Die Einrichtung und ihre Dienste | Das Produkt und sein Lebenszyklus |
| Adressat | Besonders wichtige und wichtige Einrichtungen | Hersteller, Einführer, Händler |
| Kernpflicht | Risikomanagement, § 30 Abs. 2 Nr. 1–10 BSIG [15] | Grundlegende Anforderungen, Anhang I Teil I und II [11] |
| Nachweis | Managementsystem, Dokumentation, Aufsicht | Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation [10] |
| Meldung an | Gemeinsame Meldestelle von BSI und BBK [16] | CSIRT-Koordinator und ENISA über die zentrale Meldeplattform [2] |
| Bußgeldrahmen | Bis 10 Mio. € / 2 % bzw. 7 Mio. € / 1,4 % [18] | Bis 15 Mio. € / 2,5 % [4] |
Die Rolle des BSI wächst dadurch erheblich. Der Regierungsentwurf für ein CRA-Durchführungsgesetz (BT-Drucksache 21/6134 vom 26. Mai 2026 [19]) weist dem BSI die zentrale Marktüberwachung sowie die Notifizierung der Konformitätsbewertungsstellen zu; das Kabinett hat den Entwurf am 29. April 2026 beschlossen, die erste Lesung im Bundestag fand am 11. Juni 2026 statt [20][21]. Das Gesetz befindet sich damit noch im parlamentarischen Verfahren. Ein praktischer Hinweis für alle, die den Entwurf zitieren: Die dort genannten Paragrafen sind Entwurfsnummern („BSIG-E“). Im aktuell geltenden BSIG ist § 65 die Bußgeldvorschrift [18] — die Nummerierung des Entwurfs sollte also nicht ungeprüft als geltendes Recht übernommen werden.
Der 11. September 2026: Die Meldepflicht erfasst auch Ihre ausgelieferte Basis
Artikel 71 legt drei Termine fest: Die Verordnung gilt ab dem 11. Dezember 2027, Artikel 14 jedoch bereits ab dem 11. September 2026 und Kapitel IV (Artikel 35 bis 51) ab dem 11. Juni 2026 [1]. Der CRA ist am 10. Dezember 2024 in Kraft getreten [10].
Entscheidend ist, was Artikel 14 ab September 2026 abdeckt. Die Meldepflichten gelten für Produkte, die auf dem Unionsmarkt bereitgestellt wurden — einschließlich solcher, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden [10]. Ihre installierte Basis ist damit ab September 2026 meldepflichtig, obwohl sie die grundlegenden Anforderungen des Anhangs I noch gar nicht erfüllen muss. Das ist die Asymmetrie, die in den meisten Projektplänen fehlt: Meldepflicht zuerst, Produktanforderungen später.
Artikel 14 verlangt zwei getrennte Meldestrecken, beide dreistufig, beide an den CSIRT-Koordinator und ENISA über die zentrale Meldeplattform nach Artikel 16 [2]:
| Stufe | Aktiv ausgenutzte Schwachstelle | Schwerwiegender Sicherheitsvorfall |
|---|---|---|
| Frühwarnung | 24 Stunden ab Kenntnis | 24 Stunden ab Kenntnis |
| Meldung | 72 Stunden | 72 Stunden |
| Abschlussbericht | 14 Tage | 1 Monat |
„Aktiv ausgenutzt“ ist enger definiert, als es im Alltag oft verstanden wird: Artikel 3 Nummer 42 verlangt belastbare Belege dafür, dass ein böswilliger Akteur die Schwachstelle in einem System ohne Erlaubnis des Systeminhabers ausgenutzt hat [7]. Eine veröffentlichte CVE ohne Ausnutzungsnachweis löst die 24-Stunden-Uhr nicht aus. Ein Kundenhinweis auf ein kompromittiertes Gerät hingegen sehr wohl — und ab diesem Moment zählt die Frist.
Hinzu kommt eine Pflicht, die Marketing und Support betrifft: Hersteller müssen betroffene Nutzer zeitnah über die Schwachstelle, den Vorfall und mögliche Gegenmaßnahmen informieren; wo der Hersteller dies unterlässt, kann der CSIRT die Nutzer selbst informieren [2]. Wer keine gepflegte Kontaktliste seiner Betreiber hat, hat hier ein operatives Problem, kein juristisches.
Für Kleinstunternehmen und kleine Unternehmen sieht Artikel 64 Absatz 10 Buchstabe a eine eng gefasste Erleichterung vor: Für die Versäumung der Frist nach Artikel 14 Absatz 2 Buchstabe a beziehungsweise Absatz 4 Buchstabe a — also der 24-Stunden-Frühwarnung — werden keine Geldbußen verhängt [4]. Die Meldepflicht selbst entfällt dadurch nicht.
Zwei Meldewege, ein Vorfall: Doppelmeldung und Meldelücke vermeiden
Hier entsteht der eigentliche Umsetzungsaufwand für Unternehmen, die beide Rollen tragen. Beide Regime kennen eine 24-Stunden-Frühwarnung, aber sie fragen nach Unterschiedlichem und gehen an unterschiedliche Adressaten. § 32 BSIG fragt: Was ist meiner Einrichtung passiert? Artikel 14 CRA fragt: Was ist meinem ausgelieferten Produkt passiert? [16][2]
Die folgende Zuordnung ist eine praktische Auslegungshilfe, keine gesetzliche Vorgabe — sie ergibt sich aus dem jeweiligen Regelungsgegenstand der beiden Vorschriften:
| Auslöser | § 32 BSIG | Art. 14 CRA |
|---|---|---|
| Ransomware legt Ihre eigene Fertigungs-IT lahm | Ja — erheblicher Sicherheitsvorfall | Nein, sofern kein ausgeliefertes Produkt betroffen ist |
| Aktiv ausgenutzte Schwachstelle in Ihrer ausgelieferten Steuerung | Nein, sofern Ihr eigener Betrieb unbeeinträchtigt bleibt | Ja — 24 / 72 Stunden / 14 Tage |
| Angreifer kompromittiert Ihren Update-Server und verteilt manipulierte Firmware | Ja | Ja — beide Meldewege parallel |
| Schwachstelle in einer zugekauften Open-Source-Bibliothek Ihres Produkts | Nein | Nur bei belegter aktiver Ausnutzung; zusätzlich Meldung an den Komponentenverantwortlichen nach Art. 13 Abs. 6 [3] |
Die dritte Zeile ist der Fall, an dem Prozesse scheitern. Ein kompromittierter Update-Server ist gleichzeitig ein Vorfall in Ihrer Einrichtung und ein Vorfall mit Auswirkung auf das Produkt. Beide Uhren starten im selben Moment, aber die Berichte gehen an verschiedene Stellen, folgen verschiedenen Endfristen (ein Monat nach § 32 BSIG, 14 Tage nach Artikel 14 bei Schwachstellen) und dürfen sich inhaltlich nicht widersprechen. Praktisch heißt das: eine Vorfallaufnahme, zwei Ausleitungen — und eine benannte Person, die bei jedem Vorfall beide Fragen stellt. Wie die NIS2-Seite dieser Kette aufgebaut wird, beschreiben wir ausführlich unter NIS2-Meldepflichten.
Was Ihre NIS2-Umsetzung für den CRA schon leistet — und was nicht
Die gute Nachricht zuerst: Zwei der zehn Maßnahmen aus § 30 Absatz 2 BSIG zielen bereits auf produktnahe Sicherheit. Nummer 4 verlangt Lieferkettensicherheit einschließlich der Beziehungen zu unmittelbaren Anbietern, Nummer 5 verlangt „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen“ [15]. Wer das ernsthaft umgesetzt hat, besitzt bereits den organisatorischen Unterbau für Anhang I Teil II des CRA.
| CRA-Anforderung | Deckung durch NIS2-Arbeit | Aufwand zum Schließen |
|---|---|---|
| Coordinated Vulnerability Disclosure, Kontaktadresse | Weitgehend — § 30 Abs. 2 Nr. 5 BSIG [15] | Gering |
| Sorgfaltspflicht bei Fremd- und Open-Source-Komponenten (Art. 13 Abs. 5 [3]) | Teilweise — § 30 Abs. 2 Nr. 4 BSIG deckt Anbieter, nicht Code-Herkunft [15] | Mittel |
| SBOM in maschinenlesbarem Format, mindestens Top-Level-Abhängigkeiten [11] | Keine — NIS2 kennt keine SBOM-Pflicht | Hoch |
| Produkteigenschaften nach Anhang I Teil I (sichere Voreinstellung, Angriffsflächenreduktion, Verschlüsselung) [11] | Keine — das ist Produktentwicklung, kein ISMS | Hoch |
| Supportzeitraum von mindestens fünf Jahren (Art. 13 Abs. 8 [3]) | Keine — betrifft Produktstrategie und Kalkulation | Hoch |
| Konformitätsbewertung und CE-Kennzeichnung [10] | Keine | Hoch |
Die Verbindung wirkt auch in die andere Richtung, und zwar zugunsten Ihrer Kunden. Erwägungsgrund 24 des CRA — ein Erwägungsgrund ist eine Auslegungshilfe und begründet selbst keine Pflicht — beschreibt als Ziel, die Einhaltung der Lieferkettenanforderungen der Richtlinie (EU) 2022/2555 durch Anbieter digitaler Infrastruktur zu erleichtern [9]. Ihre NIS2-pflichtigen Abnehmer müssen nach Artikel 21 Absatz 3 die Qualität der Produkte und Sicherheitspraktiken ihrer unmittelbaren Anbieter bewerten, einschließlich deren sicherer Entwicklungsverfahren [14]. CRA-Konformität wird damit absehbar zum Vertriebsargument, lange bevor sie zur Rechtspflicht wird. Wir behandeln das ausführlich unter NIS2-Lieferkettensicherheit und sichere Entwicklung.
Produktklassen: Warum die Einstufung über Ihren Aufwand entscheidet
Kurz gesagt: Die meisten Produkte darf der Hersteller selbst bewerten. Sobald ein Produkt in Anhang III fällt, wird die Selbstbewertung eingeschränkt oder unmöglich — und damit teuer.
Nach Artikel 7 gilt ein Produkt als „wichtiges Produkt mit digitalen Elementen“, wenn seine Kernfunktion einer Kategorie des Anhangs III entspricht. Maßgeblich ist, ob das Produkt vorrangig Funktionen erfüllt, die für die Cybersicherheit anderer Produkte, Netze oder Dienste kritisch sind, oder ob seine Funktion ein erhebliches Risiko nachteiliger Auswirkungen birgt [6].
| Klasse | Beispiele | Konformitätsbewertung nach Art. 32 [5] |
|---|---|---|
| Standardprodukte | Der überwiegende Teil vernetzter Produkte | Modul A (interne Kontrolle), alternativ B+C oder H |
| Anhang III Klasse I | Passwortmanager, VPN, Netzmanagement, SIEM, Betriebssysteme, Router und Switches, vernetzte Spielzeuge [11] | Modul A nur bei vollständiger Anwendung harmonisierter Normen; sonst B+C oder H |
| Anhang III Klasse II | Hypervisoren und Container-Laufzeiten, Firewalls, IDS/IPS, manipulationssichere Mikroprozessoren und Mikrocontroller [11] | B+C, H oder Zertifizierung auf Stufe „substanziell“ — kein Modul A |
| Kritische Produkte (Anhang IV) | Eng begrenzter Kreis | Europäisches Zertifizierungsschema oder die Verfahren der Klasse II |
Freie und quelloffene Software darf das Standardverfahren nutzen, wenn die technische Dokumentation zum Zeitpunkt des Inverkehrbringens öffentlich verfügbar ist [5]. Die Einstufung ist die wirtschaftlich folgenreichste Einzelentscheidung im gesamten CRA-Projekt — sie sollte am Anfang stehen, nicht am Ende. Zur europäischen Systematik technischer Anforderungen siehe auch unseren Leitfaden zur NIS2-Durchführungsverordnung.
Bußgelder: Zwei Regime, zwei Obergrenzen
| Verstoß | Obergrenze |
|---|---|
| CRA: Grundlegende Anforderungen nach Anhang I sowie Pflichten aus Art. 13 und 14 [4] | 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes — der höhere Wert |
| CRA: Pflichten aus Art. 18–23, 28, 30, 31, 32, 33 Abs. 5, 39, 41, 47, 49, 53 [4] | 10 Mio. € oder 2 % |
| CRA: Unrichtige, unvollständige oder irreführende Angaben gegenüber notifizierten Stellen und Marktüberwachungsbehörden [4] | 5 Mio. € oder 1 % |
| BSIG: Besonders wichtige Einrichtungen [18] | 10 Mio. € oder 2 % |
| BSIG: Wichtige Einrichtungen [18] | 7 Mio. € oder 1,4 % |
Ein Unterschied wird in der Vorstandskommunikation oft übersehen. Der CRA sieht keine dem § 38 BSIG entsprechende persönliche Haftung der Geschäftsleitung vor. Nach § 38 BSIG haften Geschäftsleitungen ihrer Einrichtung für die Verletzung der Pflicht, die Risikomanagementmaßnahmen nach § 30 umzusetzen und zu überwachen — nach den gesellschaftsrechtlichen Regeln der jeweiligen Rechtsform; hinzu kommt eine regelmäßige Schulungspflicht [17]. Die persönliche Ebene bleibt also NIS2-getrieben, die Unternehmensebene wird durch den CRA teurer. Mehr dazu unter Geschäftsführerhaftung nach NIS2 und NIS2-Bußgelder.
Fahrplan: Was bis wann zu tun ist
| Termin | Was gilt | Wer handelt |
|---|---|---|
| 11. Juni 2026 (erfolgt) | Kapitel IV, Art. 35–51: Rahmen für notifizierte Stellen [1] | Konformitätsbewertungsstellen |
| 11. September 2026 | Art. 14 Meldepflichten — auch für die bestehende Produktbasis [1][10] | Produktsicherheit, Support, Geschäftsleitung |
| 11. Dezember 2027 | Vollständige Geltung: Anhang I, Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation [1][10] | Entwicklung, Qualitätsmanagement, Vertrieb |
Für die verbleibenden Wochen bis September 2026 ist die Reihenfolge eindeutig. Erstens: Produktinventar erstellen — welche Produkte mit digitalen Elementen sind unter Ihrem Namen im Markt, und seit wann? Zweitens: eine meldefähige Rolle benennen, die 24 Stunden erreichbar ist, und den Zugang zur Meldeplattform vorbereiten. Drittens: die Auslöseprüfung dokumentieren, mit der bei jedem Vorfall beide Fragen beantwortet werden — Einrichtung oder Produkt oder beides. Viertens, und erst danach: SBOM, Supportzeitraum und Konformitätsbewertung für den Horizont 2027. Wer die Reihenfolge umdreht, ist im September mit einer schönen SBOM und ohne funktionierenden Meldeweg ausgestattet.
Häufige Fragen
Gilt der CRA auch für Software, die wir kostenlos abgeben?
Ja. Artikel 3 Nummer 13 erfasst die Vermarktung unter eigenem Namen oder eigener Marke ausdrücklich auch dann, wenn sie unentgeltlich erfolgt [7]. Für Open-Source-Software-Verwalter sieht Artikel 64 Absatz 10 Buchstabe b allerdings eine Ausnahme von Geldbußen vor [4].
Wie lange müssen wir Sicherheitsupdates liefern?
Der Supportzeitraum beträgt nach Artikel 13 Absatz 8 mindestens fünf Jahre; ist die erwartete Nutzungsdauer kürzer, entspricht er dieser. Jedes ausgelieferte Sicherheitsupdate muss anschließend mindestens zehn Jahre oder für den Rest des Supportzeitraums verfügbar bleiben — je nachdem, welcher Zeitraum länger ist [3].
Ersetzt eine CRA-Meldung die Meldung nach § 32 BSIG?
Nein. Die beiden Meldepflichten haben unterschiedliche Auslöser, Adressaten und Endfristen [2][16]. Betrifft ein Vorfall sowohl Ihre Einrichtung als auch Ihr ausgeliefertes Produkt, sind beide Meldungen abzugeben.
Wir sind nur Zulieferer. Betrifft uns der CRA?
Als Hersteller im Sinne des CRA nur, wenn Sie unter eigenem Namen vermarkten [7]. Mittelbar betrifft er Sie in jedem Fall: Ihre Abnehmer müssen nach Artikel 13 Absatz 5 Sorgfalt bei integrierten Fremdkomponenten walten lassen und Schwachstellen an Sie melden [3] — und werden entsprechende Zusagen vertraglich einfordern.
Brauchen wir für den CRA ein neues Managementsystem?
In der Regel nicht. Der organisatorische Teil, insbesondere Schwachstellenbehandlung und Offenlegung, lässt sich auf der Struktur nach § 30 Absatz 2 Nummer 5 BSIG aufbauen [15]. Neu sind die produktbezogenen Nachweise: SBOM, Supportzeitraum, Konformitätsbewertung.
Fazit
NIS2 und der CRA sind keine konkurrierenden Regelwerke, sondern zwei Ebenen desselben Aufsichtsgedankens: die Organisation und das Produkt. Für deutsche Hersteller, die unter beide fallen, entscheidet weniger die inhaltliche Überschneidung als die operative Trennung — zwei Meldewege, zwei Fristenlogiken, ein gemeinsamer Erkennungsprozess.
Der nächste harte Termin ist der 11. September 2026, und er trifft Produkte, die längst beim Kunden stehen. Was danach kommt, hat noch 15 Monate Vorlauf. Wer die Reihenfolge respektiert, verteilt den Aufwand. Wer sie ignoriert, muss beides gleichzeitig stemmen. Einen Überblick über die Grundlagen bietet unser Leitfaden Was ist die NIS2-Richtlinie; für Finanzunternehmen mit paralleler DORA-Pflicht gilt eine vergleichbare Doppelstruktur, die wir unter NIS2 und DORA behandeln. Herstellerspezifische Anforderungen vertiefen wir unter NIS2 im Maschinenbau.
Dieser Artikel dient ausschließlich der allgemeinen Information und stellt keine Rechts- oder Compliance-Beratung dar. Anforderungen können je nach Rechtsordnung und Art der Einrichtung abweichen. Für eine auf Ihre Situation zugeschnittene Beurteilung wenden Sie sich an eine qualifizierte Rechtsanwältin, einen qualifizierten Rechtsanwalt oder eine Compliance-Fachkraft.
Quellen
- Cyber Resilience Act, Artikel 71 — Inkrafttreten und Geltung
- Cyber Resilience Act, Artikel 14 — Meldepflichten der Hersteller
- Cyber Resilience Act, Artikel 13 — Pflichten der Hersteller
- Cyber Resilience Act, Artikel 64 — Sanktionen
- Cyber Resilience Act, Artikel 32 — Konformitätsbewertungsverfahren
- Cyber Resilience Act, Artikel 7 — Wichtige Produkte mit digitalen Elementen
- Cyber Resilience Act, Artikel 3 — Begriffsbestimmungen
- Cyber Resilience Act, Artikel 2 — Anwendungsbereich
- Cyber Resilience Act, Erwägungsgrund 24 (nicht bindende Auslegungshilfe)
- Europäische Kommission — The Cyber Resilience Act: Summary of the legislative text
- Cyber Resilience Act — Anhänge I, III und IV (Übersicht)
- BSI — Cyber Resilience Act (Themenseite)
- BSI — CRA: Marktüberwachungsbehörden tagen in Berlin, erste Meldepflichten ab September
- NIS2-Richtlinie (EU) 2022/2555, Artikel 21 — Risikomanagementmaßnahmen
- § 30 BSIG — Risikomanagementmaßnahmen
- § 32 BSIG — Meldepflichten
- § 38 BSIG — Pflichten der Geschäftsleitungen
- § 65 BSIG — Bußgeldvorschriften
- Deutscher Bundestag, BT-Drucksache 21/6134 vom 26. Mai 2026 — Gesetzentwurf CRA-Durchführungsgesetz
- JIPS, Universität des Saarlandes — Bundeskabinett beschließt Entwurf zur CRA-Umsetzung
- cyber-regulierung.de — CRA-Durchführungsgesetz: BSI wird zentrale Marktüberwachungsbehörde
Sie kennen jetzt die Anforderungen. Wissen Sie, welche Nachweise Ihnen noch fehlen?
Die kostenlose NIS2-Selbsteinschätzung — über 90 prüfbare Punkte zu Art. 21 / § 30 BSIG. Sofort als PDF.
