The Cyber Resilience Act requires products to be designed, developed and produced with an appropriate level of cybersecurity, and to ship with a secure default configuration. It doesn’t say how. In July 2026, ENISA, the EU Agency for Cybersecurity, published the Secure by Design and Default Playbook to fill part of that gap for small and medium-sized manufacturers.
It’s one of the most practical documents to come out of the CRA ecosystem so far. This article summarizes what’s in it and how to use it.
What it is, and what it isn’t
The playbook is version 1.0, published after a public consultation in April and May 2026 that drew 28 contributions from manufacturers, practitioners and the open-source community. It’s free and licensed under CC BY 4.0.
Its audience is SMEs that build products with digital elements: embedded software, IoT devices, connected systems, stand-alone software and hardware with programmable components. It’s written for the people doing the work: developers, technical product managers, architects and the security lead who often wears several other hats.
ENISA is explicit about its limits. The playbook isn’t legal guidance and isn’t a compliance manual. Following it doesn’t by itself make a product compliant with the CRA or certifiable against a standard. It’s a practical starting point that turns principles into repeatable engineering actions, and an annex maps those principles to the CRA’s essential requirements.
How it’s organized
The document has five parts:
- Secure by design and default across the product life cycle, including lightweight risk management and threat modeling.
- The secure by design and secure by default principles.
- One playbook per principle, 22 in total. This is the core of the document.
- Machine-processable attestation: how to express security claims and evidence in a format tools can verify.
- Annexes listing the CRA essential requirements and mapping each principle to them.
Life cycle and risk management, kept lightweight
The playbook follows a product through six life-cycle processes: requirements, design, implementation, verification, deployment, and maintenance and disposal. For each, it lists actions and a concrete deliverable, and the deliverables are deliberately small: a one-page security context, one architecture diagram with trust boundaries, a short requirements checklist, a release security checklist, a one-page vulnerability and patch process.
Three rules run through it for SMEs:
- Use small, reusable artifacts: one-page notes, simple diagrams, checklists.
- Prefer automated controls in CI/CD over manual reviews, and keep deep reviews for high-risk changes.
- Add fast security gates to the rituals you already have, such as the definition of done, pull request checks and the release checklist.
Risk management gets the same treatment. Instead of a formal framework, the playbook proposes a short set of activities: a one- or two-page product security context, a list of key assets and adverse effects, a living risk register of 10 to 30 risks, a one-page risk acceptance policy, a pre-release risk review, and reassessment when something significant changes. The risk acceptance policy includes non-negotiables, such as never accepting misuse of the update mechanism, unauthorized admin access or exploitable default credentials.
Threat modeling for teams without a threat modeling expert
Threat modeling sits at the center of the approach. The playbook organizes it around Shostack’s four 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?
For most SME products the goal is a “minimum viable model”: one diagram with trust boundaries and privileged paths, the top 5 to 10 threat scenarios with a priority, a mitigation and secure default for each, a verification method for each control, and defined triggers for when the model must be refreshed, such as a new internet-facing interface or a changed authentication model. STRIDE is offered as one way to find threats, not the only one.
Two points I’d underline. ENISA says lightweight threat modeling doesn’t require threat modeling specialists, but it does require people who know the product well. And it names the anti-patterns: treating threat modeling as a one-off compliance exercise, building models that don’t influence any design decision, and never updating them. For products with AI components, it asks teams to consider AI-specific attacks such as prompt injection and model poisoning.
22 principles in four groups
The principles are split between secure by design (how the product is engineered) and secure by default (how it arrives and behaves when the user first switches it on), each with two groups:
| Group | Principles |
|---|---|
| Secure by design: architectural foundations | Trust boundaries and threat modelling; least privilege; strong identity and authentication architecture; attack surface minimisation; defence in depth; open design |
| Secure by design: operational integrity | Life-cycle management; user-centric design; secure coding and verification practices; logging, monitoring and alerting; configuration and change management; incident response and recovery; vulnerability and patch management; supply-chain controls |
| Secure by default: default hardening | Minimisation of default services; restrictive initial access; secure communication by default; unique device identity and secrets by default |
| Secure by default: guided protection | Mandatory security onboarding; automated maintenance and updates; transparent security posture; secure recovery and ownership life cycle |
Most of these will be familiar to anyone who has worked in application security. The secure by default group is where many products still fall short in practice: no shared admin/admin credentials, unique per-device keys, encryption from the first connection, automatic security updates switched on, a set-up wizard that forces the important security choices, and a clear warning with a one-click way back when a user weakens the configuration.
The playbooks: checklist, evidence, release gate
Each of the 22 playbooks fits on roughly one page and uses the same five headings:
- the principle being implemented
- the objective, including the failures it prevents
- a checklist of the highest-impact actions for a lean team
- the minimum evidence that shows the checklist was implemented
- a release gate: pass or fail criteria you can copy into a release review or CI/CD pipeline
The vulnerability and patch management playbook shows how concrete this gets. Its checklist covers intake channels with a single owner, triage with “internet-exposed” and “known exploited” flags, a regular cadence for dependency updates, awareness of reporting deadlines, and publishing machine-readable advisories with CSAF and VEX where proportionate. The minimum evidence includes a vulnerability register, defined SLAs, scan output from CI, an SBOM per release and an exception log with owners and expiry dates. The release gate then checks, among other things, that critical and high findings are fixed or carry a documented, time-bound exception, and that the SBOM for the release exists.
The evidence section is the most valuable part for CRA preparation. ENISA stresses that evidence doesn’t need separate documents: one SBOM, scan result or release record can serve several playbooks, and existing engineering records such as diagrams, tickets, test results and CI output should be reused. That’s exactly the mindset that keeps technical documentation from becoming a separate project.
Where to start
The playbooks don’t all need to be adopted at once. The suggested order:
- Establish context and priorities with the risk management and threat modeling activities and the trust boundaries playbook.
- Build a foundational engineering baseline: secure coding and verification, logging and monitoring, vulnerability and patch management, and supply-chain controls. Add the secure by default playbooks that apply to your product: restrictive initial access if it has user or admin access, secure communication if it talks over a network, unique identities and secrets if it uses credentials, and automated updates if it can be updated.
- Broaden and strengthen the rest over time, increasing coverage, consistency and automation.
ENISA adds an important caveat: progressive adoption doesn’t mean postponing anything the CRA requires. The sequence is about managing effort, not about deadlines.
Machine-processable attestation
The most forward-looking part of the playbook is about evidence that machines can read. Instead of PDF reports, a manufacturer publishes structured security claims, for example in JSON, linked to the evidence behind them and to the verification results. The illustrative example, a factory gate controller called SafeGate-X1, uses three layers:
- a control layer with the security objectives, such as protection against unauthorized access
- an implementation layer with the claims about how each objective is met and the tools, versions and configurations involved
- an assessment and verification layer that links to test results, SAST summaries and hashes of build artifacts
The playbook doesn’t propose a new format. It points to existing work: NIST’s OSCAL, CycloneDX attestations (CDXA), the SPDX 3.0 security profile, OpenSSF Security Insights and Scorecard, SLSA provenance with in-toto and Sigstore, and the Transparency Exchange API from Ecma TC54. It also suggests splitting public, signed claims from a restricted technical layer that only authorized parties can access.
ENISA is careful here too: an attestation from the manufacturer isn’t proof that a product is secure. Attestation, verification and independent assessment are separate activities. Still, the direction is clear. Technical documentation that’s generated from the pipeline stays current, and a build that can’t produce its evidence can be stopped automatically.
The mapping to the CRA
Annex C maps each principle to the CRA’s essential requirements in Annex I. Trust boundaries and threat modeling, for example, support the risk assessment, protection against unauthorized access, confidentiality and integrity, and attack surface limitation. Vulnerability and patch management maps to identifying and documenting components and to remediating vulnerabilities without delay.
The mapping is indicative, and it doesn’t give presumption of conformity. That will come from harmonised standards once they’re cited in the Official Journal; see our overview of the CRA harmonised standards for where they stand. But it’s a useful way to check that your secure development practices cover each essential requirement, and to find the evidence you’ll need for the technical documentation.
How it fits with OWASP SAMM
The playbook names OWASP SAMM as one way to organize and mature security activities across the life cycle, and its threat assessment and security requirements practices as an example of turning threats into testable requirements. The two work well together. SAMM tells you how mature each practice is and what the next step looks like; the playbook gives you concrete checklists, evidence and release gates for individual principles. Our articles on choosing between SAMM and BSIMM and on SAMM metrics cover the maturity side.
Our take
For an SME preparing for the CRA, this is the document I’d hand to the engineering lead first. It’s short where it can be, concrete where it matters, and it treats evidence as a by-product of normal engineering work rather than a separate compliance effort. The release gates in particular can go straight into a definition of done or a CI pipeline.
Two things to keep in mind. It’s an introduction, not a complete method: products for critical or high-risk use will need more depth than the minimum viable versions described here. And it doesn’t replace the risk assessment the CRA requires for each product; it helps you do it.
If you want help putting the playbooks into practice, our threat modeling training covers the design-time activities, our SSDLC maturity assessment shows where your development process stands today, and work package 6 of the EU CRA Compliance Journey puts secure by design and by default into practice.