ENISA Secure by Design and Default Playbook
On July 30, 2026, ENISA published the Secure by Design and Default Playbook. It translates 22 security principles into checklists, evidence, and release criteria. It also maps them to the essential cybersecurity requirements in Annex I of the Cyber Resilience Act.
Contents
What has ENISA published?
The document is available as version 1.0 under the CC BY 4.0 license. It was preceded by a public consultation in April and May 2026 with 28 contributions. Contributors included Germany's Federal Office for Information Security (BSI), France's national cybersecurity agency (ANSSI), the OWASP Foundation, the Eclipse Foundation, and the OpenSSF. All 22 playbooks are also available in a GitHub repository.
What is the ENISA Secure by Design and Default Playbook?
The ENISA Secure by Design and Default Playbook is a guide from the EU Agency for Cybersecurity. It translates secure by design and secure by default principles into 22 playbooks. Each playbook states a principle, an objective, a checklist, the required evidence, and criteria for release approval. The target group is small and medium-sized manufacturers of products with digital elements.
This means companies with fewer than 250 employees and an annual turnover below €50 million. They develop embedded software, IoT devices, connected systems, standalone software, or hardware with programmable components.
How are the 22 playbooks structured?
Fourteen principles belong to secure by design. They cover the architecture, such as trust boundaries, least privilege, and minimizing the attack surface. They also cover ongoing operations, such as secure coding, logging, vulnerability management, and supply chain controls. Eight principles belong to secure by default. They concern the delivery state, such as disabled services, restrictive initial access, and device-unique keys. They also concern user guidance, such as enforced security onboarding and automatic updates.
Each playbook follows the same structure: principle, objective, checklist, minimum evidence, and release gate. For restrictive initial access, the guide 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 check items for the release checklist or the CI/CD pipeline.
No new documents are needed for this. ENISA refers to existing development records: architecture diagrams, configurations, tickets, test results, SBOMs, and release records. One SBOM can cover the evidence for several playbooks.
Threat modeling comes first. It decides which playbooks take priority for a product. ENISA uses four guiding questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? Five to ten prioritized threat scenarios are enough as a result.
How does the playbook connect to the Cyber Resilience Act?
Two annexes establish the link. One reproduces the essential cybersecurity requirements from Annex I of the Cyber Resilience Act in full. The other maps each of the 22 principles to the requirements it helps to implement. Restrictive initial access, for example, contributes to a secure by default configuration and to protection from unauthorized access. Automatic updates contribute to providing and securely distributing security updates.
ENISA calls this mapping indicative. The guide is neither legal advice nor a compliance manual. Implementing the principles does not make you CRA-compliant or certified.
To get started, ENISA recommends three stages. First comes threat modeling. Second comes a technical baseline of secure coding, logging, vulnerability management, and supply chain controls. Everything else follows. This order concerns building your own processes. It does not allow you to postpone obligations under the CRA.
What does this mean for manufacturers?
The principles are familiar from IEC 62443, ETSI EN 303 645, and OWASP. What is new is that each principle is tied to evidence. Article 13(2) of the CRA requires an assessment of cybersecurity risks. Annex VII requires technical documentation that shows how the requirements were met. That is where the evidence comes in.
Take an embedded controller with a web interface and remote maintenance. As legal text, the requirement for a “secure by default configuration” is abstract. The guide turns it into four check items:
- no shared credentials in the production build,
- unique credentials for each device,
- a forced change before the first administrative use, and
- a reviewed list of the services active by default.
For machinery and plant engineering, ENISA notes a limitation. Embedded products, field devices, and industrial applications are in scope, but the recommendations must be adapted to their constraints. Automatic security updates are the default. Where unattended installation could disrupt safety, availability, or operations, the guide provides for approval windows, staged rollout, and operator consent. In running plants, that is the norm.
The guide replaces neither the product-specific risk assessment nor the process requirements of EN 40000 or IEC 62443-4-1. It provides a grid for checking whether your own development and release processes cover what the CRA requires.
The playbook shows which evidence a CRA-compliant development process must produce. It does not say which of the 22 principles apply to a specific product, or in how much depth.
