Written by Jordan Hardy

ENISA’s Secure by Design Playbook: Good Start, Hard Questions

ENISA deserves credit.

Its Security by Design and Default Playbook tackles a problem many product teams already face: how to translate high-level secure-by-design expectations into practical engineering work. The playbook provides SMEs and manufacturers with concrete actions, release gates, and evidence expectations rather than another abstract security framework. That matters under the Cyber Resilience Act, where “we thought about security” will not be enough. ENISA’s draft maps secure-by-design and secure-by-default principles to lifecycle activities, practical playbooks, and CRA-related evidence expectations.

The question is not whether the playbook is useful. It is.

The harder question is whether teams will use it to improve product security, or whether it becomes another checklist that product teams complete without changing design decisions. That distinction is where threat modeling matters.

1. What ENISA gets right

ENISA’s playbook is strongest when it operationalizes secure-by-design. The document organizes Security by Design into Architectural Foundations and Operational Integrity, and Security by Default into Default Hardening and Guided Protection. This structure helps teams separate architectural decisions from shipped configuration. “We support MFA” is not the same as “MFA is enabled by default.” That separation is valuable.

The playbook also includes 22 practical playbooks. Each one defines an objective, actions, minimum evidence, and release-gate criteria. That gives teams a way to show how security decisions were made, tested, and reviewed. ENISA also introduces the concept of a Machine-Readable Security Manifest, intended to express security claims, supporting evidence, and verification results in a structured form.

That evidence-first approach is important. Product security now needs proof. Not theatre. A useful, secure-by-design program should produce:

A current system representation.
Explicit trust boundaries.
Prioritized threats.
Mapped controls.
Secure default decisions.
Verification evidence.
Accepted residual risk, where justified.

This is where the playbook aligns well with Toreon’s view: threat modeling is not a workshop artifact. It is a way to connect design decisions, engineering controls, secure defaults, and regulatory evidence.

Toreon’s threat modeling training is built around that exact operating model: learning how to identify and mitigate risks early, using practical exercises and real systems rather than theory-heavy instruction. Toreon offers both in-company training and a 20-hour online course for individuals.

2. What others have already said

The public feedback is broadly constructive.

Andrea Fortuna’s review highlights the playbook’s real value: it treats secure-by-design as an architectural responsibility and positions threat modeling as a living engineering artifact, not a compliance deliverable. Her summary points to useful practices such as minimum viable threat models, refresh triggers, abuse cases, and controls mapped to defaults.

Sarah Fluchs takes a sharper risk-engineering view. She supports the idea of release-gate checklists, but argues that the playbook sometimes conflates risk assessment with threat modeling, stretches “security by design” into lifecycle and operational topics, and risks creating more checklist questions per release. Her core warning is direct: if the threat model has no consequence for requirements, controls, or release decisions, teams will stop updating it. That criticism is valid.

A threat model that does not change the backlog, architecture, test plan, default configuration, or release decision is not useful. It is documentation.

The playbook’s release gates can help, but only if teams connect each threat modeling output to an engineering consequence:

A control added.
A control rejected with rationale.
A secure default changed.
A test added.
A release blocked.
A risk accepted by the right owner.

That is the difference between a checklist and a security decision system.

3. Our threat modeling view: the playbook is useful, but the method needs sharper edges

From a Toreon perspective, ENISA’s playbook is a strong contribution. It lowers the barrier for SMEs. It gives product teams a starting point. It connects secure-by-design work to release evidence. It triggers refreshes when the architecture, authentication, suppliers, interfaces, or update mechanisms change. That is good practice. The risk sits in the implementation.

The Threat Modeling Manifesto defines threat modeling around four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. Our feedback from OWASP community members recommends explicitly using the full Four Question Framework, rather than treating a system diagram as the sole core question.

That matters because teams often stop too early. A diagram is not a threat model. A list of threats is not a threat model. A release checklist is not a threat model.

A useful threat model connects all four questions:

What are we working on?
Scope, architecture, data flows, trust boundaries, assumptions, and deployment context.
What can go wrong?
Threats, abuse scenarios, failure modes, privacy harms, supply-chain exposure, and unsafe defaults.
What are we going to do about it?
Controls, secure defaults, tests, monitoring, design changes, and accepted risks.
Did we do a good enough job?
Review quality, residual risk, verification evidence, release decision, and refresh triggers.

The playbook supports this flow, but it could make the flow more explicit. The same applies to OWASP SAMM. SAMM places threat modeling under Design / Threat Assessment and treats maturity as a progression: from best-effort, risk-based exercises toward repeatable, measurable threat modeling integrated into the development lifecycle. ENISA’s guidance fits well at lower- to middle-maturity levels because it provides concrete artifacts: diagrams, top-threat tables, controls/defaults checklists, CI evidence, and release gates. But ENISA is not a maturity roadmap. Teams still need a way to scale.

That means defining:

Which systems require threat modeling?
Which changes trigger a refresh?
Which techniques fit each product type?
Who must attend?
How findings enter the backlog.
How risk acceptance works.
How quality is measured.
How leadership sees progress.

This is where threat modeling training becomes strategic. A central security team cannot threat-model every product, feature, and release. Delivery teams need the skill to run the first model, refresh it on meaningful change, and escalate high-risk design decisions.

4. Constructive OWASP community feedback: improve the playboob

The OWASP Threat Modeling and OWASP SAMM community feedback was submitted to ENISA as constructive input. The letter states that members of both projects reviewed draft 0.4, focusing on threat modeling, and submitted feedback through the public consultation process.

The main recommendations are practical. First, use the full Four Question Framework. The feedback notes that ENISA references the question “what are we building?”, but recommends the modern phrasing “what are we working on?” and asks ENISA to place it inside the complete four-question structure.
Second, align diagramming guidance with current threat modeling practice. The feedback flags unusual diagram elements in the draft and recommends using common representations, such as DFDs, DFD3, or sequence diagrams, or supported tools, such as OWASP PyTM and OWASP Threat Dragon.
Third, treat likelihood and impact carefully. The feedback argues that likelihood and impact scoring can trigger unproductive debate and should be optional inputs to prioritization, not mandatory mechanics. The goal is structured prioritization, not false precision.
Fourth, avoid making “abuse cases” the only path. Abuse cases are useful, but they are also a specific term of art. The feedback recommends listing abuse cases as one option among others, such as STRIDE, MITRE ATT&CK-based analysis, or STPA-Sec, and asks ENISA to define what it expects an abuse case to contain if the term remains in the playbook.
Fifth, separate entry points from trust boundaries. An entry point is a construct in the system. A trust boundary is a modeling construct that represents a change in trust level or privilege. Treating them as synonyms weakens the analysis.

These are not academic details. They decide whether the playbook helps engineers reason about systems or merely asks them to fill out forms.

5. What product teams should do next

Use the ENISA playbook. Do not use it mechanically. A strong implementation should start with a lean, repeatable threat-modeling workflow that fits engineering realities. For most teams, that means:

Create one system view with trust boundaries.
Identify the most relevant threats or abuse scenarios.
Map each threat to a control, secure default, test, or accepted risk.
Add refresh triggers to the Definition of Done.
Store evidence where engineering already works: tickets, pull requests, CI logs, and architecture records.
Escalate only the decisions that need security, legal, product, or leadership approval.

Do not start with a heavyweight governance process. Start with the product. Then scale.

For leadership, the business value is concrete:

Fewer late security redesigns.
Better release decisions.
Clearer CRA evidence.
Stronger default configurations.
Less dependency on a central security team.
More consistent engineering judgment.

This is also where training pays off. Teams do not need another policy document. They need enough skill to ask better design questions, recognize weak assumptions, and turn threats into engineering work.

Toreon’s threat modeling training is designed for that outcome: hands-on learning, expert guidance, and practical application to real systems, available as in-company training or individual online training.

Want to learn more?

Book a discovery call for Toreon’s threat modeling training and turn the ENISA playbook into a working product-security practice.

Conclusion

ENISA’s Security by Design and Default Playbook is a serious and useful contribution. It gives SMEs and manufacturers a practical route from secure-by-design principles to engineering actions, release gates, and evidence. It also puts threat modeling where it belongs: close to architecture, defaults, verification, and product lifecycle decisions.

The suggested improvements are equally clear. Threat modeling should be organized around the full Four Question Framework. Diagrams should use familiar conventions. Abuse cases should be optional, not mandatory. Prioritization should avoid false precision. Checklists should support expert discussion, not replace it.

The objection is predictable: teams are already overloaded.

That is exactly why the model must be lightweight, repeatable, and tied to delivery.

Toreon helps teams make that shift. Our threat modeling training turns secure-by-design intent into practical capability: engineers who can model systems, identify meaningful threats, select controls, defend secure defaults, and generate evidence without slowing delivery.

About the Author:

Sebastien (Seba) Deleersnyder, co-founder and CTO of Toreon, combines software engineering expertise with a passion for holistic product security. After earning his Master’s in Software Engineering from the University of Ghent, with a thesis on “Hyphenation using neural networks,” he became a driving force in the security community as the founder of the Belgian OWASP chapter, a member of the OWASP Foundation Board, and co-founder of BruCON, Belgium’s annual security conference. His leadership of OWASP SAMM and his decade-long role as a highly rated Black Hat trainer have significantly impacted global software security, earning consistently outstanding feedback from participants. Currently, Seba focuses on adapting security models for DevOps and expanding awareness of AI Threat Modeling.