01Secure by design vs. secure by default
Secure by design describes how a system is built: threats are modelled early, and architecture patterns, vetted cryptography and systematic vulnerability management are embedded in the development process rather than retrofitted. Secure by default describes how the product arrives at the customer: shipped in the most secure configuration reasonably possible, with no expert knowledge required – protective measures are active, and weakening them takes a deliberate decision. The playbook organises the 14 design principles into Architectural Foundations and Operational Integrity, and the 8 default principles into Default Hardening and Guided Protection.
02The 22 principles at a glance
Architectural Foundations (6) covers trust boundaries and threat modelling, least privilege, a strong identity and authentication architecture, attack surface minimisation, defence in depth and open design. Operational Integrity (8) adds life-cycle management, user-centric design, secure coding and verification, logging and monitoring, configuration and change management, incident response, vulnerability and patch management, and supply-chain controls including SBOMs. On the default side sit minimisation of default services, restrictive initial access, secure communication by default and unique device identities (Default Hardening), plus mandatory security onboarding, automated updates, a transparent security posture and secure recovery and ownership transfer (Guided Protection).
03Playbook anatomy: checklist, evidence, release gate
Every principle follows the same five-block format: principle, objective, a checklist of the highest-impact actions, minimum evidence – the smallest set of artefacts that demonstrates implementation – and a release gate with pass/fail criteria for release reviews or the CI/CD pipeline. Evidence is meant to come from existing engineering artefacts (architecture diagrams, CI logs, tickets, SBOMs) and may serve several playbooks at once; exceptions are allowed, but only documented with an owner and review date. For adoption, ENISA suggests three stages: clarify context and priorities first, then establish an engineering baseline of secure coding, logging, vulnerability management and supply-chain controls – complemented by the default playbooks relevant to the product – and finally broaden coverage and automation. Importantly, the staged approach organises effort; it does not defer any legal obligations.
04Threat modelling, lightweight
Instead of heavyweight analyses, the playbook recommends a minimum viable threat model along the four questions of Shostack's framework: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? The result fits on one page: a diagram with components, data flows and trust boundaries, the five to ten most relevant threat scenarios, controls per scenario including secure-default settings and verification methods – plus defined triggers for refreshing the model. ENISA explicitly names typical anti-patterns: threat modelling as a one-off compliance exercise, over-engineered models with no influence on design decisions, and missing refreshes after product changes. For products with AI components, prompt injection, model poisoning and adversarial inputs belong in the model as well.
05Machine-processable attestation: compliance as code
The most forward-looking part of the document: security claims move out of static PDFs into structured, signable artefacts (JSON/YAML) connecting three layers – security objectives (control layer), implemented controls and their configuration (implementation layer), and automated verification results with evidence hashes (assessment and verification layer). Using the worked SafeGate-X1 example, a Linux industrial controller, ENISA shows how threats become traceable through principles down to automated release gates – from an Nmap scan gate to a read-only file-system test in CI. ENISA deliberately prescribes no new schema and points to existing standards instead: NIST OSCAL, OWASP CycloneDX with CDXA and VEX, the SPDX 3.0 security profile, OpenSSF projects such as Scorecard and SLSA, plus in-toto and Sigstore. It also makes one thing clear: a manufacturer attestation is not proof – verification and independent assessment remain separate steps.
06The CRA bridge: Annex C
Annex B of the playbook lists the essential cybersecurity requirements from Annex I of the Cyber Resilience Act; Annex C maps each of the 22 principles onto them indicatively – automated updates to Annex I Part I 2(c), supply-chain controls to the SBOM obligation in Part II, or restrictive initial access to the secure default configuration under Part I 2(b). That makes the document a useful engineering entry point for CRA gap analyses: teams can see which playbooks feed which requirements and start collecting robust evidence early via the release gates. At the same time, ENISA stresses that following the playbook does not establish CRA conformity – conformity assessment, harmonised standards and the technical documentation required by the regulation remain separate obligations.
Deep dive: EU Cyber Resilience Act → 
