CRA-02 – EU-Cyberresilienzgesetz

Sicher in der Standardkonfiguration

Ihr Produkt wird in 8 Wochen ausgeliefert. Die technische Dokumentation enthält nichts zur Cybersicherheit. Beweisen Sie, dass es secure by design war.

BEDROHUNGSLEVEL: GRÜN

Sie sind der Leitende Firmware-Ingenieur bei Kastos IoT. Vier Wochen sind seit dem Zero Day vergangen — dem Authentifizierungs-Bypass, der Kastos' erste Reaktion auf das EU-Cyberresilienzgesetz (CRA) ausgelöst hat. Das Patch ist verschickt. Die SBOM wurde neu erstellt. Die Zusammenarbeit mit der benannten Stelle ist im Gange. Jetzt kommt die schwierigere Frage: können Sie beweisen, dass der K400 secure-by-default konzipiert wurde? Ihre Aufgabe: Erstellen Sie die technische Dokumentationsdatei, die gemäß CRA Artikel 31 für die K400 v4.0 Firmware-Version erforderlich ist. Die bestehende Datei wurde für die Radio Equipment Directive erstellt. Sie behandelt EMC und RF-Sicherheit. Sie sagt nichts über Cybersicherheit.

Kastos IoT — 340 Mitarbeitende, 62 Mio. € Umsatz, Hauptsitz Rotterdam
K400-v4.0-Firmware-Release in 8 Wochen geplant
Aktuelle technische Dokumentation: RED-konform (EMV + Hochfrequenzsicherheit), kein Cybersicherheits-Abschnitt
SBOM neu erstellt nach Modul 1 — jetzt verifiziert gegen Build-Artifacts
Einbindung der benannten Stelle (BSI Netherlands) für wichtige Klasse-I-Bewertung im Gange
40 % der Installationsbasis sind kleine Unternehmen, die mit der SSH-Konfiguration Schwierigkeiten haben

Missions-Briefing

So funktioniert es

Dies ist ein interaktives Entscheidungsszenario. Sie werden reale Entscheidungen treffen, die ein Leitender Firmware-Ingenieur bei der Erstellung einer CRA-konformen technischen Dokumentation trifft — und Ihre Entscheidungen bestimmen Ihre endgültige Betriebsbewertung.

Document Redline Activity

Überprüfen Sie die vorhandene technische Dokumentation und kennzeichnen Sie die Abschnitte, die den CRA-Anforderungen nicht entsprechen.

Drei Entscheidungen

Jede Entscheidung wird bewertet. Deine Entscheidungen bestimmen eine prozentuale Einsatzbewertung. Falsche Entscheidungen haben weitreichende Folgen.

Risk Assessment Spectrum

Verwenden Sie den Schieberegler, um den angemessenen Umfang für die Cybersicherheits-Risikobewertung des K400 zu ermitteln.

Klausel-Generator

Erstellen Sie die technischen Unterlagen gemäß Anhang VII, indem Sie für jeden vorgeschriebenen Abschnitt die richtige Klausel auswählen.

--:--:-- GRÜN CRA-02: Standardmäßig sicher

Personnel Briefing

Ihr Team

Sie werden mit diesen vier Personen während des Szenarios zusammenarbeiten. Ihre Prioritäten stehen im Konflikt. Ihre Aufgabe ist es, die Entscheidung zu finden, die rechtlich, technisch und kommerziell tragbar ist.

Tomasz Kowalski

Lead Firmware Engineer

Erstellt das Produkt. Kennt jede Abhängigkeit. Hat eine Abneigung gegen Papierkram.

Nina Berger

Product Manager

Er ist für den Liefertermin verantwortlich. Er wird sich gegen alles wehren, was den Start verzögert.

Sophie Laurent

Leiter der Abteilung für Rechts- und Regulierungsangelegenheiten

Sorgt dafür, dass Kastos sich an die Gesetze hält. Verwendet Fachbegriffe aus dem Rechtsbereich.

Jan Mulder

Leiter der Entwicklungsabteilung

Tomasz’ Chef. Zählt jeden Sprint. Hasst Überraschungen aus der Rechtsabteilung.

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Die technische Akte

Montag, 09:15 MEZ

Sie öffnen die K400-technische Dokumentation. Sie wurde zuletzt für die v3.0 RED-Zertifizierung aktualisiert — 18 Monate ago. Die Dokumentation behandelt elektromagnetische Verträglichkeitstests, radiofrequente Sicherheitsbewertungen und elektrische Sicherheitsstandards. Unter ‘Sicherheit,’ gibt es einen einzigen Absatz: ‘Der K400 verwendet AES-256-Verschlüsselung für Cloud-Kommunikation.’

Das EU-Cyberresilienzgesetz (CRA) verlangt in Anhang VII, dass die technische Dokumentation folgende Punkte enthält: eine allgemeine Beschreibung des Produkts, die Cybersicherheits-Risikobewertung, eine Beschreibung, wie die wesentlichen Anforderungen erfüllt werden, die Liste der angewendeten harmonisierten Standards, die EU-Konformitätserklärung und die SBOM. Ihre Dokumentation hat einen dieser Punkte teilweise abgedeckt.

Sophie hat den Zeitplan der BSI Netherlands-Bewertung weitergeleitet: die benannte Stelle benötigt die technische Dokumentation in 6 Wochen, um ihre Überprüfung vor dem v4.0-Versanddatum abschließen zu können.

OF

OPS FEED — Lage-Feed

[09:15] DOKUMENTATION — K400-technische Akte-Überprüfung eingeleitet. CRA-Anhang-VII-Konformität: 1 von 6 erforderlichen Abschnitten vorhanden (teilweise).

TOMASZ KOWALSKI — Leitender Firmware-Ingenieur

Ein Absatz über Verschlüsselung. Das ist alles. Wir bauen dies von Grund auf.

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Aktivität

Technische Akte mit Änderungsmarkierungen

Proberunde – wird nicht gewertet. Dein Ergebnis ergibt sich aus den drei Entscheidungen.

Montag, 10:30 MEZ

Bevor Sie beginnen, die Dokumentation zu schreiben, müssen Sie verstehen, wie weit die bestehende technische Dokumentation von den CRA-Anforderungen abweicht. Überprüfen Sie die aktuelle technische Dokumentation des K400 und markieren Sie die Abschnitte, die den CRA-Anforderungen nicht entsprechen. Klicken Sie auf jeden problematischen Abschnitt, um die Konformitätslücke aufzudecken.

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Die Telnet-Frage

Montag, 14:00 MEZ

Sie präsentieren die Beweisaufnahme dem Team. Die secure-by-default-Lücke ist das größte Problem. Nina bringt sofort das Installer-Problem zur Sprache.

Der K400 wird von Bauunternehmern und nicht von IT-Teams eingesetzt. In 40% der Installationen ist der Installateur ein kleines Unternehmen mit 2–5 Mitarbeitern und ohne eigenes IT-Personal. Sie verwenden Telnet, da SSH eine Schlüsselverwaltung erfordert, die ihre Arbeitsabläufe nicht unterstützen. Die Deaktivierung von Telnet würde Hunderte von Supportanfragen generieren und möglicherweise die Bereitstellung verzögern.

NINA BERGER — Produktmanager

Ich habe 340 Support-Tickets in 6 Monaten von Installateuren, die die SSH-Einrichtung nicht abschließen können. Das ist nicht theoretisch — das sind verlorene Umsätze und verzögerte Gebäudeübergaben. Wenn wir Telnet deaktivieren, müssen wir ihnen etwas geben, das tatsächlich funktioniert.

SOPHIE LAURENT — Leiterin Rechts- und Regulierungsangelegenheiten

Das EU-Cyberresilienzgesetz (CRA) erfordert eine secure-by-default-Konfiguration. Telnet ist ein unverschlüsseltes Protokoll, das Anmeldeinformationen im Klartext überträgt. Die Auslieferung mit aktiviertem Telnet ist ein klarer Verstoß gegen die Konformität. Die Frage ist, wie wir den Installationsworkflow angehen, nicht ob wir ihn angehen.

JAN MULDER – Vizepräsident für Technik

Wir können nicht 40 % unserer Installationsbasis verlieren. Das ist kein Compliance-Problem — das ist ein Überlebensproblem.

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Entscheidung erforderlich

Sichere Voreinstellungen vs. Installationsworkflow

Der K400 wird derzeit mit aktiviertem Telnet ausgeliefert. Das EU-Cyberresilienzgesetz (CRA) fordert eine sichere Standardkonfiguration. 40% der Installateure verlassen sich auf Telnet, da die SSH-Schlüsselverwaltung für ihre Arbeitsabläufe zu komplex ist. Wie lösen Sie dieses Problem?

--:--:-- GRÜN CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Outcome: Positive

SSH-Wizard erstellt

Ihr Team entwickelt einen SSH-Setup-Assistenten, der auf dem integrierten Display des K400 während der ersten Konfiguration ausgeführt wird. Er generiert ein Schlüsselpaar auf dem Gerät, zeigt einen QR-Code an, den der Installateur mit seinem Telefon scannen kann, um die Verbindung herzustellen, und speichert den Schlüssel sicher. Kein Telnet, keine manuelle Schlüsselverwaltung.

Tests mit 12 Installationsfirmen zeigen: die durchschnittliche Einrichtungszeit erhöht sich von 4 Minuten (Telnet) auf 6 Minuten (Assistent). Zwei Firmen benötigten einen 15-minütigen Telefonanruf mit dem Support beim ersten Versuch. Danach waren sie schneller als Telnet, da der QR-Code die Eingabe von Passwörtern vollständig eliminierte.

Nina ist vorsichtig optimistisch: 'Wenn die Anzahl der Supportanfragen im ersten Monat unter 50 bleibt, funktioniert das.' Sophie dokumentiert die Lösung als Beweis für die technische Akte.

Regulatory Reference

CRA Annex I Section 1(3) — Secure Default Configuration

Produkte mit digitalen Elementen müssen mit einer Konfiguration „secure by default“ ausgestattet werden, einschließlich der Möglichkeit, auf den ursprünglichen sicheren Zustand zurückzusetzen. „Secure by default“ bedeutet, dass das Produkt in seinem sichersten nutzbaren Zustand ausgeliefert wird — der Benutzer muss eine bewusste Handlung ausführen, um die Sicherheit zu verringern, und nicht umgekehrt. Das Ersetzen eines unsicheren Protokolls durch ein sicheres Alternativprotokoll, das den Bedarf an Nutzbarkeit erfüllt, ist der Goldstandard: Es eliminiert die Konformitätslücke, ohne eine Geschäftslücke zu erzeugen.

Nina Berger — Product Manager

„Wenn die Anzahl der Supportanrufe im ersten Monat unter 50 bleibt, funktioniert das.“

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Outcome: Neutral

Physische Opt-In

Telnet ist standardmäßig deaktiviert. Ein versteckter Knopf auf dem K400-Panel aktiviert Telnet, wenn er während der ersten 24 Stunden nach der Werksreset-Taste für 5 Sekunden gedrückt wird. Das Display zeigt eine Warnung an: 'TELNET AKTIVIERT — UNVERSCHLÜSSELTES PROTOKOLL — NUR DURCH INITIALISIERUNG VERWENDEN.'

Sophie überprüft den Ansatz: 'Das ist vertretbar. Die Standardkonfiguration ist sicher. Die Opt-in-Funktion erfordert physischen Zugriff und informierte Zustimmung. Aber die benannte Stelle kann fragen, warum wir das unsichere Protokoll nicht vollständig eliminiert haben — bereiten Sie sich darauf vor, zu dokumentieren, warum die Ausnahmeregelung im Verhältnis zum Installationsanwendungsfall angemessen ist.'

Nina akzeptiert: '60% der Installateure benötigen es nicht. Die 40%, die es benötigen, können einen Knopf drücken. Das reicht aus.'

Regulatory Reference

Verhältnismäßigkeit bei der sicheren Gestaltung

Das EU-Cyberresilienzgesetz (CRA) verbietet nicht alle unsicheren Funktionalitäten — es fordert sichere Defaults und informierte Nutzerentscheidungen. Die Bereitstellung eines Opt-in-Mechanismus für ein weniger sicheres Protokoll kann konform sein, wenn: (1) der Standard sicher ist, (2) der Benutzer eine bewusste, dokumentierte Handlung ausführt, um es zu ändern, (3) das Risiko klar kommuniziert wird und (4) das Produkt auf den sicheren Zustand zurückgesetzt werden kann. Der Schlüssel besteht darin, die Angemessenheit zu demonstrieren — das verbleibende Risiko wird vom Benutzer akzeptiert, nicht vom Hersteller aufgezwungen.

Sophie Laurent – Leiterin der Abteilung für Rechts- und Regulierungsangelegenheiten

„Das ist vertretbar. Die Standardeinstellung ist sicher. Die aktive Zustimmung erfordert physischen Zugriff und eine Einwilligung nach Aufklärung. Seien Sie jedoch darauf vorbereitet, zu begründen, warum diese Ausnahmeregelung im Verhältnis zum Anwendungsfall des Installateurs steht.“

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Outcome: Negative

Auto-Deaktivierungs-Umgehung

Der K400 v4.0 wird mit aktiviertem Telnet für die ersten 72 Stunden nach dem Booten ausgeliefert. Während der Prüfung durch die BSI Netherlands fragt der Prüfer: 'Also wird das Produkt in einem unsicheren Zustand durch Konstruktion bereitgestellt?' Tomasz erklärt den Installationsarbeitsablauf. Der Prüfer notiert: 'Das CRA fordert eine sichere Standardkonfiguration zum Zeitpunkt der Bereitstellung auf dem Markt. Ein 72-stündiges ungesichertes Zeitfenster ist keine sichere Standardkonfiguration — es ist eine geplante Schwachstelle.'

Das Ergebnis verzögert die Konformitätsbewertung um 4 Wochen, während Kastos eine ordnungsgemäße secure-by-default-Mechanik implementiert. Das v4.0-Lieferdatum verzögert sich. Jan ist wütend: 'Wir haben versucht, 3 Wochen der Entwicklung zu sparen und haben 4 verloren.'

Regulatory Reference

Default Means Default

Ein Produkt, das mit einer unsicheren Konfiguration ausgeliefert wird — sogar nur vorübergehend — erfüllt nicht die Anforderung an sichere Defaults des EU-Cyberresilienzgesetzes (CRA). Die Verordnung bewertet den Zustand des Produkts zum Zeitpunkt der Markteinführung, nicht nach Ablauf einer Zeitspanne. „Es sichert sich später“ ist nicht „secure by default“. Es ist unsicher mit aufgeschobener Abhilfe. Marktüberwachungsbehörden und benannte Stellen bewerten, was das Produkt „out of the box“ tut.

Jan Mulder – Vizepräsident für Technik

„Wir wollten drei Wochen Entwicklungszeit einsparen und haben vier verloren.“

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Die Risikobewertungslücke

Mittwoch, 10:00 MEZ

Mit der Klärung der sicheren Standardkonfiguration wenden Sie sich der Risikobewertung zu. Das bestehende 3-seitige Bedrohungsmodell wurde vor der Module-1-Schwachstelle erstellt und deckt Netzwerkebene-Bedrohungen ab, aber nicht den BLE-Authentifizierungs-Bypass. Das CRA fordert eine Risikobewertung, die den beabsichtigten Zweck des Produkts, die vernünftigerweise vorhersehbare Verwendung und den Lebenszyklus des Produkts — einschließlich Wartung und End-of-Life — abdeckt.

Sie haben drei Optionen für den Umfang der Risikobewertung, jede mit unterschiedlichen Kostengrenzen, Zeitplänen und Gründlichkeit.

Threat category	K400 attack surface	Current file	Required
Spoofing	BLE pairing identity	✗ missing	Mutual auth + cert pinning
Tampering	Firmware update package	⚠ partial	Signed updates + secure boot
Repudiation	Door/access audit log	✓ covered	Tamper-evident log
Info Disclosure	Cloud API + BLE provisioning	✓ covered	TLS 1.3 + LE Secure Connections
Denial-of-Service-Angriff	BLE scan flood + cloud overload	✗ missing	Rate limiting + offline cache
Erweiterung von Berechtigungen	Telnet (standardmäßig aktiviert) + JTAG	✗ missing	Nur SSH + JTAG bei der Fertigung integriert
Supply Chain	BLE stack + 23 single-maintainer libs	✗ missing	Component provenance + SBOM

3 von 7 CRA-Bedrohungskategorien abgedeckt. Der BLE-Bypass, der Modul 1 ausgelöst hat, befindet sich im Spoofing Zeile, die noch nicht geschrieben wurde.

SOPHIE LAURENT — Leiterin Rechts- und Regulierungsangelegenheiten

Anhang I Abschnitt 1 erfordert, dass der Hersteller das Produkt «auf der Grundlage einer Bewertung der Cybersicherheitsrisiken» liefert. Diese Risikobewertung muss in der technischen Akte dokumentiert und bei wesentlichen Änderungen aktualisiert werden. Eine neue Firmware-Version nach einer kritischen Schwachstelle qualifiziert als wesentliche Änderung.

OF

OPS FEED — Lage-Feed

[10:05] COMPLIANCE — Risikobewertungs-Überprüfung: das aktuelle Dokument deckt 3 von 7 CRA-erforderlichen Bedrohungskategorien ab. BLE, physischer Zugriff, Firmware-Update und Lieferkette-Kategorien fehlen.

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Entscheidung erforderlich

Risikobewertungsumfang

Die bestehende Risikobewertung ist unvollständig. Die technische Akte für v4.0 benötigt eine Cybersicherheits-Risikobewertung, die alle CRA-erforderlichen Kategorien abdeckt. Die benannte Stelle benötigt sie in 6 Wochen. Wie definieren Sie den Umfang der Bewertung?

--:--:-- GRÜN CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Outcome: Positive

Vollständiges Bedrohungsmodell

Ihr Team verbringt 3 Wochen damit, ein umfassendes Bedrohungsmodell mithilfe der STRIDE-Methode über alle K400-Schnittstellen zu erstellen. Die Bewertung identifiziert 23 Bedrohungsszenarien über 7 Angriffsflächen. Für jedes dokumentieren Sie: die Bedrohung, die bestehende Abmilderung, das verbleibende Risiko und die CRA-wesentliche Anforderung, auf die es abhängt.

Die Bewertung deckt zwei mittelschwere Probleme auf, die niemand auf dem Schirm hatte: der Firmware-Update-Mechanismus validiert die Paketsignaturen nicht während des Downloads (nur während der Installation), und die mobile App speichert den API-Schlüssel im Klartext in den gemeinsamen Einstellungen. Beide werden vor dem Versand von v4.0 behoben.

Der Prüfer der benannten Stelle bemerkt: 'Das ist eine der gründlicheren Risikobewertungen, die wir gesehen haben. Die STRIDE-Zuordnung zu CRA-wesentlichen Anforderungen ist besonders nützlich.'

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Outcome: Neutral

Update Plus Pen-Test

Sie aktualisieren das bestehende Bedrohungsmodell in 1 Woche, indem Sie BLE-, physischen Zugriff-, Firmware-Update- und Lieferkettenschwachstellen-Kategorien hinzufügen. Der externe Pen-Test beginnt in der folgenden Woche und deckt die neuen Angriffsflächen ab.

Der Pen-Test deckt die gleichen zwei mittelschweren Probleme (unsigned Firmware-Download, Klartext-API-Schlüssel) sowie ein niedrigschwacheres Ergebnis auf. Sie beheben alle drei vor dem Versand von v4.0. Die kombinierte interne Bewertung + externer Pen-Test liefert solide Beweise für die technische Akte.

Sophie bemerkt: 'Die benannte Stelle wird die unabhängige Überprüfung schätzen. Externe Tests stärken das Konformitätsargument. Das einzige Risiko ist der Zeitplan — wenn die Pen-Tester etwas Kritisches finden, sind wir wieder in einem Patch-Zyklus.'

Sophie Laurent – Leiterin der Abteilung für Rechts- und Regulierungsangelegenheiten

„Die benannte Stelle wird die unabhängige Überprüfung zu schätzen wissen. Externe Tests untermauern die Konformitätsaussage. Das einzige Risiko ist der Zeitplan – sollten die Penetrationstester etwas Kritisches entdecken, sind wir wieder im Patch-Zyklus.“

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Outcome: Negative

Minimales Patch

Sie aktualisieren die Risikobewertung mit einer einzigen Seite über den BLE-Authentifizierungs-Bypass. Der Rest des Dokuments bleibt unverändert von der v3.0-RED-Zertifizierung.

Während der BSI-Netherlands-Prüfung fragt der Prüfer: 'Ihre Risikobewertung deckt Netzbedrohungen und den BLE-Bypass ab. Was ist mit physischem Zugriff auf das Panel? Firmware-Update-Integrität? Lieferkettenrisiken für die 312 Abhängigkeiten in Ihrem SBOM? Das CRA fordert, dass die Bewertung den beabsichtigten Zweck und die vernünftigerweise vorhersehbaren Verwendungsbedingungen abdeckt.'

Der Prüfer markiert die Risikobewertung formal als unzureichend. Die Konformitätsbewertung wird pausiert, bis eine konforme Risikobewertung erstellt ist. Das v4.0-Lieferdatum ist nun ungewiss.

Regulatory Reference

CRA Annex I Section 1(2) — Risk Assessment Requirements

Das EU-Cyberresilienzgesetz (CRA) fordert von Herstellern, vor der Markteinführung eines Produkts eine Cybersicherheitsrisikobewertung durchzuführen und diese bei wesentlichen Änderungen zu aktualisieren. Die Bewertung muss den beabsichtigten Verwendungszweck des Produkts, die vorhersehbaren Verwendungsumstände und den gesamten Produktlebenszyklus abdecken. Eine Risikobewertung, die nur bekannte vergangene Schwachstellen abdeckt, ist rückblickend — das EU-Cyberresilienzgesetz (CRA) fordert eine vorausschauende Bewertung der Bedrohungen, denen das Produkt bei der Bereitstellung ausgesetzt sein wird. Eine benannte Stelle wird bewerten, ob die Risikobewertung angemessen ist für die Komplexität und das Risikoprofil des Produkts.

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Aktivität

Risikobewertungstiefe

Proberunde – wird nicht gewertet. Dein Ergebnis ergibt sich aus den drei Entscheidungen.

Woche 4

Der Umfang der Risikobewertung ist ein Kompromiss. Ziehen Sie den Schieberegler, um die Tiefe der Cybersicherheits-Risikobewertung des K400 zu setzen. Jede Position zeigt die Kosten, den Zeitplan, die Abdeckung und die regulatorische Verteidigung. Finden Sie die Position, die Gründlichkeit mit der 6-wöchigen Frist der benannten Stelle ausgleicht.

Minimal – nur den bekannten BLE-Bypass beheben Exhaustive — full threat model + external pen test + red team engagement

0% 25% 50% 75% 100%

RISK: LOW

Umfassendes STRIDE-Bedrohungsmodell für alle 7 Angriffsflächen. 3 Wochen, 0 €. Vollständige Abdeckung unter Einsatz interner Fachkenntnisse. Fundierte Dokumentation, jedoch keine unabhängige Validierung.

Die CRA verlangt eine angemessene Risikobewertung – gründlich genug, um alle vorhersehbaren Gefahren abzudecken, aber nicht so übertrieben, dass sie die Markteinführung unnötig verzögert. Der Bereich von 50 bis 75 % bietet eine umfassende Abdeckung mit stichhaltigen Nachweisen. Ein Wert unter 50 % führt zu Lücken bei der Compliance. Ein Wert über 75 % steht in keinem Verhältnis zum Risikoprofil des Produkts und führt zu einer Nichteinhaltung der Frist.

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Entscheidung erforderlich

Die Frist für die technische Dokumentation

Die technische Akte v4.0 nimmt Gestalt an. Die benannte Stelle benötigt sie in 2 Wochen. Ihre Risikobewertung ist abgeschlossen, die SBOM ist aktuell und die secure-by-default-Einstellungen sind implementiert. Aber die Ergebnisse des Penetrationstests werden erst in weiteren 3 Wochen finalisiert sein — 1 Woche nach dem BSI-Niederlande-Termin. Was reichen Sie ein?

--:--:-- GRÜN CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Outcome: Positive

Transparente Einreichung

BSI Niederlande akzeptiert die gestufte Einreichung. Sie beginnen sofort mit der Überprüfung der Risikobewertung, der SBOM, der Dokumentation der secure-by-default-Einstellungen und der Architekturabschnitte. Die Ergebnisse des Penetrationstests treffen 3 Wochen später ein und bestätigen die Abhilfemaßnahmen. Die Konformitätsbewertung wird termingerecht abgeschlossen — die 3-wöchige Verlängerung wurde aufgenommen, weil die Prüfer parallel an anderen Abschnitten arbeiteten.

Jan ist erleichtert: «Der Liefertermin bleibt bestehen. Und wir haben keine Abstriche bei der Akte gemacht.» Sophie fügt die Feedbacks des Prüfers zur internen Compliance-Bibliothek hinzu: «Sie haben die Transparenz über den ausstehenden Penetrationstest geschätzt. Es ist besser, klar zu machen, was Sie noch nicht haben, als so zu tun, als hätten Sie es bereits."

Jan Mulder – Vizepräsident für Technik

„Der Liefertermin bleibt bestehen. Und wir haben bei der Datei keine Abstriche gemacht.“

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Outcome: Neutral

Alter Test, neuer Kontext

Sie reichen mit dem 14 Monate alten Penetrationstest ein. Der BSI-Prüfer bemerkt: «Dieser Test wurde auf v3.0-Firmware durchgeführt. Der Umfang schließt die BLE-Bereitstellung aus — die genaue Angriffsfläche, die vor 4 Wochen ausgenutzt wurde. Eine neue Schwachstelle wurde gefunden und in v3.2 behoben. Ich kann einen vor der Schwachstelle durchgeführten Penetrationstest nicht als Nachweis für die Konformität nach der Schwachstelle verwenden."

Der Prüfer fordert die neuen Ergebnisse des Penetrationstests, bevor er fortfährt. Die Konformitätsbewertung wird nicht abgelehnt — sie wird im Testabschnitt pausiert. Andere Abschnitte gehen weiter. Nettoverzögerung: 2 Wochen über den ursprünglichen Zeitplan hinaus.

--:--:-- GELB CRA-02: Standardmäßig sicher

Situationsübersicht

Lageupdate

Outcome: Negative

Verzögerte Einreichung

Sie verschieben alles um 3 Wochen. Die technische Akte ist vollständig, wenn sie eingereicht wird — jeder Abschnitt ist final, jeder Test ist aktuell. Aber das v4.0-Lieferdatum ist jetzt um 3 Wochen verschoben.

Jan ist frustriert: «Wir hätten die Abschnitte einreichen können, die bereit waren, und sie hätten parallel überprüfen lassen. Jetzt haben wir 3 Wochen Umsatz verloren, weil wir auf Perfektion gewartet haben.» Sophie stimmt zu: «Eine gestufte Einreichung mit transparenten Lücken ist Standardpraxis für die Zusammenarbeit mit benannten Stellen. Sie sind es gewohnt, Abschnitte parallel zu überprüfen. Dies war eine unnötige Verzögerung."

Die Konformitätsbewertung selbst dauert nur 2 Wochen — die Akte war gründlich. Aber der Gesamtzeitplan ist jetzt 5 Wochen länger als der parallele Ansatz es hätte sein können.

Regulatory Reference

Zusammenarbeit mit benannten Stellen

Die Einschaltung benannter Stellen sind keine bestandenen oder nicht bestandenen Prüfungen — sie sind kooperative Bewertungen. Prüfer erwarten gestufte Einreichungen und arbeiten parallel an verschiedenen Abschnitten. Transparenz über ausstehende Leistungen (wie Penetrationstest-Ergebnisse) ist Standardpraxis und signalisiert keine Nichtkonformität. Das Warten auf Perfektion, bevor man sich einschaltet, verschwendet Zeit, die beide Parteien produktiv nutzen könnten. Das Ziel besteht darin, die Konformität zu demonstrieren, nicht darin, zu demonstrieren, dass man ein perfektes Dokument in einem einzigen Einreichungsschritt produzieren kann.

Jan Mulder – Vizepräsident für Technik

„Wir hätten die fertigen Abschnitte einreichen und parallel prüfen lassen können. Jetzt haben wir drei Wochen Umsatz verloren, weil wir auf Perfektion gewartet haben.“

--:--:-- GRÜN CRA-02: Standardmäßig sicher

Situationsübersicht

Aktivität

Anhang VII — Erstellen der technischen Dokumentation

Proberunde – wird nicht gewertet. Dein Ergebnis ergibt sich aus den drei Entscheidungen.

Woche 6

Die technische Akte benötigt 6 verpflichtende Abschnitte pro Anhang VII. Konstruieren Sie die Akte, indem Sie die richtige Klausel für jeden Abschnitt aus den verfügbaren Optionen auswählen. Falsche Kombinationen führen zu einer Fehlvalidierung — die benannte Stelle wird eine Akte mit fehlenden oder nicht übereinstimmenden Abschnitten nicht akzeptieren.

Module complete. Take the knowledge check when you're ready. WISSENSÜBERPRÜFUNG STARTEN →

--:--:-- GRÜN CRA-02: Standardmäßig sicher

Situationsübersicht

Wissenscheck

Bevor Sie Ihre Ergebnisse sehen — vier Fragen zum EU-Cyberresilienzgesetz (CRA). Wählen Sie eine Antwort pro Frage.