Security by Design steht seit Jahren in jedem zweiten Positionspapier. Meistens bleibt es beim Schlagwort. Mit dem „Secure by Design and Default Playbook” (Version 0.9, März 2026) hat die ENISA jetzt nachgelegt — 22 Sicherheitsprinzipien, Checklisten, Nachweisanforderungen und messbare Freigabekriterien. Zugeschnitten auf Hersteller, die den Cyber Resilience Act ernst nehmen.
Ich habe das 70-seitige Dokument durchgearbeitet. Was steckt drin, was hilft im Tagesgeschäft — und wo muss man trotzdem selbst ran?
Was das Playbook ist — und was nicht
Das Playbook richtet sich an KMU, die Produkte mit digitalen Elementen herstellen — Embedded Software, IoT-Geräte, vernetzte Systeme, Standalone-Software. Keine Compliance-Checkliste, kein Zertifizierungsersatz. Wer alles umsetzt, hat trotzdem keinen 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 Deliverables:
| Phase | Kernaktionen | Deliverable |
|---|---|---|
| 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 Pflichtprozess
Threat Modelling wird im Playbook zum Pflichtbestandteil des Entwicklungsprozesses. Aber pragmatisch: ENISA empfiehlt ein „Minimum Viable Threat Model” — schnell erstellt, leicht aktualisierbar, eng an die Entwicklung gekoppelt.
Fünf Schritte:
- Scope 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 reicht das nicht. Hier kommen Angriffsvektoren dazu, die in der IT schlicht nicht existieren: Manipulation von SPS-/PLC-Logik, unsichere Industrieprotokolle wie Modbus oder OPC UA, laterale Bewegung über Engineering-Workstations, Supply-Chain-Angriffe über kompromittierte Firmware. Das Bedrohungsmodell muss in der OT auch die Auswirkungen auf physische Prozesse und Safety-Funktionen einbeziehen — ein Punkt, den ich bei Bewertungen immer wieder als blinden Fleck sehe.
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: Das Playbook lehnt sich hier an IEC 62443 an — Sicherheitsbereiche klar abgrenzen, Kommunikationsbeziehungen kontrollieren. Der oft zitierte Air Gap taugt nicht als Sicherheitsgarantie. Reale Verbindungen für Wartung, Monitoring und Datenintegration existieren fast immer und müssen durch Firewalls, Protokoll-Gateways und überwachte Schnittstellen abgesichert werden.
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 ENISA Playbook ist das praxistauglichste Dokument, das ich bisher zur technischen Umsetzung von Security by Design im CRA-Kontext gelesen habe. Die 22 Prinzipien mit Checklisten, Nachweisen und Freigabekriterien geben Herstellern einen Rahmen, mit dem sich tatsächlich 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.