The ENISA Secure by Design and Default Playbook translates 22 security principles into checklists and release gates and maps them to Annex I of the Cyber Resilience Act.
The ENISA published the Secure by Design and Default Playbook on 30 July 2026. It translates 22 security principles into checklists, evidence and release criteria and maps them to the essential requirements from Annex I of the Cyber Resilience Act.
The document is version 1.0 and is published under a CC-BY 4.0 license. Before publication, a public consultation ran in April and May 2026 with 28 contributions, including from BSI, ANSSI, the OWASP Foundation, the Eclipse Foundation and OpenSSF. All 22 playbooks are also available in a GitHub repository.
The ENISA Secure by Design and Default Playbook is a guidance document from the EU Agency for Cybersecurity. It translates secure-by-design and secure-by-default principles into 22 playbooks. Each playbook names a principle, an objective, a checklist, the required evidence and criteria for release approval. The target audience is small and medium-sized manufacturers of products with digital elements.
This refers to companies with fewer than 250 employees and no more than EUR 50 million annual turnover that develop embedded software, IoT devices, networked systems, standalone software or hardware with programmable components.
How are the 22 playbooks structured?
Fourteen principles belong to secure by design. They cover architecture topics such as trust boundaries, least privilege and attack surface minimization, and operational topics such as secure coding, logging, vulnerability management and supply chain controls. Eight principles belong to secure by default. They concern the delivery state, for example disabled services, restrictive initial access and device-unique keys, and user guidance, for example enforced security onboarding and automatic updates.
Each playbook follows the same structure: principle, objective, checklist, minimum evidence, release gate. For restrictive initial access the guidance requires evidence that the build contains no shared or hard-coded credentials and that each device receives its own credentials. The release gate turns this into checkpoints for the release checklist or the CI/CD pipeline.
New documents are not required for this. ENISA refers to existing artefacts from development: architecture diagrams, configurations, tickets, test results, SBOMs and release records. An SBOM can provide evidence for multiple playbooks.
Prior to that comes threat modeling. It determines which playbooks take priority for a product. ENISA uses four guiding questions: what are we building, what can go wrong, what do we do about it, have we done enough. The result is five to ten prioritised threat scenarios.
What is the connection to the Cyber Resilience Act?
Two annexes establish the connection. One reproduces the full text of the essential requirements from Annex I of the Cyber Resilience Act, the other maps each of the 22 principles to the requirements they help to implement. Restrictive initial access thus contributes to secure default configuration and protection against unauthorised access, while automatic updates relate to the provision and secure distribution of security updates.
ENISA describes this mapping as indicative. The guidance is not legal advice and not a compliance manual. Implementing the principles does not make a product CRA-compliant or certified.
For getting started ENISA recommends three stages: first threat modeling, then a technical baseline of secure coding, logging, vulnerability management and supply chain controls, and then the rest. This order concerns the development of internal processes. Obligations under the CRA cannot be deferred by following this sequence.
What does this mean for manufacturers?
The principles are familiar from IEC 62443, ETSI EN 303 645 and from OWASP. What is new is that each principle is linked to required evidence. The CRA requires in Article 13(2) an assessment of cybersecurity risks and in Annex VII a technical documentation showing how the requirements were met. The playbook’s evidence is intended to feed into those obligations.
Take an embedded controller with a web interface and remote maintenance. The requirement “secure default configuration” is abstract in the legal text. The guidance turns it into four checkpoints: no shared credentials in the production build, unique credentials per device, forced change before first administrative use, and a verified list of factory-enabled services.
For machine and plant engineering ENISA notes a caveat: embedded products, field devices and industrial applications are within scope, but the recommendations must be adapted to their operating conditions. Automatic security updates are considered the standard. Where unattended installation could jeopardise safety, availability or operations, the guidance foresees maintenance windows, phased rollouts and operator consent. In running plants this is the norm.
The guidance does not replace product-specific risk assessment or the process requirements from EN 40000 or IEC 62443-4-1. It provides a framework to check whether your development and release processes cover what the CRA expects.
The playbook shows what evidence a CRA-compliant development process should generate. It does not say which of the 22 principles apply to a specific product and to what depth.
