Der Cyber Resilience Act verlangt, dass Produkte mit einem angemessenen Cybersicherheitsniveau konzipiert, entwickelt und hergestellt und mit einer sicheren Standardkonfiguration ausgeliefert werden. Wie, sagt er nicht. Im Juli 2026 hat die ENISA, die Agentur der EU für Cybersicherheit, das Secure by Design and Default Playbook veröffentlicht, um diese Lücke für kleine und mittlere Hersteller teilweise zu schließen.
Es ist eines der praxisnächsten Dokumente, die bisher rund um den CRA erschienen sind. Dieser Artikel fasst zusammen, was darin steht und wie Sie es nutzen.
Was es ist, und was nicht
Das Playbook liegt in Version 1.0 vor. Es wurde nach einer öffentlichen Konsultation im April und Mai 2026 veröffentlicht, die 28 Beiträge von Herstellern, Praktikern und der Open-Source-Community erbrachte. Es ist kostenlos und steht unter der Lizenz CC BY 4.0.
Zielgruppe sind KMU, die Produkte mit digitalen Elementen entwickeln: Embedded Software, IoT-Geräte, vernetzte Systeme, eigenständige Software und Hardware mit programmierbaren Komponenten. Es richtet sich an die Menschen, die die Arbeit machen: Entwickler, technische Produktmanager, Architekten und die Security-Verantwortlichen, die oft noch mehrere andere Rollen haben.
Die ENISA ist deutlich, was die Grenzen angeht. Das Playbook ist keine Rechtsberatung und kein Compliance-Handbuch. Wer es befolgt, macht ein Produkt dadurch nicht automatisch CRA-konform oder nach einer Norm zertifizierbar. Es ist ein praktischer Ausgangspunkt, der Prinzipien in wiederholbare Engineering-Schritte übersetzt, und ein Anhang ordnet diese Prinzipien den grundlegenden Anforderungen des CRA zu.
Wie es aufgebaut ist
Das Dokument hat fünf Teile:
- Secure by Design und Default über den gesamten Produktlebenszyklus, einschließlich schlankem Risikomanagement und Threat Modeling.
- Die Prinzipien von Secure by Design und Secure by Default.
- Ein Playbook pro Prinzip, insgesamt 22. Das ist der Kern des Dokuments.
- Maschinenlesbare Attestierung: wie sich Sicherheitsaussagen und Nachweise in einem Format ausdrücken lassen, das Tools prüfen können.
- Anhänge mit den grundlegenden Anforderungen des CRA und der Zuordnung jedes Prinzips.
Lebenszyklus und Risikomanagement, schlank gehalten
Das Playbook begleitet ein Produkt durch sechs Lebenszyklusprozesse: Anforderungen, Design, Implementierung, Verifikation, Bereitstellung sowie Wartung und Außerbetriebnahme. Für jeden nennt es Maßnahmen und ein konkretes Ergebnis, und die Ergebnisse sind bewusst klein: ein einseitiger Sicherheitskontext, ein Architekturdiagramm mit Vertrauensgrenzen, eine kurze Anforderungs-Checkliste, eine Sicherheits-Checkliste für Releases, ein einseitiger Prozess für Schwachstellen und Patches.
Drei Regeln für KMU ziehen sich hindurch:
- Nutzen Sie kleine, wiederverwendbare Artefakte: einseitige Notizen, einfache Diagramme, Checklisten.
- Bevorzugen Sie automatisierte Kontrollen in CI/CD gegenüber manuellen Reviews und heben Sie tiefe Reviews für Änderungen mit hohem Risiko auf.
- Ergänzen Sie schnelle Security Gates in den Routinen, die Sie schon haben, etwa der Definition of Done, den Prüfungen von Pull Requests und der Release-Checkliste.
Das Risikomanagement wird genauso behandelt. Statt eines formalen Frameworks schlägt das Playbook eine kurze Reihe von Aktivitäten vor: einen ein- bis zweiseitigen Produktsicherheitskontext, eine Liste wichtiger Werte und negativer Auswirkungen, ein lebendes Risikoregister mit 10 bis 30 Risiken, eine einseitige Richtlinie zur Risikoakzeptanz, eine Risikoprüfung vor dem Release und eine Neubewertung bei wesentlichen Änderungen. Die Akzeptanzrichtlinie enthält nicht verhandelbare Punkte, etwa niemals Missbrauch des Update-Mechanismus, unbefugten Admin-Zugang oder ausnutzbare Standardzugangsdaten zu akzeptieren.
Threat Modeling für Teams ohne Threat-Modeling-Experten
Threat Modeling steht im Zentrum des Ansatzes. Das Playbook organisiert es entlang der vier Fragen von Shostack:
- Woran arbeiten wir?
- Was kann schiefgehen?
- Was tun wir dagegen?
- Haben wir das gut genug gemacht?
Für die meisten KMU-Produkte ist das Ziel ein “Minimum Viable Model”: ein Diagramm mit Vertrauensgrenzen und privilegierten Pfaden, die wichtigsten 5 bis 10 Bedrohungsszenarien mit Priorität, für jedes eine Gegenmaßnahme und eine sichere Voreinstellung, für jede Maßnahme eine Verifikationsmethode und festgelegte Auslöser, wann das Modell aktualisiert werden muss, etwa eine neue Schnittstelle zum Internet oder ein geändertes Authentifizierungsmodell. STRIDE wird als eine Möglichkeit angeboten, Bedrohungen zu finden, nicht als die einzige.
Zwei Punkte möchte ich hervorheben. Die ENISA sagt, schlankes Threat Modeling brauche keine Threat-Modeling-Spezialisten, wohl aber Menschen, die das Produkt gut kennen. Und sie benennt die Anti-Patterns: Threat Modeling als einmalige Compliance-Übung, Modelle, die keine Designentscheidung beeinflussen, und Modelle, die nie aktualisiert werden. Bei Produkten mit KI-Komponenten sollen Teams KI-spezifische Angriffe wie Prompt Injection und Model Poisoning berücksichtigen.
22 Prinzipien in vier Gruppen
Die Prinzipien teilen sich auf Secure by Design (wie das Produkt entwickelt wird) und Secure by Default (wie es ankommt und sich verhält, wenn der Nutzer es zum ersten Mal einschaltet), jeweils mit zwei Gruppen:
| Gruppe | Prinzipien |
|---|---|
| Secure by Design: architektonische Grundlagen | Vertrauensgrenzen und Threat Modeling; Least Privilege; starke Architektur für Identität und Authentifizierung; Minimierung der Angriffsfläche; Defence in Depth; Open Design |
| Secure by Design: betriebliche Integrität | Lebenszyklusmanagement; nutzerzentriertes Design; sichere Programmierung und Verifikation; Logging, Monitoring und Alarmierung; Konfigurations- und Änderungsmanagement; Incident Response und Wiederherstellung; Schwachstellen- und Patchmanagement; Kontrollen in der Lieferkette |
| Secure by Default: Härtung ab Werk | Minimale Standarddienste; restriktiver Erstzugang; sichere Kommunikation als Standard; eindeutige Geräteidentität und Secrets als Standard |
| Secure by Default: geführter Schutz | Verpflichtendes Security-Onboarding; automatisierte Wartung und Updates; transparenter Sicherheitsstatus; sicherer Lebenszyklus für Wiederherstellung und Eigentum |
Die meisten davon kennt jeder, der in der Anwendungssicherheit gearbeitet hat. Bei Secure by Default bleiben viele Produkte in der Praxis noch zurück: keine gemeinsamen admin/admin-Zugangsdaten, eindeutige Schlüssel pro Gerät, Verschlüsselung ab der ersten Verbindung, standardmäßig aktivierte automatische Sicherheitsupdates, ein Einrichtungsassistent, der die wichtigen Sicherheitsentscheidungen erzwingt, und eine klare Warnung mit einem Weg zurück per Klick, wenn ein Nutzer die Konfiguration schwächt.
Die Playbooks: Checkliste, Nachweis, Release Gate
Jedes der 22 Playbooks passt auf etwa eine Seite und nutzt dieselben fünf Überschriften:
- das umgesetzte Prinzip
- das Ziel, einschließlich der Fehler, die es verhindert
- eine Checkliste mit den wirkungsvollsten Maßnahmen für ein kleines Team
- der Mindestnachweis, dass die Checkliste umgesetzt wurde
- ein Release Gate: Bestanden-/Nicht-bestanden-Kriterien, die Sie in ein Release-Review oder eine CI/CD-Pipeline übernehmen können
Das Playbook für Schwachstellen- und Patchmanagement zeigt, wie konkret das wird. Seine Checkliste umfasst Meldekanäle mit einem Verantwortlichen, eine Triage mit den Kennzeichen “aus dem Internet erreichbar” und “bekannt ausgenutzt”, einen festen Rhythmus für Updates von Abhängigkeiten, Kenntnis der Meldefristen und die Veröffentlichung maschinenlesbarer Advisories mit CSAF und VEX, wo verhältnismäßig. Der Mindestnachweis umfasst ein Schwachstellenregister, festgelegte SLAs, Scan-Ergebnisse aus der CI, eine SBOM pro Release und ein Ausnahmeprotokoll mit Verantwortlichen und Ablaufdaten. Das Release Gate prüft dann unter anderem, dass kritische und hohe Befunde behoben sind oder eine dokumentierte, befristete Ausnahme haben und dass die SBOM für das Release existiert.
Der Abschnitt zu Nachweisen ist für die CRA-Vorbereitung der wertvollste Teil. Die ENISA betont, dass Nachweise keine eigenen Dokumente brauchen: Eine SBOM, ein Scan-Ergebnis oder ein Release-Protokoll kann mehreren Playbooks dienen, und vorhandene Engineering-Unterlagen wie Diagramme, Tickets, Testergebnisse und CI-Ausgaben sollen wiederverwendet werden. Genau diese Haltung verhindert, dass die technische Dokumentation zu einem eigenen Projekt wird.
Wo Sie anfangen
Die Playbooks müssen nicht alle auf einmal eingeführt werden. Die vorgeschlagene Reihenfolge:
- Kontext und Prioritäten klären, mit den Aktivitäten für Risikomanagement und Threat Modeling und dem Playbook zu Vertrauensgrenzen.
- Eine technische Basis aufbauen: sichere Programmierung und Verifikation, Logging und Monitoring, Schwachstellen- und Patchmanagement sowie Kontrollen in der Lieferkette. Dazu die Secure-by-Default-Playbooks, die für Ihr Produkt gelten: restriktiver Erstzugang, wenn es Nutzer- oder Admin-Zugang hat, sichere Kommunikation, wenn es über ein Netzwerk kommuniziert, eindeutige Identitäten und Secrets, wenn es Zugangsdaten nutzt, und automatisierte Updates, wenn es aktualisiert werden kann.
- Den Rest mit der Zeit ausbauen und stärken, mit mehr Abdeckung, Konsistenz und Automatisierung.
Die ENISA fügt einen wichtigen Hinweis hinzu: Schrittweise Einführung heißt nicht, etwas aufzuschieben, was der CRA verlangt. Die Reihenfolge dient der Verteilung des Aufwands, nicht den Fristen.
Maschinenlesbare Attestierung
Der zukunftsweisendste Teil des Playbooks handelt von Nachweisen, die Maschinen lesen können. Statt PDF-Berichten veröffentlicht ein Hersteller strukturierte Sicherheitsaussagen, etwa in JSON, verknüpft mit den Nachweisen dahinter und den Verifikationsergebnissen. Das Beispiel, eine Steuerung für ein Werkstor namens SafeGate-X1, nutzt drei Ebenen:
- eine Kontrollebene mit den Sicherheitszielen, etwa dem Schutz vor unbefugtem Zugriff
- eine Implementierungsebene mit den Aussagen, wie jedes Ziel erreicht wird, und den beteiligten Tools, Versionen und Konfigurationen
- eine Bewertungs- und Verifikationsebene, die auf Testergebnisse, SAST-Zusammenfassungen und Hashes von Build-Artefakten verweist
Das Playbook schlägt kein neues Format vor. Es verweist auf bestehende Arbeiten: OSCAL von NIST, CycloneDX-Attestierungen (CDXA), das Sicherheitsprofil von SPDX 3.0, OpenSSF Security Insights und Scorecard, SLSA-Provenance mit in-toto und Sigstore sowie die Transparency Exchange API von Ecma TC54. Außerdem schlägt es vor, öffentliche, signierte Aussagen von einer geschützten technischen Ebene zu trennen, auf die nur berechtigte Parteien zugreifen.
Auch hier ist die ENISA vorsichtig: Eine Attestierung des Herstellers beweist nicht, dass ein Produkt sicher ist. Attestierung, Verifikation und unabhängige Bewertung sind getrennte Tätigkeiten. Die Richtung ist trotzdem klar. Technische Dokumentation, die aus der Pipeline erzeugt wird, bleibt aktuell, und ein Build, der seine Nachweise nicht liefern kann, lässt sich automatisch stoppen.
Die Zuordnung zum CRA
Anhang C ordnet jedes Prinzip den grundlegenden Anforderungen in Anhang I des CRA zu. Vertrauensgrenzen und Threat Modeling unterstützen zum Beispiel die Risikobewertung, den Schutz vor unbefugtem Zugriff, Vertraulichkeit und Integrität sowie die Begrenzung der Angriffsfläche. Schwachstellen- und Patchmanagement gehört zur Identifizierung und Dokumentation von Komponenten und zur unverzüglichen Behebung von Schwachstellen.
Die Zuordnung ist indikativ und begründet keine Konformitätsvermutung. Die kommt von harmonisierten Normen, sobald sie im Amtsblatt genannt sind; unsere Übersicht der harmonisierten CRA-Normen zeigt, wo sie stehen. Sie ist aber ein nützliches Mittel, um zu prüfen, ob Ihre sicheren Entwicklungspraktiken jede grundlegende Anforderung abdecken, und um die Nachweise zu finden, die Sie für die technische Dokumentation brauchen.
Wie es zu OWASP SAMM passt
Das Playbook nennt OWASP SAMM als eine Möglichkeit, Sicherheitsaktivitäten über den Lebenszyklus zu organisieren und reifer zu machen, und die Practices Threat Assessment und Security Requirements als Beispiel dafür, Bedrohungen in prüfbare Anforderungen zu übersetzen. Beide ergänzen sich gut. SAMM sagt Ihnen, wie reif jede Practice ist und wie der nächste Schritt aussieht; das Playbook liefert konkrete Checklisten, Nachweise und Release Gates für einzelne Prinzipien. Unsere Artikel zur Wahl zwischen SAMM und BSIMM und zu SAMM-Kennzahlen behandeln die Reifegradseite.
Unsere Einschätzung
Für ein KMU, das sich auf den CRA vorbereitet, ist das das Dokument, das ich der Entwicklungsleitung als Erstes geben würde. Es ist kurz, wo es geht, konkret, wo es darauf ankommt, und es behandelt Nachweise als Nebenprodukt normaler Engineering-Arbeit statt als eigenen Compliance-Aufwand. Besonders die Release Gates lassen sich direkt in eine Definition of Done oder eine CI-Pipeline übernehmen.
Zwei Dinge sollten Sie im Kopf behalten. Es ist eine Einführung, keine vollständige Methode: Produkte für kritische oder risikoreiche Einsätze brauchen mehr Tiefe als die hier beschriebenen Minimalversionen. Und es ersetzt nicht die Risikobewertung, die der CRA für jedes Produkt verlangt; es hilft Ihnen dabei.
Wenn Sie Unterstützung bei der Umsetzung der Playbooks möchten: Unser Threat Modeling Training deckt die Aktivitäten in der Designphase ab, unser SSDLC Maturity Assessment zeigt, wo Ihr Entwicklungsprozess heute steht, und Arbeitspaket 6 der EU CRA Compliance Journey bringt Secure by Design und by Default in die Praxis.