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

How This Works

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

Review the existing technical file and flag the sections that fail CRA requirements.

Three Decisions

Each decision is scored. Your choices determine a percentage-based ops rating. Wrong calls create cascading consequences.

Risk Assessment Spectrum

Use a slider to find the proportionate depth for the K400’s cybersecurity risk assessment.

Clause Builder

Construct the Annex VII technical file by selecting the correct clause for each mandatory section.

--:--:-- GRÜN CRA-02: Secure-by-default

Personnel Briefing

Your 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

Builds the product. Knows every dependency. Allergic to paperwork.

Nina Berger

Product Manager

Owns the ship date. Will push back on anything that slips the launch.

Sophie Laurent

Head of Legal & Regulatory Affairs

Keeps Kastos on the right side of the law. Speaks in regulatory citations.

Jan Mulder

VP of Engineering

Tomasz’s boss. Counts every sprint. Hates surprises from legal.

--:--:-- GELB CRA-02: Secure-by-default

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: Secure-by-default

Situationsübersicht

Aktivität

Technische Akte mit Änderungsmarkierungen

Practice round — not scored. Your score comes from the three decisions.

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: Secure-by-default

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 — VP of Engineering

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

--:--:-- GELB CRA-02: Secure-by-default

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: Secure-by-default

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

“If the support call volume stays under 50 in the first month, this works.”

--:--:-- GELB CRA-02: Secure-by-default

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

Proportionality in Secure Design

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 — Head of Legal & Regulatory Affairs

“This is defensible. The default is secure. The opt-in requires physical access and informed consent. But be prepared to document why the escape hatch is proportionate to the installer use case.”

--:--:-- GELB CRA-02: Secure-by-default

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 — VP of Engineering

“We tried to save 3 weeks of development and lost 4.”

--:--:-- GELB CRA-02: Secure-by-default

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	BLE scan flood + cloud overload	✗ missing	Rate limiting + offline cache
Elevation of Privilege	Telnet (default-on) + JTAG	✗ missing	SSH-only + JTAG fused at production
Supply Chain	BLE stack + 23 single-maintainer libs	✗ missing	Component provenance + SBOM

3 of 7 CRA threat categories covered. The BLE bypass that triggered Module 1 lives in the Spoofing row that isn’t written yet.

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: Secure-by-default

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: Secure-by-default

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: Secure-by-default

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 — Head of Legal & Regulatory Affairs

“The notified body will appreciate the independent verification. External testing strengthens the conformity argument. The only risk is timeline — if the pen testers find something critical, we’re back to a patch cycle.”

--:--:-- GELB CRA-02: Secure-by-default

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: Secure-by-default

Situationsübersicht

Aktivität

Risikobewertungstiefe

Practice round — not scored. Your score comes from the three decisions.

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 — patch the known BLE bypass only Exhaustive — full threat model + external pen test + red team engagement

0% 25% 50% 75% 100%

RISK: LOW

Full STRIDE threat model across all 7 attack surfaces. 3 weeks, €0. Complete coverage using internal expertise. Strong documentation but no independent validation.

The CRA requires a proportionate risk assessment — thorough enough to cover all foreseeable threats, but not so excessive that it delays market placement unnecessarily. The 50–75% range provides comprehensive coverage with defensible evidence. Going below 50% creates compliance gaps. Going above 75% is disproportionate to the product’s risk profile and misses the deadline.

--:--:-- GELB CRA-02: Secure-by-default

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: Secure-by-default

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 — VP of Engineering

“The ship date holds. And we didn’t cut corners on the file.”

--:--:-- GELB CRA-02: Secure-by-default

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: Secure-by-default

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

Working With Notified Bodies

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 — VP of Engineering

“We could have submitted the sections that were ready and let them review in parallel. Now we’ve lost 3 weeks of revenue because we waited for perfection.”

--:--:-- GRÜN CRA-02: Secure-by-default

Situationsübersicht

Aktivität

Anhang VII — Erstellen der technischen Dokumentation

Practice round — not scored. Your score comes from the three decisions.

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.

--:--:-- GRÜN CRA-02: Secure-by-default

Situationsübersicht

Wissenscheck

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