The ENISA Secure by Design and Default Playbook
Twenty-two playbooks, published 30 July 2026, mapped here to the CRA Annex I essential requirements each one produces evidence for. Including the three Annex I requirements that none of them reaches.
Where the playbook fits in CRA compliance
ENISA published the playbook to explain secure by design and secure by default as repeatable actions that fit into engineering, product and release processes already in use. The audience is national and EU authorities and the private sector, with small and medium-sized manufacturers explicitly in view. That focus shows in the format, since each playbook is short and action-oriented rather than a specification to test against.
It is agency guidance rather than a standard, so it sits further from presumption of conformity than any harmonised or supporting standard does. Working through all 22 playbooks evidences the engineering work. It does not discharge the obligation, and nobody assessing your technical file will treat a completed playbook set as a conformity argument.
The practical value is organisational. The 22 map cleanly onto Annex I Part I, so using them as a work breakdown produces evidence in roughly the shape a technical file wants it. The route to presumption of conformity runs through the EN 40000 series instead, once those are cited in the Official Journal.
ENISA Secure by Design and Default Playbook
ENISA Secure by Design and Default Playbook, 22 playbooks, published 30 July 2026
Practical guidance on applying secure by design and secure by default principles across the life cycle of a product, written as repeatable actions that fit into existing engineering, product and release processes. The stated audience is national and EU authorities and the private sector, with small and medium-sized manufacturers explicitly in view.
Agency guidance, not a harmonised standard
ENISA guidance, not a standard and not a CRA harmonised standard. Applying the playbooks does not confer presumption of conformity with the CRA, because only a standard cited in the Official Journal does that. They are a good way to organise engineering work and to produce evidence a technical file can use. A completed playbook set evidences the work rather than discharging the obligation.
| Provision | Requirement & how the platform helps | CRA reference |
|---|---|---|
| Secure by design, architectural foundations | ||
| SbD 1 | Trust boundaries and threat modelling Identify where trust changes hands and model the threats that cross those boundaries. STRIDE threat catalogue and data-flow diagrams attached to each product record. | Annex I Part I (1) |
| SbD 2 | Least privilege Every component and account holds only the permissions its function requires. Elevation-of-privilege threats mapped to the Annex I access-control requirements. | Annex I Part I (2)(d) |
| SbD 3 | Strong identity and authentication architecture Identities are unique and authentication is designed rather than bolted on. Spoofing threats and authentication controls tracked per product. | Annex I Part I (2)(d) |
| SbD 4 | Attack surface minimisation Interfaces, services and features that are not needed are not shipped. Unnecessary-functionality review in the threat model and the Annex I checklist. | Annex I Part I (2)(j) |
| SbD 5 | Defence in depth No single control is load-bearing. Layers are designed to fail independently. Mitigation layering recorded against each threat, with residual risk after treatment. | Annex I Part I (2)(k) |
| SbD 6 | Open design Security rests on the strength of the design and its keys, not on secrecy of the mechanism. Design rationale captured in the risk assessment rather than assumed. | Annex I Part I (1) |
| Secure by design, operational integrity | ||
| SbD 7 | Life-cycle management Support windows, end-of-life and update commitments are defined and honoured. Support-period tracking and documentation-currency review per product. | Annex I Part I (2)(c) |
| SbD 8 | User-centric design The secure path is the easy path, so users are not pushed into unsafe workarounds. Annex II user-information obligations tracked alongside the secure-configuration requirement. | Annex I Part I (2)(b) |
| SbD 9 | Secure coding and verification practices Coding standards, review and testing are applied and their results retained. Security-review scheduling and test evidence attached to the technical file. | Annex I Part II (3) |
| SbD 10 | Logging, monitoring and alerting Security-relevant events are recorded and the records are usable after an incident. Monitoring-source configuration and the append-only audit log. | Annex I Part I (2)(l) |
| SbD 11 | Configuration and change management Changes are controlled and the shipped configuration is known and reproducible. Substantial-modification assessment and evidence versioning per product. | Annex I Part I (2)(f) |
| SbD 12 | Incident response and recovery Response roles, escalation and recovery paths are defined before they are needed. Article 14 three-stage workflow with the 24-hour, 72-hour and final-report clocks. | Annex I Part I (2)(h) |
| SbD 13 | Vulnerability and patch management Reports are received, triaged and remediated on a defined and evidenced process. The public disclosure portal, triage workflow, CSAF advisories and security.txt. | Annex I Part II (2) |
| SbD 14 | Supply-chain controls Third-party components are inventoried and monitored for newly disclosed vulnerabilities. SBOM registry with OSV and EUVD correlation, plus the findings ledger. | Annex I Part II (1) |
| Secure by default, default hardening | ||
| SbDef 15 | Minimisation of default services Services and ports that are not needed for the intended purpose are off out of the box. Attack-surface review recorded against the Annex I secure-configuration requirement. | Annex I Part I (2)(j) |
| SbDef 16 | Restrictive initial access The out-of-box state is closed rather than open, and opening it is a deliberate act. Secure-by-default configuration evidence and the factory-reset objective. | Annex I Part I (2)(b) |
| SbDef 17 | Secure communication by default Transport protection is on by default rather than an option the user must find. Data-in-transit threats and the confidentiality controls tracked per product. | Annex I Part I (2)(e) |
| SbDef 18 | Unique device identity and secrets by default No shared factory credentials. Each unit carries its own identity and secrets. Spoofing threats and the no-universal-default-password control in the Annex I checklist. | Annex I Part I (2)(d) |
| Secure by default, guided protection | ||
| SbDef 19 | Mandatory security onboarding First-run forces the security-relevant decisions rather than deferring them indefinitely. Secure-setup guidance tracked as part of the Annex II user information. | Annex I Part I (2)(b) |
| SbDef 20 | Automated maintenance and updates Security updates reach the field without requiring the user to go looking for them. Update-distribution tracking and CSAF advisory publication. | Annex I Part I (2)(c) |
| SbDef 21 | Transparent security posture Users can see the security state of the product and what it is doing on their behalf. Public advisory publication and the portal status page for reported issues. | Annex I Part II (4) |
| SbDef 22 | Secure recovery and ownership life cycle Reset, resale and decommissioning remove the previous owner's data and access. Data-removal threats and the user-data deletion requirement in the Annex I checklist. | Annex I Part I (2)(m) |
Provision titles reproduced from the ENISA Secure by Design and Default Playbook, published by ENISA under CC BY 4.0. Descriptions and the evidence mapping are our own.
What the 22 playbooks do not cover
The mapping above is the useful half. This is the other half. Three Annex I Part I(2) requirements have no counterpart in the playbook, so a manufacturer who treats the 22 as a complete Annex I work breakdown will have a gap they cannot see.
The playbooks describe practice across the life cycle. None of them establishes the state of the product at the moment it is placed on the market, which is what this requirement tests.
Processing only the data that is adequate, relevant and limited to what is necessary is a design constraint on what the product collects. No playbook addresses it directly.
The requirement to minimise the negative effect a product can have on the availability of services provided by other devices or networks has no counterpart in the 22.
Turn secure-by-design work into Annex I evidence
Track your threat model, SBOM and vulnerability handling against the Annex I checklist, then export an Annex VII technical dossier.