01Secure by Design vs. Secure by Default
Secure by Design beschreibt, wie ein System gebaut ist: Bedrohungen werden früh modelliert, Architektur-Muster, geprüfte Kryptografie und systematisches Schwachstellenmanagement sind in den Entwicklungsprozess eingebettet statt nachgerüstet. Secure by Default beschreibt, wie das Produkt beim Kunden ankommt: mit der sichersten sinnvollen Konfiguration ab Werk, ohne dass Anwender Expertenwissen brauchen – Schutzmechanismen sind aktiv, und wer sie abschwächt, tut das bewusst. Das Playbook ordnet die 14 Design-Prinzipien den Gruppen Architectural Foundations und Operational Integrity zu, die 8 Default-Prinzipien den Gruppen Default Hardening und Guided Protection.
02Die 22 Prinzipien im Überblick
Architectural Foundations (6) umfasst Trust Boundaries & Threat Modelling, Least Privilege, eine starke Identitäts- und Authentifizierungsarchitektur, minimale Angriffsfläche, Defence in Depth und Open Design. Operational Integrity (8) ergänzt Lifecycle-Management, nutzerzentriertes Design, Secure Coding und Verifikation, Logging und Monitoring, Konfigurations- und Änderungsmanagement, Incident Response, Schwachstellen- und Patch-Management sowie Supply-Chain-Kontrollen inklusive SBOM. Auf der Default-Seite stehen minimale Default-Services, restriktiver Erstzugang, verschlüsselte Kommunikation ab Werk und einzigartige Geräteidentitäten (Default Hardening) sowie verpflichtendes Security-Onboarding, automatische Updates, transparente Sicherheitslage und sichere Recovery- und Besitzwechsel-Prozesse (Guided Protection).
03Playbook-Anatomie: Checkliste, Evidence, Release-Gate
Jedes Prinzip folgt demselben Fünf-Block-Format: Prinzip, Ziel, Checkliste mit den wirksamsten Aktionen, Minimum Evidence – die kleinste Menge an Artefakten, die die Umsetzung belegt – und ein Release-Gate mit Pass/Fail-Kriterien für Release-Reviews oder die CI/CD-Pipeline. Nachweise sollen aus vorhandenen Engineering-Artefakten bestehen (Architektur-Diagramme, CI-Logs, Tickets, SBOMs) und dürfen mehrere Playbooks gleichzeitig bedienen; Ausnahmen sind erlaubt, aber nur dokumentiert mit Verantwortlichem und Review-Datum. Für die Einführung empfiehlt ENISA drei Stufen: zuerst Kontext und Prioritäten klären, dann eine Engineering-Baseline aus Secure Coding, Logging, Schwachstellen-Management und Supply-Chain-Kontrollen etablieren – ergänzt um die produktrelevanten Default-Playbooks – und schließlich Abdeckung und Automatisierung ausbauen. Wichtig: Der Stufenplan organisiert Aufwand, verschiebt aber keine rechtlichen Pflichten.
04Threat Modelling in Leichtbauweise
Statt schwergewichtiger Analysen empfiehlt das Playbook ein Minimum Viable Threat Model entlang der vier Fragen von Shostacks Framework: Woran arbeiten wir? Was kann schiefgehen? Was tun wir dagegen? War es gut genug? Ergebnis ist eine Seite: ein Diagramm mit Komponenten, Datenflüssen und Trust Boundaries, die fünf bis zehn wichtigsten Bedrohungsszenarien, je Szenario Kontrollen samt Secure-Default-Einstellung und Verifikationsmethode – plus definierte Trigger, wann das Modell aktualisiert werden muss. ENISA benennt typische Anti-Pattern ausdrücklich: Threat Modelling als einmalige Compliance-Übung, überdetaillierte Modelle ohne Wirkung auf Designentscheidungen und fehlende Refreshs nach Produktänderungen. Für Produkte mit KI-Komponenten gehören auch Prompt Injection, Model Poisoning und Adversarial Inputs ins Modell.
05Maschinenlesbare Attestierung: Compliance als Code
Der visionärste Teil des Dokuments: Sicherheitsaussagen wandern aus statischen PDFs in strukturierte, signierbare Artefakte (JSON/YAML), die drei Schichten verbinden – Sicherheitsziele (Control Layer), implementierte Kontrollen samt Konfiguration (Implementation Layer) und automatisierte Prüf-Ergebnisse mit Evidence-Hashes (Assessment & Verification Layer). Am durchgerechneten Beispiel SafeGate-X1, einem Linux-Industriecontroller, zeigt ENISA, wie Bedrohungen über Prinzipien bis zu automatischen Release-Gates rückverfolgbar werden – vom Nmap-Scan-Gate bis zum Read-only-Dateisystem-Test in der CI. ENISA schreibt bewusst kein neues Schema vor, sondern verweist auf existierende Standards wie NIST OSCAL, OWASP CycloneDX mit CDXA und VEX, das SPDX-3.0-Security-Profile, OpenSSF-Projekte wie Scorecard und SLSA sowie in-toto und Sigstore. Klargestellt wird auch: Eine Hersteller-Attestierung ist kein Beweis – Verifikation und unabhängige Bewertung bleiben eigenständige Schritte.
06Die CRA-Brücke: Annex C
Annex B des Playbooks listet die grundlegenden Cybersicherheitsanforderungen aus Anhang I des Cyber Resilience Act, Annex C mappt jedes der 22 Prinzipien indikativ darauf – etwa automatische Updates auf Anhang I Teil I 2(c), Supply-Chain-Kontrollen auf die SBOM-Pflicht in Teil II oder restriktiven Erstzugang auf die sichere Standardkonfiguration nach Teil I 2(b). Damit eignet sich das Dokument als Engineering-Einstieg in CRA-Gap-Analysen: Teams sehen, welche Playbooks auf welche Anforderungen einzahlen, und sammeln über die Release-Gates früh belastbare Nachweise. ENISA betont zugleich, dass die Befolgung des Playbooks keine CRA-Konformität begründet – Konformitätsbewertung, harmonisierte Normen und die technische Dokumentation nach der Verordnung bleiben eigenständige Pflichten.
Deep Dive: EU Cyber Resilience Act → 
