In diesem Beitrag
Security by Design steht seit Jahren in jedem zweiten Positionspapier. Meistens bleibt es beim Schlagwort. Am 30. Juli 2026 veröffentlichte ENISA die finale Fassung des „Secure by Design and Default Playbook“. Die 22 Playbooks verbinden Sicherheitsprinzipien mit Checklisten, Nachweisen und messbaren Freigabekriterien. Rechtsverbindlich ist das Dokument nicht; als praktische Umsetzungshilfe ist es trotzdem wertvoll.
Ich habe die finale Fassung durchgearbeitet. Was steckt drin, was hilft im Tagesgeschäft — und wo muss man trotzdem selbst ran?
Was das finale Playbook ist — und was nicht
Das Playbook richtet sich vor allem an KMU, die Produkte mit digitalen Elementen herstellen — Embedded Software, IoT-Geräte, vernetzte Systeme oder Standalone-Software. Es ist weder eine rechtsverbindliche Compliance-Checkliste noch ein Zertifizierungsersatz. Wer alles umsetzt, hat deshalb noch keinen formalen CRA-Konformitätsnachweis in der Tasche.
Was es liefert: einen Rahmen, um Cybersecurity über den gesamten Produktlebenszyklus zu verankern. Von der Anforderungsdefinition über Architektur und Entwicklung bis zu Wartung und Außerbetriebnahme. Und zwar mit Augenmaß für Teams, die keine eigene Security-Abteilung haben.
Den Gesamtrahmen des CRA habe ich in meinem Überblick zum Cyber Resilience Act für Maschinenbauer und Hersteller aufbereitet.
22 Prinzipien in zwei Kategorien
Im Kern stehen 22 Sicherheitsprinzipien, aufgeteilt in zwei Kategorien:
Secure by Design (14 Prinzipien) — wie das System entworfen und gebaut wird. Diese unterteilen sich nochmal in Architectural Foundations (Systemarchitektur) und Operational Integrity (Betrieb und Wartung):
- Trust Boundaries und Threat Modelling
- Least Privilege
- Starke Identitäts- und Authentifizierungsarchitektur
- Angriffsoberflächen-Minimierung
- Defense in Depth
- Open Design
- Lifecycle Management
- User Centric Design
- Sichere Coding-Praktiken
- Logging, Monitoring und Alerting
- Konfigurations- und Änderungsmanagement
- Incident Response und Recovery
- Schwachstellen- und Patch-Management
- Supply-Chain-Kontrollen
Secure by Default (8 Prinzipien) — wie das Produkt ausgeliefert wird. Aufgeteilt in Default Hardening und Guided Protection:
- Minimierung von Standarddiensten
- Restriktiver Erstzugang
- Sichere Kommunikation ab Werk
- Eindeutige Geräteidentität und Geheimnisse ab Werk
- Verpflichtendes Sicherheits-Onboarding
- Automatisierte Wartung und Updates
- Transparente Sicherheitslage
- Sichere Wiederherstellung und Eigentümer-Lebenszyklus
Wie die Prinzipien strukturiert sind
Alle 22 Prinzipien folgen derselben Vierer-Struktur — und genau das hebt dieses Playbook von den üblichen Empfehlungssammlungen ab:
- Zielsetzung: Was soll das Prinzip erreichen, welche Fehlerquellen schaltet es aus?
- Checkliste: Maßnahmen mit der größten Wirkung — zugeschnitten auf kleine Teams
- Mindestnachweis: Konkrete Evidenzen (Konfigurationsstände, Logs, Testergebnisse, SBOMs), die die Umsetzung belegen
- Freigabe-Kriterien: Pass/Fail-Kriterien, die sich in Release-Prozesse automatisiert einbauen lassen
Damit werden die Prinzipien auditierbar. Statt „Sicherheit sollte berücksichtigt werden” steht hier, was konkret nachzuweisen ist, bevor ein Release rausgeht.
Lebenszyklusorientierung: Shift Left zu Ende gedacht
Security gehört in jede Phase, nicht nur in die Entwicklung. Das Playbook definiert pro Phase konkrete Aktionen und Arbeitsergebnisse:
| Phase | Kernaktionen | Arbeitsergebnis |
|---|---|---|
| Requirements | Sicherheitskontext definieren, Top-Risiken und Abuse Cases erfassen | 1-Seite Security Context + Anforderungs-Checkliste |
| Design | Architekturdiagramm mit Trust Boundaries, Lightweight Threat Model | Architekturdiagramm + Bedrohungs-/Maßnahmenliste |
| Development | Sichere Defaults im Code, Dependency-Hygiene, SAST/Scanning in CI | CI-Logs + Secure Coding Checklist |
| Testing | Automatisierte Security-Checks, Default-Konfiguration validieren | Release Security Checklist (Pass/Fail) |
| Deployment | Sichere Provisionierung, Least-Privilege Runtime, Monitoring | Deployment Hardening Checklist + Rollback-Plan |
| Maintenance | Patch-SLAs, Vulnerability Monitoring, Incident Handling, EOL-Plan | Schwachstellen-/Patch-Prozess + EOL-Dokumentation |
Aus meiner Beratungspraxis finde ich einen Punkt bemerkenswert: ENISA empfiehlt explizit leichtgewichtige Artefakte — eine Seite Security Context, einfache Diagramme, Checklisten. Automatisierte Controls in CI/CD statt manuelle Reviews. Das spricht für ein realistisches Verständnis der Ressourcenlage bei KMU. Kein 200-Seiten-Sicherheitskonzept, das in der Schublade verstaubt.
Bedrohungsmodellierung als empfohlenes Vorgehen
ENISA empfiehlt, Bedrohungsmodellierung in den Entwicklungsprozess einzubinden. Das freiwillige Playbook begründet jedoch keinen eigenständigen gesetzlichen Pflichtprozess. Davon zu trennen ist die verbindliche Cybersicherheitsrisikobewertung nach Artikel 13 Absatz 2 CRA. Ein leichtgewichtiges Bedrohungsmodell kann diese Bewertung unterstützen, wenn Produktkontext, Angriffswege und Maßnahmen nachvollziehbar erfasst werden.
Fünf Schritte:
- Umfang und Annahmen definieren – was wird geschützt, welche Umgebung, welche Annahmen
- System modellieren — ein einfaches Architektur-/Datenflussdiagramm mit Komponenten, Datenspeichern, externen Entitäten und Einstiegspunkten
- Trust Boundaries und privilegierte Pfade markieren — wo verlaufen die Vertrauensgrenzen, welche Operationen sind hochprivilegiert (Firmware-Update, Admin-Zugang, Key-Provisioning)
- Top-Bedrohungen identifizieren und priorisieren — 5 bis 10 Abuse Cases mit einfacher Likelihood/Impact-Bewertung (High/Medium/Low)
- Mitigations, Secure Defaults und Verifikation festlegen — für jede Bedrohung die Gegenmaßnahme, die Standardkonfiguration und den Verifikationsweg
In OT-Umgebungen muss das Modell zusätzlich die Auswirkungen auf physische Prozesse und Safety-Funktionen erfassen. Dazu gehören die Manipulation von SPS-Logik, ungeschützte Modbus-Kommunikation, laterale Bewegung über Engineering-Workstations und kompromittierte Firmware. OPC UA ist dagegen nicht pauschal ein unsicheres Protokoll: Risiken entstehen unter anderem durch deaktivierte Signatur oder Verschlüsselung sowie mangelhafte Zertifikats- und Rechteverwaltung. Das Sicherheitsmodell erläutert die OPC Foundation.
Machine-Readable Security Manifest (MRSM)
Das spannendste Konzept im Playbook ist das Machine-Readable Security Manifest — ein maschinenlesbares Artefakt, das die Sicherheitslage eines Produkts in festen Feldern abbildet.
Die Idee: Jede Sicherheitszusage (Security Claim) wird an konkrete technische Evidenz gekoppelt — Konfigurationsdaten, Testergebnisse, SBOM-Einträge, Scan-Reports. Keine Behauptung ohne Beleg.
Der praktische Hebel: Compliance-Prüfungen werden automatisierbar. Statt manuelle Audits Zeile für Zeile durchzugehen, kann ein MRSM maschinell validiert werden. Für KMU mit knappen Ressourcen spart das reale Zeit.
Ein „Aber” gibt es: ENISA schreibt kein verbindliches Schema vor. Das Beispiel im Playbook ist illustrativ, kein Standard. Die Standardisierung steht aus. Wer trotzdem heute schon sauber dokumentiert, wird sich die Nachrüstung sparen.
CRA-Mapping: Anhang C schließt die regulatorische Lücke
In der Praxis dürfte Anhang C der Teil sein, den Hersteller zuerst aufschlagen. Er ordnet jedes der 22 Prinzipien den Essential Requirements aus CRA Anhang I zu.
Damit lässt sich sofort ablesen: Welche Prinzipien decken welche CRA-Anforderung ab — und wo fehlt noch etwas? Keine formale Konformitätserklärung, aber ein solider Ausgangspunkt für die eigene Umsetzungsplanung.
Was sich aus dem Mapping ableiten lässt:
- Sicherheitsmaßnahmen müssen über den gesamten Produktlebenszyklus nachweisbar umgesetzt werden
- Schwachstellen sind aktiv zu managen — mit definierten Prozessen und SLAs
- Sicherheitsupdates müssen laufend bereitgestellt werden
- Support-Zeiträume müssen dokumentiert und kommuniziert werden
OT-Relevanz: Was das Playbook für industrielle Umgebungen bedeutet
Für Hersteller industrieller Systeme — ein Bereich, in dem ich regelmäßig Bewertungen durchführe — liefert das Playbook drei sofort nutzbare Ansatzpunkte:
Netzwerksegmentierung nach Zonen-Modell: In meiner Übertragung auf industrielle Anlagen verbinde ich die Playbook-Empfehlungen mit Zonierung und Risikobeurteilung nach IEC 62443-3-2. Das ist eine eigene OT-Einordnung, keine behauptete ausdrückliche Normzuordnung der ENISA. Wartungs-, Monitoring- und Datenverbindungen müssen im Modell erfasst werden; aus einem angenommenen Air Gap folgt noch keine Sicherheitsgarantie. Die erforderlichen Schutzmaßnahmen hängen von Risiken und Kommunikationsbeziehungen ab.
Fernzugriff absichern: Nur über gehärtete Mechanismen — VPN mit Multi-Faktor-Authentifizierung, dedizierte Jump Hosts. Direkte Zugriffe auf kritische Systeme: ausgeschlossen.
OT-spezifische Bedrohungsmodellierung: Die Standard-IT-Analyse reicht nicht. Steuerungslogik-Manipulation, unsichere Industrieprotokolle, kompromittierte Firmware und das Zusammenspiel von Security und Safety gehören ins Modell — kein optionaler Zusatz.
Operative Sicherheit: Resilienz als laufender Prozess
Acht Aktivitäten definiert das Playbook für den laufenden Betrieb. Die vier wichtigsten:
- Schwachstellenmanagement — fortlaufend identifizieren, priorisieren, beheben
- Incident Response — klare Abläufe, wenn es doch passiert
- Backup und Wiederherstellung — Betriebsfähigkeit auch im Störfall
- Sicherheitsmonitoring und Logging — Angriffe erkennen, bevor sie Schaden anrichten
Der Gedanke dahinter: Resilienz ist kein Architektur-Feature, das einmal eingebaut und dann vergessen wird. Resilienz ist Tagesgeschäft — aktiv umgesetzt, regelmäßig geprüft, Stück für Stück verbessert.
Meine Einschätzung
Das finale ENISA-Playbook ist eines der praxistauglicheren Dokumente zur technischen Umsetzung von Security by Design im CRA-Kontext. Die 22 Playbooks mit Checklisten, Nachweisen und Freigabekriterien geben Herstellern einen Rahmen, mit dem sich unmittelbar arbeiten lässt.
Drei Stärken stechen heraus:
Anhang C macht den regulatorischen Bezug zum CRA greifbar — kein Rätselraten, welches Prinzip zu welcher Anforderung gehört. Der MRSM-Ansatz zeigt, wohin Compliance-Dokumentation geht: maschinenlesbar, automatisiert validierbar, skalierbar. Und die KMU-Perspektive mit leichtgewichtigen Artefakten und Automatisierung-First senkt die Einstiegshürde auf ein realistisches Niveau.
Was fehlt: Ein verbindliches MRSM-Schema, tiefergehende OT-Guidance (dafür bleibt IEC 62443 das Referenzwerk) und formale Konformitätszuordnungen. Das Playbook liefert ein „indicative mapping” — keine rechtsverbindliche Zuordnung.
Meine Empfehlung: Das Playbook als Gerüst nehmen, die 22 Prinzipien gegen den eigenen Entwicklungsprozess halten und Lücken schließen. Wer das durchzieht, baut CRA-Readiness auf und verbessert dabei die Produktsicherheit messbar.
Wenn Sie Unterstützung brauchen — ob CRA-Gap-Analyse, Bedrohungsmodellierung für Embedded-Systeme oder die Integration von Security in bestehende Entwicklungsprozesse — melden Sie sich bei mir.