CRA vs. NIS2 vs. RED vs. BFSG: Welche Regeln treffen euer Produkt?

Der CRA fragt: „Ist euer Produkt sicher?" – NIS2 fragt: „Ist euer Unternehmen sicher aufgestellt?" Deshalb kann beides gleichzeitig gelten: Ein Hersteller kritischer Komponenten braucht CRA-konforme Produkte UND eine NIS2-konforme Organisation. Und deshalb ersetzt keins das andere.

Je nach Regelwerk unterschiedlich: Beim CRA nein – er gilt größenunabhängig, kleine Unternehmen bekommen nur Erleichterungen bei der Dokumentation. Bei NIS2 gelten Größenschwellen (mit Ausnahmen für bestimmte kritische Anbieter). Beim BFSG gibt es Ausnahmen für Kleinstunternehmen im Dienstleistungsbereich. Welche auf euch zutreffen, klärt eure Rechtsberatung – Pauschalantworten wären hier unseriös.

Weil NIS2 die Lieferkette einbezieht: Betroffene Unternehmen müssen die Sicherheit ihrer Zulieferer managen – und reichen das als Fragebögen, Vertragsklauseln und Ausschreibungsanforderungen an euch weiter. Eine saubere CRA-Umsetzung (SBOM, Update-Prozesse, Meldefähigkeit) ist praktischerweise genau das Material, mit dem ihr solche Anfragen beantwortet.

Nach Frist und Marktzugang: Was bereits gilt, zuerst – RED (seit 08/2025, CE-relevant) und BFSG (seit 06/2025, bei Verbraucher-Apps). Parallel die CRA-Meldefähigkeit bis 09/2026, dann die restlichen CRA-Anforderungen bis 12/2027. Da sich die technischen Grundlagen überschneiden, ist das in der Praxis eine priorisierte Liste, kein Nacheinander von drei Projekten.

Der CRA knüpft an die Bereitstellung auf dem Markt an – eine rein intern genutzte App, die nie in Verkehr gebracht wird, fällt in der Regel nicht darunter. Das BFSG zielt auf Verbraucher-Angebote. Aber zwei Vorbehalte: Fällt euer Unternehmen unter NIS2, wird auch interne Software Teil eures Risikomanagements. Und sobald die „interne“ App an Kunden oder Partner geht, ändert sich die Einordnung – die Grenze im Einzelfall zieht eure Rechtsberatung.

Die rechtliche Einordnung (Betroffenheit, Produktklassifizierung, Konformitätserklärung) gehört zu eurer Kanzlei oder Regulatory-Beratung. Die technische Umsetzung – SBOM, Update-Fähigkeit, Meldekette, Barrierefreiheit im Code – gehört zu eurem Entwicklungspartner. Beides zusammen ergibt Konformität; deshalb arbeiten wir auf Wunsch direkt mit eurer Rechtsberatung zusammen, statt Zuständigkeits-Pingpong zu spielen.

Die DSGVO regelt personenbezogene Daten und läuft quer zu allen vieren – sie bleibt unabhängig davon bestehen. Die gute Nachricht: CRA-Maßnahmen wie Datenminimierung, Verschlüsselung und der Audit eurer Dritt-SDKs zahlen direkt auf die DSGVO ein. Wer den CRA sauber umsetzt, räumt datenschutzrechtlich gleich mit auf.

CRA und RED: die Marktüberwachungsbehörden (in Deutschland u. a. die Bundesnetzagentur), mit dem CE-Kennzeichen als Hebel. NIS2: das BSI. BFSG: die Marktüberwachungsbehörden der Länder. In der Praxis prüft euch aber meist jemand anderes zuerst: der Einkauf eurer B2B-Kunden, der Konformitätsnachweise zunehmend in Ausschreibungen verlangt – lange bevor eine Behörde anklopft.