ENISA’s Security by Design Playbook Explained: What It Means for CRA Compliance

In March 2026, ENISA published the “Security by Design and Default Playbook”, a practical guide specifically aimed at SMEs developing products with digital elements. The document is currently in version 0.9 (final draft for public consultation), and it’s the most concrete guidance yet on how to implement the security requirements of the EU Cyber Resilience Act.

This article breaks down what’s in the playbook, why it matters, and how you can use it today.

What the playbook covers

The playbook has five main sections.

Section 2 covers the product security lifecycle and provides a framework for how security activities map to product development phases (requirements, design, development, testing, deployment, maintenance, end-of-life). It includes practical tables showing what to do and what to deliver at each phase, specifically sized for SME constraints.

Section 2.3 covers threat modeling with a step-by-step approach designed for teams without dedicated security expertise: define scope and security objectives, model the system at a useful abstraction level, mark trust boundaries and privileged paths, identify and prioritize top threats (5-10 abuse cases), and define mitigations with secure defaults and verification.

Section 3 defines 22 security principles organized into four groups: Architectural Foundations (how the system is built), Operational Integrity (how it’s maintained), Default Hardening (how it ships), and Guided Protection (how users stay secure).

Section 4 is the core: 22 individual playbooks, one per principle, each with the same structure: Principle, Objective, Checklist, Minimum Evidence, and Release Gate criteria. This is the most actionable part of the entire document.

Section 5 introduces the concept of a Machine-Readable Security Manifest (MRSM), a structured format for expressing security claims with supporting evidence and verification results. This is forward-looking but signals where CRA compliance documentation is heading.

The 22 playbooks at a glance

The Architectural Foundations group covers trust boundaries and threat modeling, least privilege, strong identity and authentication architecture, attack surface minimization, defense in depth, and open design.

The Operational Integrity group covers lifecycle management, user-centric design, secure coding practices, logging monitoring and alerting, configuration and change management, incident response and recovery, vulnerability and patch management, and supply chain controls.

The Default Hardening group covers minimization of default services, restrictive initial access, secure communication by default, and unique device identity and secrets by default.

The Guided Protection group covers mandatory security onboarding, automated maintenance and updates, transparent security posture, and secure recovery and ownership lifecycle.

How it maps to the CRA

Annex C of the playbook provides a direct mapping between each of the 22 principles and the CRA Annex I Essential Requirements. This mapping is enormously valuable because it answers the question every manufacturer asks: “If I implement this principle, which CRA requirements am I covering?”

For example, implementing the “Trust boundaries and threat modeling” playbook supports CRA requirements for risk-based cybersecurity (ANNEX1.PT1.1), unauthorized access protection (ANNEX1.PT1.2.d), confidentiality (ANNEX1.PT1.2.e), integrity (ANNEX1.PT1.2.f), and attack surface limitation (ANNEX1.PT1.2.j).

Why this matters for SMEs

The CRA requires security by design and security by default, but doesn’t tell you exactly how to do it. The ENISA playbook fills that gap with concrete, SME-sized guidance. It acknowledges the constraints SMEs face (limited budget, no dedicated security team, time pressure) and provides lightweight deliverables (one-page documents, simple checklists) instead of heavy enterprise frameworks.

The playbook structure (checklist plus minimum evidence plus release gate) is designed to integrate into agile development workflows. Each playbook can be treated as a sprint task or a definition-of-done criterion.

If you’re looking for a practical starting point for CRA compliance, the ENISA playbook is the best resource available today.

How CompliPeak implements the playbook

CompliPeak turns all 22 ENISA playbooks into interactive checklists with status tracking, evidence upload, and automated CRA requirement mapping. Instead of reading a 72-page PDF and figuring out how to apply it, you get a guided workflow that tells you exactly what to do, what evidence to collect, and which CRA requirements you’re covering.

Join the waitlist to get early access.

ENISA Security by Design Playbook erklärt: Was es für CRA-Compliance bedeutet

Im März 2026 hat ENISA das “Security by Design and Default Playbook” veröffentlicht, einen praktischen Leitfaden speziell für KMUs, die Produkte mit digitalen Elementen entwickeln. Das Dokument liegt in Version 0.9 vor (final Draft zur öffentlichen Konsultation) und ist die bisher konkreteste Anleitung zur Umsetzung der Sicherheitsanforderungen des EU Cyber Resilience Act.

Dieser Artikel fasst zusammen, was im Playbook steht, warum es wichtig ist und wie Sie es heute nutzen können.

Was das Playbook abdeckt

Das Playbook hat fünf Hauptabschnitte.

Section 2 behandelt den Product Security Lifecycle und bietet ein Framework, wie Sicherheitsaktivitäten auf Produktentwicklungsphasen abgebildet werden (Requirements, Design, Entwicklung, Testing, Deployment, Wartung, End-of-Life). Es enthält praktische Tabellen, die zeigen was pro Phase zu tun und zu liefern ist, speziell zugeschnitten auf KMU-Bedingungen.

Section 2.3 behandelt Threat Modeling mit einem Schritt-für-Schritt-Ansatz für Teams ohne dedizierte Security-Expertise: Scope und Security-Objectives definieren, System auf nützlicher Abstraktionsebene modellieren, Trust Boundaries und privilegierte Pfade markieren, Top-Threats identifizieren und priorisieren (5-10 Abuse Cases), und Mitigations mit Secure Defaults und Verifikation definieren.

Section 3 definiert 22 Security-Prinzipien in vier Gruppen: Architectural Foundations (wie das System gebaut wird), Operational Integrity (wie es betrieben wird), Default Hardening (wie es ausgeliefert wird) und Guided Protection (wie User geschützt werden).

Section 4 ist der Kern: 22 einzelne Playbooks, eines pro Prinzip, jeweils mit derselben Struktur: Principle, Objective, Checklist, Minimum Evidence und Release Gate Kriterien. Das ist der handlungsrelevanteste Teil des gesamten Dokuments.

Section 5 führt das Konzept eines Machine-Readable Security Manifest (MRSM) ein, ein strukturiertes Format um Security-Claims mit unterstützenden Nachweisen und Verifikationsergebnissen auszudrücken. Das ist zukunftsgerichtet, zeigt aber wohin CRA-Compliance-Dokumentation sich entwickelt.

Die 22 Playbooks im Überblick

Die Gruppe Architectural Foundations umfasst: Trust Boundaries und Threat Modeling, Least Privilege, Strong Identity und Auth Architecture, Attack Surface Minimisation, Defence in Depth und Open Design.

Die Gruppe Operational Integrity umfasst: Lifecycle Management, User Centric Design, Secure Coding Practices, Logging Monitoring und Alerting, Configuration und Change Management, Incident Response und Recovery, Vulnerability und Patch Management und Supply Chain Controls.

Die Gruppe Default Hardening umfasst: Minimisation of Default Services, Restrictive Initial Access, Secure Communication by Default und Unique Device Identity und Secrets by Default.

Die Gruppe Guided Protection umfasst: Mandatory Security Onboarding, Automated Maintenance und Updates, Transparent Security Posture und Secure Recovery und Ownership Lifecycle.

Wie es auf den CRA mappt

Annex C des Playbooks liefert ein direktes Mapping zwischen jedem der 22 Prinzipien und den CRA Annex I Essential Requirements. Dieses Mapping ist enorm wertvoll, weil es die Frage beantwortet, die jeder Hersteller stellt: “Wenn ich dieses Prinzip umsetze, welche CRA-Anforderungen decke ich damit ab?”

Zum Beispiel unterstützt die Umsetzung des Playbooks “Trust boundaries and threat modelling” die CRA-Anforderungen für risikobasierte Cybersecurity (ANNEX1.PT1.1), Zugriffsschutz (ANNEX1.PT1.2.d), Vertraulichkeit (ANNEX1.PT1.2.e), Integrität (ANNEX1.PT1.2.f) und Attack Surface Limitation (ANNEX1.PT1.2.j).

Warum das für KMUs wichtig ist

Der CRA verlangt Security by Design und Security by Default, sagt aber nicht genau, wie man das umsetzt. Das ENISA-Playbook füllt diese Lücke mit konkreter, KMU-gerechter Anleitung. Es anerkennt die Einschränkungen von KMUs (begrenztes Budget, kein Security-Team, Zeitdruck) und liefert leichtgewichtige Deliverables (einseitige Dokumente, einfache Checklisten) statt schwerer Enterprise-Frameworks.

Die Playbook-Struktur (Checkliste plus Minimum Evidence plus Release Gate) ist darauf ausgelegt, sich in agile Entwicklungsworkflows zu integrieren. Jedes Playbook kann als Sprint-Aufgabe oder Definition-of-Done-Kriterium behandelt werden.

Wenn Sie einen praktischen Einstieg in die CRA-Compliance suchen, ist das ENISA-Playbook die beste verfügbare Ressource.

Wie CompliPeak das Playbook umsetzt

CompliPeak verwandelt alle 22 ENISA Playbooks in interaktive Checklisten mit Status-Tracking, Evidence-Upload und automatischem CRA-Anforderungs-Mapping. Statt ein 72-seitiges PDF zu lesen und herauszufinden wie man es anwendet, bekommen Sie einen geführten Workflow, der Ihnen genau sagt was zu tun ist, welche Nachweise zu sammeln sind und welche CRA-Anforderungen Sie abdecken.

Tragen Sie sich auf die Warteliste ein und erhalten Sie Early Access.