ENISA has published its Secure by Design and Default Playbook, a set of 22 playbooks on applying secure by design and secure by default principles across the life cycle of a product. The stated aim is to explain the principles as repeatable actions that fit into existing engineering, product and release processes.
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. Each playbook is short and action-oriented rather than a specification.
What is in it
The 22 playbooks fall into four groups.
Architectural foundations covers trust boundaries and threat modelling, least privilege, strong identity and authentication architecture, attack surface minimisation, defence in depth, and open design.
Operational integrity covers life-cycle management, user-centric design, secure coding and verification practices, logging and monitoring and alerting, configuration and change management, incident response and recovery, vulnerability and patch management, and supply-chain controls.
Default hardening covers minimisation of default services, restrictive initial access, secure communication by default, and unique device identity and secrets by default.
Guided protection covers mandatory security onboarding, automated maintenance and updates, transparent security posture, and secure recovery and ownership life cycle.
All 22 are also published in an easy-to-navigate GitHub repository under CC BY 4.0.
What it is not
It is not a 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, and none has been cited yet.
That distinction is worth holding onto, because the playbooks map closely enough onto CRA Annex I Part I that they read like a checklist for it. They are a good way to organise engineering work and to produce evidence that a technical file can use. They are not a route to conformity, and a manufacturer who treats a completed playbook set as a compliance argument will find that it evidences the work rather than discharging the obligation.
There are also gaps against Annex I. Nothing in the 22 reaches the requirement to place a product on the market with no known exploitable vulnerabilities, the data minimisation requirement, or the requirement to limit the impact of an incident on the availability of other devices. Those still need answering separately.
The publication is available on the ENISA website.