ENISA Secure by Design and Default Playbook

The current version of this report was prepared following a public consultation held by ENISA during April 2026 and May 2026. ENISA received 28 contributions from public and private stakeholders, cybersecurity experts, product manufacturers, software development practitioners and the open-source community. We would like to publicly thank all stakeholders who provided their views and feedback. All contributions have been reviewed and, to the maximum extent possible, the recommendations and observations have been addressed in this final version. This report may undergo regular revisions.

Acknowledgements

ENISA would like to acknowledge the following individuals and organisations that contributed to the public consultation and agreed to be publicly named.

Name Affiliation

Adam Shostack OWASP Foundation Anthony Harrison APH10 Arne Padmos Biserka Radeva Ministry of Electronic Governance Bob Lord Software Safety Institute Brunn Hilmar Mettler-Toledo International Cédric LEVY-BENCHETON cetome Dave Russo Red Hat LLC Diana Rossi Dr. Thomas Termin WITTE Automotive / Institute for Security Systems Friedhelm Becker Ioana Nilwik J B Toby Avolites Ltd Joan Romero Chaparro craevidence.com Johan Sydseter OWASP Foundation Juan Rico Eclipse Foundation Jukka Ruohonen University of Southern Denmark Kenichi Ikegami JTEKT ELECTRONICS Corporation Lauren Zabierek Software Safety Institute Madalin Neag OpenSSF/The Linux Foundation Martin Schneider Fraunhofer FOKUS Martin Zimpel BSI Matthew Coles OWASP Foundation Max Alejandro Gómez Sánchez Vergaray OWASP Foundation Michael Schuster BSI Nikos Mavrogiannopoulos ASSA ABLOY Patrick Lamplmair Tributech Philippe BOINOT ANSSI Sanjay Kumar Sirurmath Sarah Fluchs admeritia Sebastien Deleersnyder OWASP Foundation Sebastien Deleersnyder OWASP Foundation Thierry Dupont Zoe Braiterman OWASP Foundation

Modern products with digital elements are increasingly expected to be secure by design and secure by default . However, many organisations – in particular small and medium-sized enterprises, in which development teams are small and security expertise can be limited – may face distinct challenges in applying these concepts consistently, requiring targeted solutions.

This report puts forward a set of principles and tangible guidance on the application of secure by design and default requirements throughout the life cycle of a product. In particular, the report focuses on explaining these principles in clear, repeatable actions that can be applied to existing engineering, product and release processes.

The secure by design principles are organised into two groups, namely architectural foundations

and operational integrity . The former addresses how the system is designed, implemented and built, while the latter focuses on how the system is distributed, installed, managed and maintained. Similarly,

the secure by default principles are grouped into the categories default hardening and guided

protection . The former ensures that products start in a secure and restrictive state, while the latter aims to support users in maintaining the secure baseline through clear defaults, warnings and recovery mechanisms.

A core part of this document is a set of practical Secure by Design and Default playbooks. Each playbook presents the principle’s objective, practical actions, and a set of evidence that could support the demonstration of its implementation. Annex C provides an indicative mapping of the principles presented in this report to the essential requirements set out in Annex I to the European Union’s Cyber Resilience Act.

The report also presents an illustrative example of a machine-processable attestation, demonstrating how voluntary, manufacturer-issued machine-processable artefacts are able to provide a high-fidelity record of a product’s security posture. Rather than proposing a new schema or prescribing a specific format, the example illustrates how machine-processable attestations can express security claims, supporting evidence and verification results in a structured format, enabling automated processing and validation.

This approach also allows for the automation of security checks and release decisions, which helps to ensure that secure by design and default properties are maintained over time. This capability is particularly valuable for small and medium-sized enterprises with limited security resources, because it reduces the need for manual audits while increasing confidence in the product’s security posture.

Introduction

Secure by design and secure by default require more than applying principles during development. They must be operationalised end to end across the entire product life cycle, from the initial concept to the product’s eventual decommissioning. This life-cycle view is especially important for connected products; where evolving threats, supply-chain dependencies and long-lived deployments can erode security despite otherwise sound design if governance and assurance do not persist over time.

ENISA’s report Guidelines for Securing the Internet of Things highlights a common failure node: ‘Security goals can often fail – even in the presence of good design – if there is a lack of tools that enable stakeholders to understand and assess security issues’ (8). In practice, secure by design and default depends on both good engineering decisions and the organisational mechanisms (methods, artefacts, metrics and review gates) that make risk visible, decisions repeatable and trade-offs explicit.

Secure by design and secure by default provide a framework for building systems that are resilient and security hardened from the start and that remain so once released into real-world environments. ENISA’s report Good Practices for Security of IoT (SDLC) (16) describes secure by design as a ‘holistic approach’ that must be applied throughout the entire life cycle of a product or service.

Security is not a static state but a continuous process involving specific development guidelines, threat modelling and the integration of security controls during the earliest stages of design to minimise the impact of cyberattacks.

• Secure by design embeds protective measures into products during development, rather than adding them retrospectively. This includes threat modelling, secure architecture patterns, validated cryptography and systematic vulnerability management integrated into development processes.
• Secure by default ensures that products ship with the most secure configuration reasonably possible. Users should not need technical expertise to achieve baseline security; protective measures must be active upon installation, with any reduction requiring deliberate user action.

These playbooks provide a practical, lightweight way for small and medium-sized manufacturers and product teams to implement secure by design and secure by default principles without creating a heavy governance burden. Each playbook distils a single security principle into a one-page, execution-focused guide that teams can apply repeatedly across releases and product lines.

The intention is to translate security principles from abstract aspirations into concrete engineering and operational actions, with clear expectations, verifiable outcomes and a consistent definition of done for security. Each playbook follows the same format to make adoption fast and repeatable.

• Principle. The security concept being implemented.
• Objective. What the principle is trying to achieve and what failure modes it reduces.
• Checklist. The highest-impact actions to implement (designed to be achievable in lean teams).
• Minimum evidence. The smallest set of artefacts/logs/configurations that demonstrate that the checklist has been implemented.
• Release gate. A copy and paste set of pass or fail criteria that can be used in a release review (or CI/CD). Teams should apply the criteria relevant to the release and confirm that the controls continue to operate as intended where the release could affect them.

This structure is deliberately aligned with how SMEs operate: short cycles, shared responsibilities, limited specialist capacity and a need for guidance with a high signal-to-noise ratio. Unless stated otherwise, the actions in the playbooks are directed at manufacturers and teams acting on their behalf. References to users and operators describe product capabilities, information or actions that manufacturers should enable or support.

Developers and manufacturers should consider the following guidance when using the playbooks.

• Treat each playbook’s release gate as a standard agenda item in release readiness
• Implement the minimum evidence as repository artefacts and CI outputs wherever possible.
• Use the product changes, threat model and risk assessment to determine which release-gate criteria require verification. Unchanged controls may be recorded as not affected.
• Reuse the same evidence across playbooks where appropriate. For example, a single SBOM, scan result or release record may satisfy related evidence requirements and release-gate criteria for more than one playbook.
• Allow exceptions only with a documented rationale, owner and review date.
• Refresh playbooks periodically based on incident learnings, vulnerability trends and product changes.

It is important to note that the items listed under ‘Minimum evidence’ do not necessarily require separate documents or artefacts. A single item of evidence may support several playbooks. Organisations should reuse existing engineering records wherever possible, including architecture diagrams, repository files, configuration records, issue-tracking tickets, test results, SBOMs, CI/CD outputs and release records.

The contents of this section should be treated as a baseline rather than a final state. As products evolve, risks change and new features are introduced, the content should be reviewed and updated to ensure that secure by design and secure by default remain effective over time.

The playbooks can be adopted progressively, prioritising those most relevant to the product’s risks, intended use and development context. Progressive adoption does not imply delaying any applicable requirements or controls, including those arising from legal obligations under the CRA. A suggested approach is provided at the end of this section.

Machine-processable attestation

in such a way that they ensure an appropriate level of cybersecurity based

on the risks.

Article 13(2) and where applicable, products with digital elements shall:

unless otherwise agreed between manufacturer and business user in

relation to a tailor-made product with digital elements, including the

possibility to reset the product to its original state;

including, where applicable, through automatic security updates that are

installed within an appropriate timeframe enabled as a default setting, with

a clear and easy-to-use opt-out mechanism, through the notification of

available updates to users, and the option to temporarily postpone them;

mechanisms, including but not limited to authentication, identity or access

management systems, and report on possible unauthorised access;

data, personal or other, such as by encrypting relevant data at rest or in

transit by state of the art mechanisms, and by using other technical

means;

personal or other, commands, programs and configuration against any

manipulation or modification not authorised by the user, and report on

corruptions;

limited to what is necessary in relation to the intended purpose of the

product with digital elements (data minimisation);

incident, including through resilience and mitigation measures against

denial-of-service attacks;

devices on the availability of services provided by other devices or

networks;

external interfaces;

using appropriate exploitation mitigation mechanisms and techniques;

internal activity, including the access to or modification of data, services or

functions, with an opt-out mechanism for the user;

permanent basis all data and settings and, where such data can be

transferred to other products or systems, ensure that this is done in a

secure manner.

identify and document vulnerabilities and components contained in

products with digital elements, including by drawing up a software bill of

materials in a commonly used and machine-readable format covering at

the very least the top-level dependencies of the products;

and remediate vulnerabilities without delay, including by providing security

updates; where technically feasible, new security updates shall be

provided separately from functionality updates;

with digital elements;

disclose information about fixed vulnerabilities, including a description of

the vulnerabilities, information allowing users to identify the product with

digital elements affected, the impacts of the vulnerabilities, their severity

and clear and accessible information helping users to remediate the

vulnerabilities; in duly justified cases, where manufacturers consider the

security risks of publication to outweigh the security benefits, they may

delay making public information regarding a fixed vulnerability until after

users have been given the possibility to apply the relevant patch;

vulnerabilities in their product with digital elements as well as in third-party

components contained in that product, including by providing a contact

address for the reporting of the vulnerabilities discovered in the product

with digital elements;

digital elements to ensure that vulnerabilities are fixed or mitigated in a

timely manner and, where applicable for security updates, in an automatic

manner;

security issues, they are disseminated without delay and, unless

otherwise agreed between a manufacturer and a business user in relation

to a tailor-made product with digital elements, free of charge,

accompanied by advisory messages providing users with the relevant

information, including on potential action to be taken.

requirement