ENISA veröffentlicht Secure by Design and Default Playbook
Die ENISA hat am 30. Juli 2026 das Secure by Design and Default Playbook veröffentlicht. Es übersetzt 22 Sicherheitsprinzipien in Checklisten, Nachweise und Freigabekriterien und ordnet sie den grundlegenden Cybersicherheitsanforderungen aus Anhang I des Cyber Resilience Acts zu.
Inhalt
Was hat die ENISA veröffentlicht?
Das Dokument liegt in Version 1.0 vor und steht unter der Lizenz CC BY 4.0. Davor lief im April und Mai 2026 eine öffentliche Konsultation mit 28 Beiträgen, unter anderem von BSI, ANSSI, OWASP Foundation, Eclipse Foundation und OpenSSF. Alle 22 Playbooks stehen zusätzlich in einem GitHub-Repository bereit.
Was ist das ENISA Secure by Design and Default Playbook?
Das ENISA Secure by Design and Default Playbook ist ein Leitfaden der EU-Agentur für Cybersicherheit. Er übersetzt Secure-by-Design- und Secure-by-Default-Prinzipien in 22 Playbooks. Jedes Playbook nennt ein Prinzip, ein Ziel, eine Checkliste, die nötigen Nachweise und Kriterien für die Release-Freigabe. Zielgruppe sind kleine und mittlere Hersteller von Produkten mit digitalen Elementen.
Gemeint sind Unternehmen mit weniger als 250 Beschäftigten und weniger als 50 Millionen Euro Jahresumsatz, die eingebettete Software, IoT-Geräte, vernetzte Systeme, Standalone-Software oder Hardware mit programmierbaren Komponenten entwickeln.
Wie sind die 22 Playbooks aufgebaut?
Vierzehn Prinzipien gehören zu Secure by Design. Sie decken die Architektur ab, etwa Vertrauensgrenzen, Least Privilege und die Minimierung der Angriffsfläche, und den laufenden Betrieb, etwa sichere Codierung, Logging, Schwachstellenmanagement und Lieferkettenkontrollen. Acht Prinzipien gehören zu Secure by Default. Sie betreffen den Auslieferungszustand, etwa abgeschaltete Dienste, restriktiven Erstzugang und geräteindividuelle Schlüssel, und die Nutzerführung, etwa erzwungenes Security-Onboarding und automatische Updates.
Jedes Playbook ist gleich aufgebaut: Prinzip, Ziel, Checkliste, Mindestnachweise, Release Gate. Beim restriktiven Erstzugang verlangt der Leitfaden als Nachweis, dass im Build keine gemeinsamen oder fest codierten Zugangsdaten stecken und dass jedes Gerät eigene Zugangsdaten erhält. Das Release Gate macht daraus Prüfpunkte für die Freigabecheckliste oder die CI/CD-Pipeline.
Neue Dokumente sind dafür nicht nötig. Die ENISA verweist auf vorhandene Unterlagen aus der Entwicklung: Architekturdiagramme, Konfigurationen, Tickets, Testergebnisse, SBOMs und Release-Aufzeichnungen. Eine SBOM kann die Nachweise für mehrere Playbooks abdecken.
Davor steht die Bedrohungsmodellierung. Sie entscheidet, welche Playbooks für ein Produkt Vorrang haben. Die ENISA nutzt dafür vier Leitfragen: Woran arbeiten wir, was kann schiefgehen, was tun wir dagegen, haben wir gut genug gearbeitet. Als Ergebnis reichen fünf bis zehn priorisierte Bedrohungsszenarien.
Was ist die Verbindung zum Cyber Resilience Act?
Zwei Anhänge stellen den Bezug her. Der eine gibt die grundlegenden Cybersicherheitsanforderungen aus Anhang I des Cyber Resilience Acts im Volltext wieder, der andere ordnet jedem der 22 Prinzipien die Anforderungen zu, bei deren Umsetzung es hilft. Der restriktive Erstzugang zahlt so auf die sichere Standardkonfiguration und den Schutz vor unbefugtem Zugriff ein, die automatischen Updates auf die Bereitstellung und sichere Verteilung von Sicherheitsupdates.
Die ENISA nennt dieses Mapping indikativ. Der Leitfaden ist keine Rechtsberatung und kein Compliance-Handbuch. Wer die Prinzipien umsetzt, ist damit weder CRA-konform noch zertifiziert.
Für den Einstieg empfiehlt die ENISA drei Stufen: erst Bedrohungsmodellierung, dann eine technische Grundlinie aus sicherer Codierung, Logging, Schwachstellenmanagement und Lieferkettenkontrollen, danach der Rest. Diese Reihenfolge betrifft den Aufbau der eigenen Prozesse. Pflichten aus dem CRA lassen sich damit nicht aufschieben.
Was bedeutet das für Hersteller?
Die Prinzipien kennt man aus IEC 62443, ETSI EN 303 645 und von OWASP. Neu ist, dass jedes Prinzip mit einem Nachweis verbunden wird. Der CRA verlangt in Artikel 13 Absatz 2 eine Bewertung der Cybersicherheitsrisiken und in Anhang VII eine technische Dokumentation, die zeigt, wie die Anforderungen erfüllt wurden. Dort setzen die Nachweise an.
Nehmen Sie einen Embedded Controller mit Web-Interface und Fernwartung. Die Anforderung „sichere Standardkonfiguration“ ist als Rechtstext abstrakt. Der Leitfaden macht daraus vier Prüfpunkte: keine gemeinsamen Zugangsdaten im Produktionsbuild, eigene Zugangsdaten je Gerät, erzwungener Wechsel vor der ersten administrativen Nutzung, geprüfte Liste der ab Werk aktiven Dienste.
Für den Maschinen- und Anlagenbau nennt die ENISA eine Einschränkung: Eingebettete Produkte, Feldgeräte und Industrieanwendungen fallen in den Anwendungsbereich, die Empfehlungen müssen aber an deren Rahmenbedingungen angepasst werden. Automatische Sicherheitsupdates gelten als Standard. Wo eine unbeaufsichtigte Installation Sicherheit, Verfügbarkeit oder Betrieb stören könnte, sieht der Leitfaden Freigabefenster, gestaffelten Rollout und Betreiberzustimmung vor. In laufenden Anlagen ist das der Regelfall.
Der Leitfaden ersetzt weder die produktspezifische Risikobewertung noch die Prozessanforderungen aus EN 40000 oder IEC 62443-4-1. Er liefert ein Raster, an dem sich prüfen lässt, ob die eigenen Entwicklungs- und Freigabeprozesse abdecken, was der CRA voraussetzt.
Welche Nachweise ein CRA-konformer Entwicklungsprozess erzeugen muss, zeigt das Playbook. Welche der 22 Prinzipien für ein konkretes Produkt gelten und wie tief, sagt es nicht.
