ENISA Secure by Design and Default Playbook

TLP - CLEAR

ENISA Secure by Design and Default Playbook

A Practical Guide to Secure by Design and Default Principles for SMEs JULY 2026

ENISA Secure by Design and Default Playbook Version: 1.0

About ENISA

The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common level of cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the European Union Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and processes with cybersecurity certification schemes, cooperates with Member States and EU bodies, and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building and awareness raising, the Agency works together with its key stakeholders to strengthen trust in the connected economy, to boost resilience of the Union’s infrastructure, and, ultimately, to keep Europe’s society and citizens digitally secure. More information about ENISA and its work can be found here: www.enisa.europa.eu.

CONTACT

To contact the authors, use product_security@enisa.europa.eu. For media enquiries about this paper, use press@enisa.europa.eu.

LEGAL NOTICE

This publication represents the views and interpretations of ENISA, unless stated otherwise. It does not endorse a regulatory obligation of ENISA or of ENISA bodies pursuant to Regulation (EU) 2019/881.

ENISA has the right to alter, update or remove the publication or any of its contents. It is intended for information purposes only and must be accessible free of charge. All references to it or its use as a whole or in part must mention ENISA as its source.

Third-party sources are quoted as appropriate. ENISA is not responsible or liable for the content of the external sources, including external websites, referenced in this publication. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication. ENISA maintains its intellectual property rights in relation to this publication.

COPYRIGHT NOTICE

© European Union Agency for Cybersecurity (ENISA), 2026 Generative AI was used in a limited capacity to support language refinement and preliminary document screening. All outputs were reviewed and validated by subject-matter experts. No AIgenerated content was used without substantive human oversight.

This publication is licenced under CC-BY 4.0 “Unless otherwise noted, the reuse of this document is authorised under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence (https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed, provided that appropriate credit is given and any changes are indicated”.

PDF ISBN 978-92-9204-802-0 doi:10.2824/4422633 TP-01-26-016-EN-N

ENISA Secure by Design and Default Playbook Version: 1.0

Table of contents Executive summary 6 1. Introduction 8 1.1 Objectives 8 1.2 Scope and methodology 9 1.3 Target audience 10 1.4 Structure of the report 10 2. Secure by design and default across a product’s life cycle 12 2.1 Product life cycle 12 2.2 Risk management activities 15 2.3 Threat modelling 17 3. Secure by design and default principles 22 3.1 Secure by design principles 22 3.2 Secure by default principles 25 4. Playbooks 29 4.1 Trust boundaries and threat modelling 31 4.2 Least privilege 32 4.3 Strong identity and authentication architecture 33 4.4 Attack surface minimisation 34 4.5 Defence in depth 35 4.6 Open design 36 4.7 Life-cycle management 37 4.8 User-centric design 39 4.9 Secure coding and verification practices 40 4.10 Logging, monitoring and alerting 42 4.11 Configuration and change management 43

ENISA Secure by Design and Default Playbook Version: 1.0

4.12 Incident response and recovery 44 4.13 Vulnerability and patch management 45 4.14 Supply-chain controls 47 4.15 Minimisation of default services 49 4.16 Restrictive initial access 50 4.17 Secure communication by default 51 4.18 Unique device identity and secrets by default 52 4.19 Mandatory security onboarding 53 4.20 Automated maintenance and updates 54 4.21 Transparent security posture 55 4.22 Secure recovery and ownership life cycle 56 4.23 Progressive adoption of the playbooks 57 5. Machine-processable attestation 60 5.1 Demonstrability, verifiability and assurance 60 5.2 Incentives 61 5.3 Existing frameworks and initiatives 62 5.4 Illustrative example 63 6. Bibliography 70 Annex A: Abbreviations 72 Annex B: Cyber Resilience Act essential requirements 73 Annex C: Mapping security principles to Cyber Resilience Act essential requirements 75

ENISA Secure by Design and Default Playbook

Note on this version

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 opensource 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

ENISA Secure by Design and Default Playbook Version: 1.0

Executive summary

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.

SECTION 1

Introduction

ENISA Secure by Design and Default Playbook Version: 1.0

1. Introduction 1.1 Objectives

Secure by design represents a fundamental shift in product security, with protective measures embedded from conception rather than retrofitted post-development. For small and medium-sized enterprises (SMEs), including microenterprises, that manufacture products, the transition to a secure by design approach presents distinct challenges requiring tailored solutions ( ).

Secure by design is increasingly expected, including under the European Union’s Cyber Resilience Act (CRA) ( ). This report does not provide legal guidance but offers practical, technically grounded approaches that can support manufacturers in applying the relevant principles in practice. It is intended as a practical starting point, rather than an exhaustive or prescriptive implementation framework. Its application should be adapted to the product’s intended use, context and associated risks and to the applicable requirements. For reference, Annex C provides an indicative mapping of the secure by design and default principles described in this report to the essential requirements set out in Annex I to the CRA, which are themselves listed in Annex B.

The report aims to bridge the gap between aspirational security principles and practical implementation within SME constraints, providing guidance that development teams can immediately apply during design, build and deployment phases.

The report takes into account the persistent challenges that SMEs face in translating security principles into engineering practice, acknowledging limitations on time, budget, expertise and resources. It provides structured, easy-to-follow checklists enabling organisations to:

• Identify relevant security controls (quick wins). Determine a priority set of protective measures that align with specific product requirements. • Implement controls systematically (approachability). Apply security measures through technically feasible approaches. • Enable measurable improvement. Establish measurable baselines and use relevant evidence to assess whether security processes and controls operate as intended, to guide improvement.

1.1.1 Intended outcomes

Applying this playbook is intended to contribute to:

• fewer recurring and preventable vulnerabilities;

ENISA Secure by Design and Default Playbook Version: 1.0

• products delivered with safer default configuration and reduced unnecessary exposure; • earlier identification and treatment of security risks; • better visibility and stronger protection of dependencies, build processes, releases and updates; • faster detection, remediation and communication of vulnerabilities; • reduced likelihood and impact of cybersecurity incidents throughout the product life cycle.

These outcomes benefit users and operators through safer and more resilient products. Manufacturers benefit through more consistent security decisions, while customers and integrators benefit through clearer and more traceable security evidence.

1.2 Scope and methodology

This guidance was developed with SMEs, including microenterprises, in mind, particularly SME manufacturers developing products with digital elements, such as embedded software, internet of things (IoT) devices, connected systems, stand-alone software and any hardware incorporating programmable components. It addresses security requirements throughout the product life cycle, from product design to decommissioning.

An SME is defined as an organisation with fewer than 250 employees and an annual turnover below 3 4 EUR 50 million ( ). SME manufacturers typically face ( ):

• budget constraints – limited financial resources for security investments ( ); • limited expertise – no dedicated security personnel, reliance on general IT staff; • skills gaps – minimal specialist security knowledge within the organisation; • time pressures – security competing with core business priorities.

For the purpose of this report, ENISA performed an analysis of existing security frameworks, such as those previously published by ENISA and other EU-based cybersecurity agencies, and relevant guidance from the US National Institute of Standards and Technology (NIST) and the Open Worldwide Application Security Project (OWASP) ( ). We identified common requirements and implementation patterns, which were evaluated against SME capabilities to determine feasibility and adaptation requirements.

While this report can support a solid technical foundation for making products secure by design and default, it serves as introductory guidance rather than a comprehensive compliance manual. Adherence to the principles outlined in this report does not inherently ensure certification against specific international standards or compliance with regulatory mandates. Instead, it acts as a foundational bridge to help teams navigate the complexities of secure product development.

Cybersecurity threats, technologies and good practices continue to evolve. This playbook may therefore be updated or complemented over time by additional guidance and resources, such as the ENISA

ENISA Secure by Design and Default Playbook Version: 1.0

technical advisories ( ). For example, while embedded, field-level and industrial products fall within the scope of this report, the guidance may need to be adapted or supplemented to account for their specific technical and operational constraints.

1.3 Target audience

This guidance is structured as a technical companion for software and product developers, systems engineers and technical leads. It is intended for those tasked with the practical implementation of secure by design and default principles in their product development life cycle.

The primary groups that will benefit from this guidance include

• Software developers and engineers. Professionals seeking tactical methods to embed security into the codebase while operating within rapid delivery cycles. • Technical product managers. Individuals responsible for balancing functional requirements with the need for fundamental security resilience. • SME security leads. Personnel tasked with interpreting enterprise-grade frameworks for organisations with limited budgets, specialised niches or lean teams. • System architects. Designers aiming to build robust infrastructures that prioritise security from the initial conceptual phase.

1.4 Structure of the report

The structure of the report is outlined below.

• Section 2 covers the product security life cycle and practical ways in which risk management activities and threat modelling can be applied in the context of an SME. The section includes a series of simple-to-follow steps showing how each of the activities can lead to tangible deliverables. • Section 3 covers fundamental secure by design and secure by default principles. They are explained in an easy-to-understand manner. This section lays the foundation for the next sections. The report also includes a mapping of these principles to other ENISA security best practices and well-established resources, such as MITRE’s common weakness enumeration (CWE) and OWASP’s top 10 critical security risks for 2025. ▪ Section 4, the most extensive part of the report, details each of the 22 principles by covering, for each, the objective, key elements to consider when applying it in an engineering context, means of collecting evidence that the principle has been followed and a set of criteria that can be used in a release review. • Section 5 covers the concept of machine-processable attestation, offering an example of the implementation of a hierarchical data model that ensures that every high-level security claim is backed by granular technical evidence. • The annexes summarise the CRA essential cybersecurity requirements, providing a mapping of the secure by design and default principles described in this report to those requirements, to show how the principles can support the implementation of the CRA.

SECTION 2

Secure by design and default across a product’s life cycle

ENISA Secure by Design and Default Playbook Version: 1.0

2. Secure by design and default across a product’s life cycle

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’ ( ). 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.

2.1 Product life cycle

As highlighted in the ENISA report Baseline security recommendations for IoT in the context of critical information infrastructures ( ), security must be considered throughout the entire product life cycle. Regardless of the production model used (V-model or agile), the following life-cycle processes require explicit security consideration to support product security.

• Requirements. As part of this process, user, business, functional and security requirements are determined. These requirements reflect the intended use of the product and will be translated into specifications that will guide design, development and maintenance/deployment decisions at later stages. • Design. As part of the design process, the architecture and the design of the product are created. This process involves the creation of a set of documents that describe how the product requirements, including security requirements, will be translated into system specifications and essentially how the product will work. • Implementation. As part of the implementation process, specifications and software design artefacts are implemented in the product. • Verification: This process involves all necessary steps to verify that the developed product actually meets the identified requirements and design principles of the previous processes. • Deployment. This process follows the acceptance of the product subject to successful testing as part of the previous processes – that is, it takes place after it has been approved for release. It involves integrating all necessary elements of the solution into the production environment and its deployment.

ENISA Secure by Design and Default Playbook Version: 1.0

• Maintenance and disposal. Solutions deployed in production need to be constantly maintained to ensure the availability and integrity of the functionality provided. When the solution becomes obsolete, it is important to provide data erasure mechanisms that ensure secure disposal and preserve privacy management.

These processes are presented as groupings, not a mandatory sequential model. They may overlap, occur iteratively and be revisited throughout a product’s life cycle. For example, in agile environments, security requirements may be captured and progressively refined through backlog items, user stories, acceptance criteria and the definition of done.

Figure 1 shows the relationships between the product life cycle, secure by design and default principles and risk management activities.

Risk management activities establish the security context by clarifying important considerations, including what needs to be protected, the threats of concern and the acceptable level of residual risk given the product’s intended purpose and security impact. Secure by design and default principles translate this context into practical security decisions that are applied throughout the processes of the product life cycle, from requirements through to end of life.

Risk management activities should be revisited in response to changes or events arising during the product life cycle. Similarly, while the product life-cycle processes are presented sequentially, both the life cycle and the application of secure by design and default principles across the processes are inherently iterative. Events or findings in later processes, such as testing results, deployment in new environments, incidents, discovered vulnerabilities or the implementation of new features, often require re-entry into earlier life-cycle processes.

Frameworks such as the OWASP software assurance maturity model (SAMM) ( ) may be used to organise and mature security activities across the software life cycle. Its threat assessment and security requirements practices provide one example of how identified threats can inform testable

ENISA Secure by Design and Default Playbook Version: 1.0

security requirements. For SMEs, especially those operating with rapid iterations, the key is to keep life-cycle processes lightweight, risk driven and automation first:

▪ use small, reusable artefacts (one-page context, simple diagrams, checklists); ▪ prefer automated controls in continuous integration and continuous delivery (CI/CD) over manual reviews, reserving deep reviews for high-risk changes; ▪ introduce fast security gates aligned with existing agile ceremonies (definition of ready/done, pull request (PR) checks, release checklist).

Life-cycle Actions Deliverables process

Define the product context (users, environments, One-page security data), non-negotiable security defaults, and top risks context and Deciding on and threat scenarios; establish clear criteria for assumptions, short requirements addressing risks, based on the product’s intended security requirements purpose, expected use and security impact. checklist (including secure defaults) Maintain one architecture diagram with trust Architecture and trustboundaries; run a lightweight threat model to identify boundary diagram, top a manageable number of threat scenarios (e.g. the threats and Design top 5 to 10); decide on the critical design controls mitigations (bulleted a (authentication/authorisation ( ), update mechanism, list) secrets, logging). Build secure defaults into code/config; enforce CI evidence (pipeline dependency hygiene; protect secrets; require review logs), lightweight for security-sensitive changes; configure automated secure coding / Implementation static application security testing (SAST) / checklist (often a repo dependency scanning as part of CI environments file) (agile /DevOps/DevSecOps). Run automated security checks (SAST / dependency Release security scanning, basic dynamic application security testing checklist (pass/fail and (DAST) where relevant); ensure default configuration exceptions) and is validated; run targeted penetration testing when documented known potential risk triggers are hit (e.g. in the case of a issues / residual risk Verification substantial modification). Run automated tests with high coverage that include security-relevant negative tests (verifying that what shouldn’t happen doesn’t happen). Note that security verification should be integrated into developer workflows and CI pipelines as early as possible (following the ‘shift left’ principle). Ensure secure provisioning/enrolment, least-privilege Deployment hardening runtime config and monitoring of key health/security checklist, rollback Deployment indicators; treat updates as controlled change plan, minimal management. monitoring/alert list Define a patch intake process and service-level Vulnerability and agreements (SLAs), decide on vulnerability patch process guide Maintenance monitoring and incident handling processes and draw (one page), end-ofand disposal up an end-of-support/end-of-life plan; ensure secure life/disposal note, disposal (data erasure, credential revocation). maintained risk register updates a ( ) https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05- Authorization_Testing/README.

ENISA Secure by Design and Default Playbook Version: 1.0

2.2 Risk management activities

Risk management activities provide the foundation for implementing secure by design and default across the product life cycle. They ensure that security decisions are based on an informed and shared understanding of what needs to be protected, from whom and under what constraints.

In this report, ‘risk management’ concerns cybersecurity risks affecting the product and the users, operators, customers, data, services and systems that depend on it, taking into account the product’s intended purpose and reasonably foreseeable use. It does not refer to the manufacturer’s commercial or reputational risk.

These activities establish the context within which secure by design and default principles are applied. Their outputs directly informs:

▪ security requirements and architecture decisions; ▪ default configuration and ‘out of the box’ hardening; ▪ prioritisation of controls and assurance activities (e.g. testing depth, review gates); ▪ acceptable trade-offs inherent to the product’s intended use and deployment context; ▪ the ongoing operational security posture, including patching and end-of-life handling.

Risk management is typically initiated early, but it must be iterative: revisited at defined life-cycle gates (e.g. major release, supplier change, new deployment context) and triggered by significant events (e.g. newly disclosed vulnerabilities, threat shifts, incident learnings). Examples of risk management activities directly supporting secure by design and default decisions include:

• product context definition, including intended purpose, operating environment, users, data processed, and constraints • establishing risk acceptance criteria, expressed as simple and practical guidelines to support consistent decision-making; • high-level risk assessment focused on threat modelling, key assets, trust boundaries and risk treatment decisions.

Risk assessments should also be informed by evidence from deployed products, including customer and researcher reports, incident investigations, observed exploitation patterns and proportionate telemetry, where available and appropriate.

This report does not aim to define or replace a formal risk management framework. Rather, it aims to highlight common risk management activities and outputs that feed security decision-making.

To support SMEs, the following list is a sample set of activities that can drive secure by design and default decisions without creating heavy processes. The purpose of these activities is to translate product context and credible threats into testable security requirements, prioritise the relevant playbooks and determine the appropriate depth of controls and assurance activities, rather than applying every practice uniformly.

ENISA Secure by Design and Default Playbook Version: 1.0

Activity Actions Deliverables

Product context and scope Define intended use, deployment One- or two-page ‘product environments, user/admin roles, data security context’ note (scope, types/sensitivity and key external assumptions, dependencies) dependencies (cloud, mobile app, third parties). Asset and adverse effect List top data, hardware or function assets Asset list and top adverse identification (e.g. credentials, customer data, essential effects list (one page) functions) and key adverse effect outcomes (privacy breach, takeover, outage, fraud, safety impact). Lightweight threat See Section 2.3 See Section 2.3

modelling

Risk register Record 10 to 30 risks using a simple, Living risk register documented prioritisation method, with (spreadsheet or ticket board) owner, treatment and status; link priority risks to backlog items/controls. The prioritisation method could take into account aspects like impact, likelihood, plausibility, exploitability or exposure, as appropriate. Risk acceptance criteria Define a set of non-negotiable risk One-page risk acceptance and conditions (e.g. misuse of software updates, exceptions policy unauthorised administrative access and exploitation of default credentials are not acceptable) and establish criteria for accepting residual risk. For example, the accepted level of residual risk should not undermine the essential cybersecurity requirements, given the product’s intended purpose and reasonably foreseeable use. Security requirements Translate top risks into testable ‘must’ security requirements checklist baseline requirements (authn/authz, secure defaults, (testable controls) secrets, encryption, logging, updates). Release risk review gate As part of the secure development life cycle, Release security review record include a formal pre-release gate to verify (ticket/comment) and compliance with the requirements defined documented exceptions during the above activities. This review should confirm checklist met, defaults verified, known vulnerabilities triaged, high risks treated / accepted with rationale; decide go/no-go. Change-triggered Rerun context/threat/risk steps when major Updated context note, threat reassessment changes occur (architecture, auth model, shortlist and risk register data, critical dependencies/suppliers, entries (with date) deployment environment), including changes that could be considered substantial modifications, or after incidents.

ENISA Secure by Design and Default Playbook Version: 1.0

Risk assessments can also support product-specific implementation of applicable cybersecurity requirements, assessment and treatment of identified vulnerabilities and evaluation of the security impact of significant changes to a product.

2.3 Threat modelling

Threat modelling is a structured activity that supports security decision-making and may inform risk assessment by helping teams identify credible threats and attack paths. Combined with the product context and an appropriate prioritisation method, the outputs can help in selecting appropriate security requirements and controls, including secure by default settings.

One commonly used approach to identifying and categorising security threats is STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege) ( ). STRIDE is presented in this report as an illustrative example, but other suitable threat-modelling approaches may also be used( ).

Threat modelling should align with widely accepted threat-modelling principles ( ), recognising that it is a collaborative and iterative activity focused on understanding and reducing real security risks, rather than simply producing documentation artefacts. Common anti-patterns to avoid include treating threat modelling as a one-off compliance exercise, over-engineering models that do not influence design or secure by default decisions and failing to review the model following substantial product modifications or changes in the threat landscape. For products incorporating artificial intelligence (AI) / machine learning (ML) components, threat identification should also consider relevant AI-specific attack patterns, such as prompt injection, model poisoning and adversarial inputs ( ).

For SMEs, particularly those developing products intended for non-critical or lower-risk environments, the objective is not exhaustive analysis; it is a minimum viable model that is fast to produce, easy to refresh and tightly coupled to delivery (architecture decisions, default configuration and release gates).

A lightweight threat-modelling exercise can be organised around four questions (Shostack’s fourquestion 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?

Table 3 provides an illustrative example of how these questions can be translated into practical activities and deliverables for SMEs.

ENISA Secure by Design and Default Playbook Version: 1.0

ACTIVITY ACTIONS DELIVERABLE

Define scope, Time-box a short scoping stage to One-page (or equivalent assumptions and make the exercise decision ticket/wiki) ‘Threat model security objectives focused. Capture what is in and out scope and objectives’ note, of scope (e.g. devices, apps, cloud covering: services, admin tools), the ▪ purpose (what decisions deployment context(s) and the this will drive); assumptions and constraints you ▪ scope boundaries are working under (e.g. ‘device may (components and be physically accessible’, ‘customer environments); ▪ assumptions/constraints; network is untrusted’, ‘cloud APIs ▪ security objectives and are internet-exposed’, ‘advanced ‘crown jewels’ (what must user capabilities’). Then state the not fail). security objectives that matter for this product (e.g. confidentiality, integrity, availability, plus privacy/safety if applicable).

Model the system at a Produce a simple representation of System representation, useful level of the system that answers Shostack’s covering: abstraction core question, ‘What are we ▪ main components (devices, working on?’ This may be an apps, cloud services, architecture diagram, a data-flow APIs); diagram or another suitable ▪ external entities (users, representation. It should show the admins, third-party services); main components, data stores, ▪ data stores (device external entities, key data flows, storage, cloud database, entry points and trust boundaries in logs); sufficient detail to assess exposure. ▪ entry points (APIs, admin Complementary techniques, such UI, update channel, local as misuse cases or attack trees, ports); may also be used where helpful. ▪ trust boundaries (where Consider reusing the architecture trust assumptions, privileges or security and trust-boundary diagram properties change). developed during the design phase described in Table 1.

Mark trust boundaries Annotate the diagram with (a) trust Diagram showing: a and privilege paths; boundaries ( ) (boundaries between ▪ trust boundaries (internet– identify key assets environments with different security back end, device–cloud, properties) and (b) the highest- user–admin, tenant– privilege operations (e.g. firmware / tenant); OTA updates, remote admin, key ▪ privileged paths (updates, provisioning, identity issuance). auth, key management, admin actions); This is the step that turns ▪ top assets architecture into security-relevant (credentials/keys, sensitive architecture.

ENISA Secure by Design and Default Playbook Version: 1.0

data, device control functions, availability). Identify and prioritise the Generate a short list/representation Top threats table, showing: top threats of the answers to the question • a manageable number of ‘What can go wrong?’, mapped to threat scenarios (e.g. the entry/exit points, data flows and top 5 to 10) tied to specific trust boundaries (e.g. ‘credential entry/exit points and trust stuffing → account takeover → boundaries; remote control’, ‘malicious update’, • priority or severity rating ‘API authorisation bypass’, ‘man-in- with a short rationale. the-middle attacks during Prioritised threat scenarios onboarding’). Prioritise them using that drive design and default a lightweight, documented method choices appropriate to the product. This might take into account impact, likelihood, plausibility, exploitability and exposure or use predefined b severity criteria. OWASP ( ) describes this as threat identification and ranking as a core step in most threat-modelling approaches.

Define mitigations and Next, focus on ‘What are we going Controls, defaults and secure defaults, verify to do about it?’ For each top verification checklist, including: their effectiveness and threat, specify the mitigation ▪ Control/default decision set refresh triggers strategy, the required control(s) and for each top threat; the secure by default settings that ▪ test/verification mapping the product should ship with (e.g. (automation first); ‘admin interface disabled by ▪ explicit refresh triggers default’, ‘no default passwords’, (so that the model stays current). ‘signed updates enforced’, ‘leastprivilege roles’, ‘authentication attempts rate-limited’). Then map each control to how it will be verified (e.g. CI checks, tests, configuration validation, release gates), which will help to answer the question ‘Did we do a good enough job?’ Finally, define the triggers that require rerunning the model (e.g. a new internet-exposed interface, a new auth model, new sensitive data, a new critical dependency, a major architecture change). a ( ) https://owasp.org/www-community/Threat_Modeling_Process;. b ( ) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html.

ENISA Secure by Design and Default Playbook Version: 1.0

A practical starting point could be to identify a small number of the highest-impact adverse-effect scenarios for users, operators or other affected parties and a manageable number of credible threat scenarios (e.g. the top 5 to 10) that could lead to them. These scenarios should be prioritised based on impact and likelihood. As part of their release review, teams should determine whether product changes affect the scenarios, assumptions or controls. Where products are intended for higher-risk or critical use cases, depending on the product’s intended use and associated risks, a more comprehensive analysis will be required.

Lightweight threat modelling does not necessarily require special threat-modelling expertise. Product expertise, on the other hand, is essential, because an accurate understanding of the product, its intended use and its deployment context is the foundation of a useful threat model. However, specialist security expertise is likely to be needed for higher-risk products or more complex threats.

Threat-modelling outputs can vary depending on aspects like the product’s scope, the assumptions, the methodology selected and analyst judgement. These inputs should be documented and applied consistently, to increase repeatability and support review.

Threat modelling and risk assessment should be revisited throughout the product lifecycle. For example, reviews could be performed at initial product design, implementation of the technical architecture, and verification, validation, maintenance and operation, where discovered vulnerabilities and field evidence can inform subsequent assessments.

SECTION 3

Secure by design and default principles

ENISA Secure by Design and Default Playbook Version: 1.0

3. Secure by design and default principles

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) ( ) 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.

3.1 Secure by design principles

Secure by design focuses on incorporating security principles from the earliest stages of development. It requires organisations to embed security into the structure, logic and behaviour of a system rather than treating it as an afterthought. For the purposes of this playbook, secure by design is treated as a life-cycle approach. The principles are grouped into architectural foundations (how a system is built) and operational integrity (how it is managed and maintained) (Figure 2). These categories are practical organising lenses rather than mutually exclusive classifications, and some aspects of the principles contribute to both categories ( ).

ENISA Secure by Design and Default Playbook Version: 1.0

3.1.1 Architectural foundations

Architectural foundations are the blueprints for a system’s security; they focus on the structural design choices that make a product inherently difficult to compromise or exploit. This category establishes the fundamental rules for how data flows, how components interact, and how the system contains a potential breach before it can spread.

The following principles fall under this category.

▪ Trust boundaries and threat modelling. These concepts reflect two related security principles: trust should be made explicit rather than assumed, and threats should be identified before and throughout development. Trust boundaries define where data, identities and execution contexts cross from a more trusted domain to a less trusted one (or vice versa), such as between a device and a cloud service, a user and an admin interface or one microservice and another. Boundaries clearly identify which components must authenticate each other, where input must be treated as untrusted and where additional controls (e.g. validation, rate limiting, encryption or isolation) are required. Threat modelling also provides a structured way to identify what could go wrong at these boundaries by mapping key assets (e.g. credentials, firmware images, customer data), likely threat actors and realistic attacker capabilities and assumptions. ▪ Least privilege. Systems and users should be granted only the feasible minimum level of access required to perform their functions. Restricting permissions reduces the impact and limits the scope of compromise. Least privilege should be applied consistently across user accounts, service accounts, APIs and administrative roles, and privileges should be elevated only when needed and for the shortest feasible duration. ▪ Strong identity and authentication architecture. A secure product architecture requires a clear and consistent approach for how identities are created, verified, and managed for users, devices, services, and administrators. This includes defining authoritative identity sources, establishing how authentication occurs across interfaces (e.g. web portals, APIs, local

ENISA Secure by Design and Default Playbook Version: 1.0

management consoles and device-to-cloud communication) and ensuring that authentication is resistant to common attacks such as credential stuffing, replay attacks and session hijacking. ▪ Attack surface minimisation. Unnecessary features, services and interfaces increase the number of potential attack vectors. Therefore, reducing system complexity and disabling unused or unnecessary components reduces the likelihood of vulnerabilities being introduced or exploited. This includes removing default accounts, uninstalling unused packages, closing nonessential ports, removing unused code and limiting exposed management interfaces to trusted networks only. Standardised secure baselines and hardened configuration templates make it easier to keep systems consistently minimal as they scale. Ongoing vulnerability scanning and asset inventory are also important, because you cannot minimise what you do not know exists. ▪ Defence in depth. Applying layered security controls ensures that the failure of a single mechanism does not result in complete compromise. Layers can include preventive controls (e.g. multi-factor authentication (MFA), network segmentation), detective controls (e.g. monitoring, logging, anomaly detection) and corrective controls (e.g. automated isolation, backup/restore). Effective defence in depth also assumes that some controls will be bypassed, so systems should be designed to degrade gracefully and still protect critical assets. This approach reduces reliance on any single silver bullet and increases the attacker’s cost and time to achieve their objectives. It is strongest when controls are diverse (not all dependent on the same technology or trust assumption). ▪ Open design (avoiding obscurity). Systems should not depend on secrecy of design or hidden behaviour for protection. Security controls should remain effective even if an adversary understands how the system operates. This principle encourages the use of well-studied algorithms and protocols, clear documentation and designs that can withstand scrutiny through review and testing. Open design does not mean making secrets public; rather, it means that the security of the product should rest on protected keys, strong authentication and robust implementation, not on keeping the mechanism itself hidden. In practice, it also supports maintainability, because transparent designs are easier to audit, validate and improve over time.

3.1.2 Operational integrity

Operational integrity addresses the human and procedural practices that maintain product security throughout development, deployment, operation and retirement. It ensures that security is treated as a continuous, lived experience, for developers and users alike, rather than a one-time checklist completed during the design phase.

This category includes the following principles.

▪ Life-cycle management. Security responsibilities extend beyond initial development. Components must be maintained, updated and eventually retired in a controlled manner, taking the expected duration of use into account. The practical application of life-cycle management, including how secure by design and secure by default principles are applied from design and development through to decommissioning, is explored in Section 2. ▪ User-centric design. Security mechanisms must be usable and understandable even for everyday users. Poor usability often leads to insecure workarounds or misconfigurations. For example, if a system requires the user to perform complex manual configuration to enable encryption, they may skip the step or apply it incorrectly. On the other hand, providing a simple, guided set-up that enables encryption automatically reduces the chance of misconfiguration and encourages the use of the security feature. ▪ Secure coding and verification practices. Developers should follow established secure coding standards to prevent common vulnerabilities. Early identification and mitigation of

ENISA Secure by Design and Default Playbook Version: 1.0

insecure code ensure that weaknesses are not built into the system. For example, developers can use SAST tools ( ) while coding to identify vulnerabilities and software composition analysis to detect vulnerable third-party libraries. They can then apply dynamic testing tools ( ) (DAST) before deployment to uncover runtime issues. These practices ensure that code-related vulnerabilities are identified early and not after the product is released. ▪ Logging, monitoring and alerting. Security depends on visibility. Systems should generate appropriate security-relevant logs, retain them for a defined period and protect them from tampering, so that they can support investigation and compliance needs. Rather than simply collecting data, monitoring should be designed to detect suspicious behaviours such as repeated failed authentication attempts, privilege escalation, unexpected configuration changes and unusual outbound connections. ▪ Configuration and change management. Secure operation requires configurations to be controlled, consistent and auditable. Baseline hardening standards should be defined (e.g. secure defaults, disabled unused services and enforced encryption settings) and applied through repeatable mechanisms such as templates and infrastructure as code to reduce drift. Changes to systems should follow a governed process that includes review, testing, approval and rollback plans, particularly for security-sensitive components. ▪ Incident response and recovery. Developers must be prepared to respond quickly and effectively to security incidents that affect their products in the field, including vulnerabilities, compromised code, malicious updates and misuse of product functionality. This requires defined internal roles, escalation paths and decision-making authority for security events, as well as documented playbooks for containment and customer communication. ▪ Vulnerability and patch management. Vulnerability and patch management should be practical, repeatable and prioritised by risk. Manufacturers need a simple way for customers and researchers to report issues (e.g. a dedicated security email address and a basic disclosure process) and an internal process to triage findings quickly and decide what needs urgent action. ▪ Supply-chain controls. Developers and manufacturers should protect product integrity without excessive process overhead, focusing on the points where a compromise would have the largest impact: code repositories, build systems, signing keys and the channels used to distribute updates. At a minimum, source code and CI/CD modification rights should be limited to named individuals, protected with MFA and reviewed through lightweight peer approval for changes to security-critical areas. Software bills of materials (SBOMs) should be generated and maintained to support dependency transparency, vulnerability management and product lifecycle security.

3.2 Secure by default principles

Secure by default complements secure by design by focusing on the product’s security configuration presented to the user. Even well-designed systems can become vulnerable if they are released with insecure or overly permissive default settings.

The goal of secure by default is to minimise the attack surface after deployment by ensuring that the most secure configuration is applied automatically ( ). This includes disabling unnecessary services, applying restrictive access controls and providing clear information to users about the default security

ENISA Secure by Design and Default Playbook Version: 1.0

posture. Secure defaults reduce reliance on user expertise and limit the potential for misconfigurations, which are a common source of security incidents.

To summarise, secure by design focuses on how the system is engineered, while secure by default focuses on how the system arrives and behaves when the user first turns it on. We can organise secure by default into two distinct categories: default hardening and guided protection (Figure 3). These categories are practical organising lenses. Some principles contribute both to the product’s initial secure state and to maintaining that state during use.

3.2.1 Default hardening

Default hardening focuses on the factory-shipped state of the software, ensuring that the initial configuration is as restrictive as possible. It aims to eliminate low-hanging fruit for attackers by removing unnecessary features and ensuring that all active components are operating at their highest security level without requiring any user input.

▪ Minimisation of default services. Any feature or service that is not essential for the core functionality of the product should be disabled by default. If a web server includes an optional file-sharing module that most users will not need, that module should be off until the user explicitly opts in, thereby reducing the immediate attack surface. ▪ Restrictive initial access. Systems should ship with the most restrictive permissions possible. This includes the elimination of universal ‘admin/admin’ credentials and the enforcement of unique passwords and mandatory password changes upon first boot. ▪ Secure communication by default. All external communications should be encrypted and authenticated from the first connection. Rather than allowing an unencrypted HTTP or Telnet connection for convenience, the system should strictly enforce protocols like TLS 1.3 or SSH, ensuring that data is protected the moment it leaves the device. ▪ Unique device identity and secrets by default. The product should ship with unique, perdevice credentials and cryptographic identity (keys/certificates) rather than shared defaults. Any secrets used for authentication, update verification or encrypted communications must be generated uniquely and protected against extraction. This reduces the risk that compromise of a single device or a leaked credential could be used to attack other customers or the wider installed base.

3.2.2 Guided protection

Guided protection addresses the interaction between the user and the system’s security features. It acknowledges that human error is a primary cause of breaches and uses automated prompts,

ENISA Secure by Design and Default Playbook Version: 1.0

mandatory set-up steps and clear feedback to ensure that the user cannot easily or accidentally leave the system in an insecure state.

▪ Mandatory security onboarding. Critical security features should not be hidden in a settings menu; they should be part of the initial set-up wizard. For instance, requiring a user to configure MFA or an encryption key during the first-run experience ensures that the system enters a secure state before it is exposed to the internet. ▪ Automated maintenance and updates. A secure default posture must be sustainable. By enabling automatic security updates by default, the manufacturer ensures that the product remains protected against newly discovered vulnerabilities without requiring the SME to have a dedicated IT team to manually manage patching cycles. ▪ Transparent security posture. The system should clearly communicate its security status to the user. If a user chooses to disable a security feature or if a specific configuration increases risk, the system must provide a clear, understandable warning and offer a one-click path to return to the secure baseline. ▪ Secure recovery and ownership life cycle. The product should provide guided, low-friction recovery and transfer processes (credential reset, account recovery, secure factory reset and ownership transfer) that are simple for users to follow but resistant to account takeover and social engineering.

SECTION 4

Playbooks

ENISA Secure by Design and Default Playbook Version: 1.0

4. Playbooks

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.

ENISA Secure by Design and Default Playbook Version: 1.0

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.

ENISA Secure by Design and Default Playbook

4.1 Trust boundaries and threat modelling

ENISA Secure by Design and Default Playbook

4.2 Least privilege

ENISA Secure by Design and Default Playbook

4.3 Strong identity and authentication architecture

ENISA Secure by Design and Default Playbook

4.4 Attack surface minimisation

ENISA Secure by Design and Default Playbook

4.5 Defence in depth

ENISA Secure by Design and Default Playbook

4.6 Open design

ENISA Secure by Design and Default Playbook

4.7 Life-cycle management

ENISA Secure by Design and Default Playbook

ENISA Secure by Design and Default Playbook

4.8 User-centric design

ENISA Secure by Design and Default Playbook

4.9 Secure coding and verification practices

ENISA Secure by Design and Default Playbook

ENISA Secure by Design and Default Playbook

4.10 Logging, monitoring and alerting

ENISA Secure by Design and Default Playbook

4.11 Configuration and change management

ENISA Secure by Design and Default Playbook

4.12 Incident response and recovery

ENISA Secure by Design and Default Playbook

4.13 Vulnerability and patch management

ENISA Secure by Design and Default Playbook

ENISA Secure by Design and Default Playbook

4.14 Supply-chain controls

ENISA Secure by Design and Default Playbook

ENISA Secure by Design and Default Playbook

4.15 Minimisation of default services

ENISA Secure by Design and Default Playbook

4.16 Restrictive initial access

ENISA Secure by Design and Default Playbook

4.17 Secure communication by default

ENISA Secure by Design and Default Playbook

4.18 Unique device identity and secrets by default

ENISA Secure by Design and Default Playbook

4.19 Mandatory security onboarding

ENISA Secure by Design and Default Playbook

4.20 Automated maintenance and updates

ENISA Secure by Design and Default Playbook

4.21 Transparent security posture

ENISA Secure by Design and Default Playbook

4.22 Secure recovery and ownership life cycle

ENISA Secure by Design and Default Playbook Version: 1.0

4.23 Progressive adoption of the playbooks

This section provides an illustrative progressive adoption sequence, showing how the playbooks can be adopted and applied over time. The example begins with activities that provide context and prioritisation, followed by a foundational engineering baseline and then a broader and more mature implementation of the principles. Progressive adoption here refers to how organisations build and strengthen their security practices over time. It does not suggest delaying applicable requirements or controls, particularly those arising from legal obligations, including under the CRA. This guidance is without prejudice to such obligations, which take precedence.

4.23.1 Establish context and priorities

The product context, risk management and threat-modelling activities described in Section 2 can be used, together with Playbook 4.1, to identify the most relevant threats, trust boundaries and security objectives. This step can guide prioritisation and scoping as regards the implementation of the playbooks.

4.23.2 Establish a foundational engineering baseline

Based on the product context, security objectives, and identified risks threats, organisations should establish an appropriate engineering baseline. For most products, an initial baseline should include:

• secure coding and verification practices (Playbook 4.9); • logging, monitoring and alerting (Playbook 4.10); • vulnerability and patch management (Playbook 4.13); • supply-chain controls (Playbook 4.14).

This baseline should be supplemented by the secure by default playbooks relevant to the product. For example:

• restrictive initial access (Playbook 4.16), where the product provides user, administrative or maintenance access; • secure communication by default (Playbook 4.17), where the product communicates over a network or exchanges data with external components; • unique device identity and secrets by default (Playbook 4.18), where devices, product instances or services require identities or credentials; • automated maintenance and updates (Playbook 4.20), where the product can be updated after deployment.

Other playbooks should be prioritised at this stage where they are necessary to address the identified risks, threats and security objectives or product context. For example, availability-sensitive products may require early implementation of the incident response and recovery playbook (Playbook 4.12), while products supporting reset, ownership transfer or decommissioning may require the implementation of the secure recovery and ownership life-cycle playbook (Playbook 4.22).

Progressive adoption could also determine the extent to which an individual playbook is implemented. An organisation could begin with the checklist items that address its priority risks and applicable requirements, and then strengthen coverage, evidence and automation over time.

ENISA Secure by Design and Default Playbook Version: 1.0

4.23.3 Broaden and strengthen implementation

The remaining applicable playbooks can be implemented and prioritised according to the product context, intended use, deployment context and identified risks and threats. Over time, teams should increase the coverage, consistency and automation. Moreover, progress should be assessed using relevant measures.

This illustrative sequencing is intended to help organisations manage implementation effort. It does not mean that playbooks addressed in a later phase are inherently less important or that applicable security or regulatory requirements may be deferred.

SECTION 5

Machine-processable attestation

ENISA Secure by Design and Default Playbook Version: 1.0

5. Machine-processable attestation 5.1 Demonstrability, verifiability and assurance

In modern software engineering, the transition from manual, document-heavy compliance to machineprocessable attestations marks a critical evolution in how trust can be verified. At its core, a machineprocessable attestation is a digital claim, encoded in formats like JSON or YAML, asserting that a specific security control, process or property has been met. Unlike static PDF reports that sit in a folder, these digital artefacts are ‘generatable’ and ‘consumable’ by automated systems, enabling frequent or event-driven updates and automated validation of security claims across the product supply chain.

Machine-processable means that automated systems should be able to validate, interpret and act on it without human interpretation. This requires elements such as defined field types and semantics, controlled values, structured representation of decision-relevant information and schema versioning. Structured fields should be preferred for information used in automated processing, with free text used where additional explanation is helpful.

By embedding these attestations directly into the development pipeline, security becomes an intrinsic part of the product’s DNA, rather than a post-development checkbox.

• During a product’s design and development, machine-processable formats allow architects to define security requirements as code, which can then be automatically mapped to implementation evidence. • For verification, these attestations enable automated gatekeeping; for instance, a deployment system can be configured to block any container that lacks a valid, machine-signed attestation of a successful vulnerability scan by default.

Furthermore, machine-processable attestations solve the ‘transparency gap’ inherent in complex ecosystems. They provide a verifiable, tamper-evident trail of a product’s security posture from the source code to the final runtime environment. This level of transparency ensures that every stakeholder, from the developer to the end customer, has access to an objective, current view of the risk profile, effectively automating the trust relationship between producers and consumers.

Technical documentation can also benefit from machine-processable attestations. Instead of being created as a static snapshot at a particular point in time, the artefacts can help ensure that documentation stays accurate and current by displaying the security requirements, implementation evidence, and verification results.

This is a significant advantage, particularly in view of the CRA’s requirement that manufacturers maintain technical documentation. Such documentation can be kept up to date and supported by verifiable implementation and test evidence.

A manufacturer-issued attestation by itself is not proof that a product is secure. Attestation, verification and independent assessment are distinct activities. An attestation provides claims and links it to supporting evidence; verification checks the integrity, scope, currency and consistency of those claims and that evidence; and independent assessment can evaluate whether the controls and evidence are sufficient for the product and its risks.

ENISA Secure by Design and Default Playbook Version: 1.0

For SME engineering teams, machine-processable attestation can support automation by employing these concepts:

• Demonstrability: The proactive capacity of a system and its development process to provide objective, machine-processable evidence that specific security requirements have been implemented. It represents the shift from “claiming” security in a static document to “showing” security through generated artefacts, such as signed build logs, automated test results, and standardised metadata. • Verifiability: The ability for an independent party, whether an automated tool, a customer, or a regulator, to programmatically authenticate and validate the integrity of security claims. A verifiable system ensures that attestations are transparent, tamper-evident, and mapped to a recognised root of trust, allowing for the continuous, low-friction audit of a product’s security posture. • Reusability: The ability to use existing attestations for further build on existing developments directly integrating cybersecurity in the development cycle and enabling an continuous cybersecurity improvement with minimal effort. • Reliability: The ability to rely on existing attestations also for third party components, simplifying due diligence based on a structured attestation demonstrating security properties of a component with additional option for third party verification

5.2 Incentives

When security requirements are demonstrable, engineering teams move away from security as an afterthought and instead treat security as a primary functional requirement, because it means that every design decision, from the choice of a library to the architecture of a database, should be accompanied by the creation of a machine-processable artefact. This active generation of evidence allows teams to catch architectural flaws during the design phase, long before code is committed or products are shipped.

Furthermore, while secure by default focuses on delivering products that are secure out of the box, verifiability provides the mechanism to ensure those defaults remain intact and effective. In a verifiable ecosystem, the default state is not just a configuration choice but a protected claim that can be automatically checked at every stage of the life cycle.

Using reusable attestation enables the manufacturer to directly include cybersecurity into the development process and enabling the integration of cybersecurity controls in small use case specific packages leveraging existing agile methods and can also be included in quality gates in agile project management and tooling, e.g. cybersecurity as part of Definition of Ready and Done in Scrum

Relying on machine-processable attestation enables manufacturer to reduce effort for due diligence and supply chain management. A structured attestation enables integrators to simply pinpoint necessary security properties for due diligence and enhances trust with evidences and additional verification.

This creates a fail-safe environment in which a system can refuse to operate if its attestations, such as signed proof that MFA is enforced or that the latest vulnerability scan was passed, are missing or invalid.

For SMEs, this automation eliminates the need for constant manual checks. It ensures that the product’s security baseline is both self-verifying and consistently visible to stakeholders.

ENISA Secure by Design and Default Playbook Version: 1.0

Machine-processable attestations can also support procurement and supplier assessment. Customers, integrators and procurers can use such structured claims and evidence to compare products, verify security-relevant properties and identify areas that may require further assessment.

5.3 Existing frameworks and initiatives

The ecosystem of machine-processable security has been rapidly evolving. Some of the key initiatives include foundational frameworks like NIST’s Open Security Controls Assessment Language (OSCAL) (compliance as code), OWASP’s CycloneDX Attestations (CDXA) (native security attestation) and SPDX 3.0 Security Profile, which provide the structural grammar for automating compliance and supply-chain transparency. Presented below are some of these initiatives in this area.

• OSCAL ( ). Developed by NIST, OSCAL is the premier model for compliance as code. It provides a standardised way to express security control catalogues, system security plans and assessment results. By using OSCAL, organisations can automate the generation of compliance documentation, allowing for continuous authorisation, whereby the status of security controls is updated in real-time as evidence is collected. • CycloneDX (OWASP ECMA-424) ( ). While originally an SBOM format, CycloneDX has expanded into a full-stack transparency standard. Its attestation capabilities (CDXA) allow organisations to document claims about security requirements alongside generating a bill of materials. It also includes specialised modules like VEX to communicate whether a vulnerability actually affects a product, and it can produce a cryptographic bill of materials (CBOM) to inventory cryptographic assets for quantum readiness. CycloneDX Assessors Studio ( ) provides an emerging open-source implementation for conducting structured assessments, collecting evidence, documenting claims and generating CycloneDX attestations. • SDPX 3.0 Security Profile ( ). The security profile captures security-related information in a SPDX Security Document. Specifically, the properties and relationships specified in the security profile are in support of exchanging information about system vulnerabilities that may exist, the severity of those vulnerabilities, and a mechanism to express how a vulnerability may affect a specific element including if a fix is available. • The Open Source Security Foundation (OpenSSF). OpenSSF leads several projects, including Security Insights ( ), a specification that project teams can use to report security facts (like bug bounty information or security contacts) in a machine-processable YAML format. They also champion the OpenSSF Scorecard ( ), which automatically assesses open-source projects against security best practices. OpenSSF Best Practices badge ( ) provides machine-readable security criteria status for many OSS projects, including against the 28 29 OpenSSF Baseline ( ). Supply-chain Levels for Software Artifacts, or SLSA ( ) (“salsa”) provides recommended machine-readable schemas for SLSA attestations. • OWASP (Open Web Application Security Project). Beyond CycloneDX, OWASP projects like the ASVS ( ) (Application Security Verification Standard) provide the underlying requirements that these machine-readable formats aim to verify. Newer initiatives like the MLSVS (Machine Learning Security Verification Standard) are extending these principles into the AI/ML domain.

ENISA Secure by Design and Default Playbook Version: 1.0

• TC54 (Ecma International) ( ): This technical committee is the formal standardisation body for CycloneDX. It focuses on the Transparency Exchange API, which aims to standardise how software transparency information (like SBOMs and attestations) is discovered and shared across the global supply chain. • in-toto ( ). in-toto provides an open framework for expressing verifiable claims about software supply-chain activities. SLSA Provenance uses in-toto to describe where, when and how software artefacts were built and tools such as Sigstore Cosign ( ) can sign and verify in-toto attestations. • Device Security Passport ( ). The Device Security Passport (DSP) is intended to provide a structured, machine-readable record that consolidates relevant security information about an IoT component and makes it accessible to stakeholders across the supply chain.

5.4 Illustrative example

This section describes an illustrative example of how security claims, supporting evidence and assessment results can be expressed in a structured, machine-processable format to describe aspects of a product’s security posture.

The example does not propose a new schema or prescribe a specific format; rather, it is intended to show the relationship between a security objective, its implementation and the evidence used to assess it. Existing standards and specifications may be used, separately or together, to represent this information.

The example follows a simple cascade pattern, in which each high-level security objective is linked to its implementation actions and the results used to verify it.

• Control layer (security objectives to be addressed) o Defines structured security objectives (e.g. ‘protection against unauthorised access’ or ‘secure update delivery’), which may be derived from secure by design and default principles and/or aligned with regulatory or recognised cybersecurity frameworks. • Implementation layer (how controls are implemented) o Provides claims describing the technical controls implemented to satisfy each objective, together with references to supporting evidence (e.g. ‘Implementation of TLS 1.3 with AES-256 encryption’). o Details the specific tools (e.g. OpenSSL version, specific compiler flags), versions, configurations (e.g. ‘Strict-Transport-Security’ headers) and parameters used to instantiate the control. • Assessment and verification layer (how claims and evidence are validated) o Links to verifiable outputs of automated validation processes, such as timestamped test results, static analysis (SAST) summaries and cryptographic hashes of build artefacts.

These layers do not need to be contained in a single document. Claims, SBOMs, vulnerability information, build provenance, test results and other evidence may be maintained as separate but linked machine-processable artefacts.

ENISA Secure by Design and Default Playbook Version: 1.0

Given that this information may contain sensitive technical details, such as specific compiler flags, internal test logs or cryptographic configurations, it may be impractical or insecure to grant every stakeholder full visibility. Sensitive evidence does not need to be included in a single publicly accessible record. Manufacturers may separate the information into:

• a public attestation layer – cryptographically signed security claims, provenance information and other non-sensitive information that can be independently verified; • a restricted technical overlay – detailed test results, tool configurations, build parameters and other sensitive evidence, made available to authorised recipients through an authenticated and access-controlled API endpoint, such as the Transparency Exchange API.

5.4.1 Organisation of the example

For the purposes of the example, the information is organised as shown below. This organisation is illustrative and does not define a schema, field names or a required implementation format.

5.4.2 SafeGate-X1 example

Scenario. Imagine you are the manufacturer of SafeGate-X1, a specialised hardware controller used to manage security gates and water valves in a factory.

The product:

• a standalone Linux-based controller –it sits in a physical cabinet, not a cloud; • the application – a C++ binary that listens for ‘open/close’ commands and logs telemetry; • the user interface – a small local touch-screen and a restricted SSH port for maintenance.

ENISA Secure by Design and Default Playbook Version: 1.0

The goal. You want to prove to your industrial clients that SafeGate-X1 is not just a black box and is built following the secure by design principles of least privilege, minimal attack surface, strong identity and vulnerability and patch management.

Disclaimer: This Machine-processable attestation example and the SafeGate-X1 scenario are provided solely as conceptual models to illustrate the practical integration of secure by design principles into automated verification workflows. They do not constitute formal legal or technical advice and should not be treated as a definitive proof of compliance with specific regulatory frameworks, such as the EU Cyber Resilience Act, or as a substitute for certified audit processes.

5.4.2.1 Threat model

You use the guidance on threat modelling to define the product scope, assumptions and security objectives.

Category Details

SafeGate-X1 is modelled as a set of interacting processes with varying trust levels.

• Trust Boundary A (External/Network): Separates the untrusted factory LAN from the device’s listening services (HTTPS/SSH). • Trust Boundary B (User/System): Separates the non-privileged gate-service user from the restricted root system functions. • Privileged Path (The Update Channel): A high-integrity path from the Update Server to the internal flash storage. • Privileged Path (Admin Maintenance): A short-lived, certificate-signed path for the Maintenance Engineer to access the OS shell.

ENISA Secure by Design and Default Playbook

Note that Figure 4 provides an illustrative system representation for this simplified example. It is not intended to prescribe a standard notation or a particular tool. Other suitable approaches, including dedicated threat-modelling tools, may be used.

The threats in this example are specific to the illustrated product and should be adapted to the product’s functionality and deployment context. The example below uses likelihood/impact ratings for prioritisation as an example

5.4.2.2 Controls, defaults and verification

This section maps the threats to specific principles and verification methods.

ENISA Secure by Design and Default Playbook Version: 1.0

5.4.2.3 Applying the three layers

The SafeGate-X1 example can be read across the three layers as follows.

• Control layer o Records the strategic objectives and their relationship to the identified threat scenarios (T1–T5), for example: ‘Unauthorised gate operation must be prevented.’ • Implementation layer o Identifies relevant principles and controls, for example: ‘We apply least privilege and attack surface minimisation.’ o Describes the technical settings used to implement them, for example: ‘We run as UID 1001, use Linux capabilities and close all ports except 443.’ • Assessment and verification layer o Records the checks performed, release gates and SBOM hashes, for example: ‘Nmap and Lynis confirm these settings; we provide the cryptographic hashes of the evidence.’

Attack surface minimisation (T1/T3) • Logic. If the threat is an external compromise (RCE), we remove the tools an attacker needs to escalate (sh, curl, etc.). • Implementation. We use a Distroless ( ) base image. • Gate. An automated Nmap scan runs against the deployed release candidate. It compares the active ports against the ports_allowed list in the JSON. If a mismatch is found, the release fails and the firmware is rejected.

The JSON fragment presented as Figure 5 illustrates how information from the three layers could be expressed in a machine-processable form. The field names and structure are illustrative only and do not define a specific schema or implementation format. In practice, this information may be represented using existing standards and specifications, like those described in Section 5.3.

ENISA Secure by Design and Default Playbook Version: 1.0

Least privilege (T2) • Logic. If the web service is compromised, it should not have permission to modify the system. • Implementation. The application is assigned UID 1001 with no entry in the sudoers file. • Gate. A Systemd audit script parses the service unit files. It verifies that CapabilityBoundingSet is restricted to only necessary network calls, ensuring that the principle of least privilege is hard-coded into the operating system execution.

Strong identity (T4) • Logic. Credential stuffing and brute-force attacks rely on passwords. • Implementation. We disable password logins entirely at the configuration level. • Gate. Before the gold image of the firmware is generated, a linter checks sshd_config to ensure PasswordAuthentication is set to no.

Vulnerability and patch management (T5) • Logic. Even following a compromise, the attacker should not be able to achieve persistence by modifying system files. • Implementation. The root file system is mounted as read-only. • Gate. A CI test runs a script inside a staging environment that attempts to touch /usr/bin/test_file. If the file is successfully created, the release gate fails, as it has been proved that the secure by default setting was not correctly applied.

5.4.2.4 Illustrative example of third-party verification

The following table shows how machine-processable security information may be consumed by thirdparty assessors to identify relevant claims, locate supporting evidence and perform targeted verification activities.

Verification Threat Technical evidence (what to Principle gate (how it Auditor spot-check step ID look for) was tested)

Attack Distroless image; empty Run ls /bin/sh on the Nmap-Scansurface T1, T3 /bin/ and /usr/bin/ of device; it should return ‘File not Gate minimisation non-essential tools found’

ENISA Secure by Design and Default Playbook

systemd unit file showing Run ps aux and verify the Least Systemd- T2 User=1001 and restricted gate process is owned by privilege Unit-Audit capabilities gate-service, not root

sshd_config with SSH- Attempt to SSH using a

Strong

T4 PasswordAuthentication Config- password; the connection must

identity

no Validation be immediately rejected

Vulnerability Partition table Run touch /usr/bin/test; Mountand patch T5 showing/mounted as ro (read it should return ‘Read-only file Check-CI management only) system’

ENISA Secure by Design and Default Playbook Version: 1.0

6. Bibliography

1. Chidukwani, A., Zander, S., & Koutsakis, P. – Cybersecurity preparedness of small-to-medium businesses: A Western Australia study with broader implications. Computers & Security, 145, 104026, 2024. https://doi.org/10.1016/j.cose.2024.104026 2. ENISA, ENISA Cybersecurity for SMEs – Challenges and Recommendations, 2021: https://www.enisa.europa.eu/publications/enisa-report-cybersecurity-for-smes 3. European Commission. SME definition. Accessed 2026. https://single-marketeconomy.ec.europa.eu/smes/sme-fundamentals/sme-definition_en 4. European Commission. Small and medium-sized enterprises (SMEs). Accessed 2026. https://eur-lex.europa.eu/EN/legal-content/glossary/small-and-medium-sized-enterprises.html 5. ENISA. Cybersecurity for SMEs Challenges and Recommendations. 2021. https://www.enisa.europa.eu/sites/default/files/publications/ENISA%20Report%20- %20Cybersecurity%20for%20SMES%20Challenges%20and%20Recommendations.pdf 6. ENISA. NIS Investments – Cybersecurity Policy Assessment. 2023. https://www.enisa.europa.eu/sites/default/files/publications/CSPA%20- %20NIS%20Investments%20-%202023.pdf

7. ENISA. Guidelines for Securing the Internet of Things, Secure supply chain for IoT. 2020. https://www.enisa.europa.eu/sites/default/files/publications/ENISA%20Report%20- %20Guidelines%20for%20Securing%20the%20Internet%20of%20Things.pdf

8. ENISA. Baseline Security Recommendations for IoT. 2017 https://www.enisa.europa.eu/sites/default/files/publications/WP2017%20O-1-1- 2%201%20Baseline%20Security%20Recommendations%20for%20IoT%20in%20the%20context %20of%20CII_FINAL.pdf

9. ENISA. Good practices for security of IoT, Secure Software Development Lifecycle, 2019. https://www.enisa.europa.eu/sites/default/files/publications/WP2019%20- %20O.1.1.1%20Good%20practices%20for%20security%20of%20IoT.pdf

10. OWASP. Authorization Testing (Web Security Testing Guide). Accessed 2026. https://owasp.org/www-project-web-security-testing-guide/latest/4- Web_Application_Security_Testing/05-Authorization_Testing/README

11. OWASP. Threat Modeling Cheat Sheet. Accessed 2026. https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html

12. OWASP. Threat Modeling Process. Accessed 2026. https://owasp.org/wwwcommunity/Threat_Modeling_Process

13. NIST. SP 800-160 Vol. 1 Rev. 1: Engineering Trustworthy Secure Systems. 2022. https://doi.org/10.6028/NIST.SP.800-160v1r1

14. OWASP. SAMM Model (Software Assurance Maturity Model). Accessed 2026. https://owaspsamm.org/model/

15. OWASP. OWASP Secure by Design Framework. 2025 https://owasp.org/www-project-secure-bydesign-framework/

16. OWASP. Threat modeling. Accessed 2026. https://owasp.org/www-community/Threat_Modeling

17. ETSI. EN 303 645 V3.1.3: Cyber Security for Consumer Internet of Things Baseline Requirements. 2024. https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pd f

18. NIST. SP 800-213: IoT Device Cybersecurity Guidance for the Federal Government. 2021. https://doi.org/10.6028/NIST.SP.800-213

ENISA Secure by Design and Default Playbook Version: 1.0

19. ENISA. Baseline Security Recommendations for IoT in the context of CII. 2017. https://www.enisa.europa.eu/sites/default/files/publications/WP2017%20O-1-1- 2%201%20Baseline%20Security%20Recommendations%20for%20IoT%20in%20the%20context %20of%20CII_FINAL.pdf

20. MITRE. CWE Top 25 Most Dangerous Software Weaknesses. Accessed 2026. https://cwe.mitre.org/top25/

21. OWASP. Top 10 2025. Accessed 2026. https://owasp.org/Top10/2025/

22. PURL. Accessed 2026. https://github.com/package-url/purl-spec

23. NIST NVD. CPE: Common Platform Enumeration. Accessed 2026. https://nvd.nist.gov/products/cpe

24. NIST. OSCAL: Open Security Controls Assessment Language. Accessed 2026. https://pages.nist.gov/OSCAL/

25. CycloneDX. Attestations Capability. Accessed 2026. https://cyclonedx.org/capabilities/attestations/

26. CycloneDX Authoritative Guide to Attestations, 2024, https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-Attestations-en.pdf

27. CycloneDX Assessor Studio, 2026, https://assessors.studio/

28. OpenSSF. Security Insights Specification. Accessed 2026. https://openssf.org/projects/securityinsights/

29. OpenSSF. Scorecard. Accessed 2026. https://openssf.org/projects/scorecard/

30. OWASP. Application Security Verification Standard (ASVS). Accessed 2026. https://owasp.org/www-project-application-security-verification-standard/

31. OWASP. Application Security Verification Standard (ASVS). 2025. https://github.com/OWASP/ASVS/raw/v5.0.0/5.0/OWASP_Application_Security_Verification_Stan dard_5.0.0_en.pdf

32. TC54. Transparency Exchange API Specification. Accessed 2026. https://tc54.org/tea/

33. Buildroot. Buildroot, Making Embedded Linux Easy. Accessed 2026. https://buildroot.org/

34. openSUSE. How to build a distroless image using SLE BCI. Accessed 2026. https://opensource.suse.com/bci-docs/guides/building-a-distroless-image/

35. CISA Categorically Unsafe Software. 2024. https://www.cisa.gov/news-events/news/categoricallyunsafe-software

36. Padmos, A. An extensive list of resources related to threat modelling. Gotta catch ’em all!. Accessed 2026. https://github.com/arnepadmos/threats

ENISA Secure by Design and Default Playbook

Annex A: Abbreviations

ENISA Secure by Design and Default Playbook Version: 1.0

Annex B: Cyber Resilience Act essential requirements

ID CRA text

ANNEX-1.PT1.1 Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

ANNEX-1.PT1.2 On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall:

ANNEX-1.PT1.2.a be made available on the market without known exploitable vulnerabilities;

ANNEX-1.PT1.2.b be made available on the market with a secure by default configuration, 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;

ANNEX-1.PT1.2.c ensure that vulnerabilities can be addressed through security updates, 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;

ANNEX-1.PT1.2.d ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access;

ANNEX-1.PT1.2.e protect the confidentiality of stored, transmitted or otherwise processed 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;

ANNEX-1.PT1.2.f protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions;

ANNEX-1.PT1.2.g process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation);

ANNEX-1.PT1.2.h protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks;

ANNEX-1.PT1.2.i minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks;

ANNEX-1.PT1.2.j be designed, developed and produced to limit attack surfaces, including external interfaces;

ANNEX-1.PT1.2.k be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;

ENISA Secure by Design and Default Playbook Version: 1.0

ANNEX-1.PT1.2.l provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user;

ANNEX-1.PT1.2.m provide the possibility for users to securely and easily remove on a 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;

ANNEX-1.PT2.2 in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates;

ANNEX-1.PT2.3 apply effective and regular tests and reviews of the security of the product with digital elements;

ANNEX-1.PT2.4 once a security update has been made available, share and publicly 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;

ANNEX-1.PT2.5 put in place and enforce a policy on coordinated vulnerability disclosure;

ANNEX-1.PT2.6 take measures to facilitate the sharing of information about potential 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;

ANNEX-1.PT2.7 provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner;

ANNEX-1.PT2.8 ensure that, where security updates are available to address identified 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.

ENISA Secure by Design and Default Playbook Version: 1.0

Annex C: Mapping security principles to Cyber Resilience Act essential requirements

Principle CRA essential Implementation support requirement

Trust ANNEX-1.PT1.1 Supports identification and assessment of cybersecurity boundaries and risks by making trust assumptions, assets and attack threat modelling paths explicit during design

ANNEX-1.PT1.2.d Supports protection from unauthorised access by clarifying where authentication and access controls are required between trust boundaries

ANNEX-1.PT1.2.e Supports confidentiality protections by identifying where data crosses trust boundaries and requires protection

ANNEX-1.PT1.2.f Supports integrity protection by identifying where data, commands or configuration cross boundaries and may require integrity controls

ANNEX-1.PT1.2.j Supports attack surface limitation by identifying exposed interfaces and unnecessary trust relationships

Least privilege ANNEX-1.PT1.2.d Supports protection from unauthorised access by limiting what authenticated users, services and processes are permitted to access or perform

ANNEX-1.PT1.2.f Supports integrity protection by limiting which identities are authorised to modify data, programs or configuration

ANNEX-1.PT1.2.g Supports data minimisation by limiting access to data to what is necessary for the intended purpose

Strong identity ANNEX-1.PT1.2.d Supports access protection by defining how identities and are authenticated and managed across interfaces

authentication

architecture ANNEX-1.PT1.2.l Supports logging and monitoring of authentication and access-related activity

Attack surface ANNEX-1.PT1.2.b Supports secure by default configuration by reducing minimisation enabled features and services at initial deployment

ENISA Secure by Design and Default Playbook Version: 1.0

ANNEX-1.PT1.2.j Supports attack surface limitation by reducing unnecessary interfaces, services and exposed functionality

Defence in depth ANNEX-1.PT1.2.h Supports availability and resilience by relying on multiple layers of protection rather than a single control

ANNEX-1.PT1.2.k Supports impact reduction by applying multiple mitigation mechanisms that limit the effect of exploitation

Open design ANNEX-1.PT2.3 Supports effective testing and review by using designs that can be examined and assessed

ANNEX-1.PT2.4 Supports vulnerability disclosure by aligning with transparent communication of security issues and fixes

Life-cycle ANNEX-1.PT1.2.c Supports the ability to address vulnerabilities over the management product lifetime through updates

ANNEX-1.PT1.2.m Supports secure decommissioning by providing mechanisms to remove data and settings at end of use

ANNEX-1.PT2.2 Supports timely remediation of vulnerabilities throughout the supported life cycle

ANNEX-1.PT2.7 Supports controlled and secure distribution of updates over time

User-centric ANNEX-1.PT1.2.b Supports secure by default configuration that users can design reasonably adopt and maintain

Secure coding ANNEX-1.PT1.2.a Supports release without known exploitable and verification vulnerabilities by identifying and addressing issues practices during development

ANNEX-1.PT2.1 Supports identification and documentation of vulnerable components during development

ANNEX-1.PT2.3 Supports regular testing and review of product security during development and before release

Logging, ANNEX-1.PT1.2.d Supports detection and reporting of unauthorised monitoring and access attempts

alerting

ANNEX-1.PT1.2.l Supports recording and monitoring of security-relevant internal activity

Configuration ANNEX-1.PT1.2.f Supports protection of configuration integrity by and change controlling, reviewing, and rolling back configuration management changes.

ENISA Secure by Design and Default Playbook Version: 1.0

ANNEX-1.PT1.2.d Supports protection from unauthorised access by restricting who can deploy or modify configurations, particularly in production environments

Incident ANNEX-1.PT1.2.h Supports recovery and continued availability of essential response and functions after incidents

recovery

ANNEX-1.PT1.2.k Supports reduction of incident impact through prepared response and mitigation actions

Vulnerability and ANNEX-1.PT2.1 Supports identification and tracking of vulnerable patch components and dependencies throughout the product management life cycle

ANNEX-1.PT2.2 Supports timely triage and remediation of identified vulnerabilities based on risk

ANNEX-1.PT2.4 Supports public disclosure of fixed vulnerabilities

ANNEX-1.PT2.5 Supports coordinated handling and disclosure of vulnerabilities

ANNEX-1.PT2.6 Supports mechanisms for receiving vulnerability reports from external parties

ANNEX-1.PT2.7 Supports secure distribution of patches and updates

ANNEX-1.PT2.8 Supports timely dissemination of security updates and related user guidance

Supply-chain ANNEX-1.PT1.2.a Supports reduction of exploitable vulnerabilities controls introduced through compromised components

ANNEX-1.PT2.1 Supports transparency of components and dependencies through SBOM generation

ANNEX-1.PT2.7 Supports secure distribution of updates through protected build and release channels

Minimisation of ANNEX-1.PT1.2.b Supports secure by default configuration by disabling default services non-essential features and services at initial deployment

ANNEX-1.PT1.2.i Supports minimising negative impact on other services by disabling non-essential functionality that could otherwise be abused or misused

ANNEX-1.PT1.2.j Supports limitation of attack surfaces by reducing exposed services and interfaces by default

Restrictive initial ANNEX-1.PT1.2.b Supports secure by default access settings by avoiding access permissive initial credentials and permissions

ENISA Secure by Design and Default Playbook Version: 1.0

ANNEX-1.PT1.2.d Supports protection from unauthorised access by enforcing restrictive authentication and access-control settings at first use

Secure ANNEX-1.PT1.2.b Supports secure by default configuration by enforcing communication encrypted and authenticated communications from initial by default connection

ANNEX-1.PT1.2.e Supports confidentiality of transmitted data by applying encryption to communications from first use

ANNEX-1.PT1.2.f Supports integrity protection of transmitted data by preventing unauthorised modification of data in transit

Unique device ANNEX-1.PT1.2.b Supports secure by default configuration by avoiding identity and shared credentials and shared cryptographic material

secrets by

default ANNEX-1.PT1.2.d Supports protection from unauthorised access by avoiding shared credentials and enforcing unique device authentication

ANNEX-1.PT1.2.e Supports confidentiality by preventing reuse or leakage of shared secrets across devices

Mandatory ANNEX-1.PT1.2.b Supports secure by default configuration by requiring security critical security features to be configured before initial onboarding exposure

ANNEX-1.PT1.2.d Supports protection from unauthorised access by ensuring that authentication and access controls are configured at first use

Automated ANNEX-1.PT1.2.b Supports a secure by default posture by enabling maintenance automatic security updates

and updates

ANNEX-1.PT1.2.c Supports the ability to address vulnerabilities through automatic security updates enabled by default

ANNEX-1.PT2.2 Supports timely remediation of vulnerabilities by reducing reliance on manual patch deployment

Supports secure and timely distribution of security ANNEX-1.PT2.7 updates by enabling automated update mechanisms

Transparent ANNEX-1.PT1.2.b Supports secure by default configuration by guiding security posture users back to a secure baseline when insecure choices are made

ANNEX-1.PT1.2.l Supports security-related information by informing users of security-relevant state changes and risks

ENISA Secure by Design and Default Playbook Version: 1.0

Secure recovery ANNEX-1.PT1.2.b Supports secure by default configuration by providing and ownership safe recovery and reset paths that restore a secure life cycle baseline

ANNEX-1.PT1.2.d Supports protection from unauthorised access during recovery, reset and ownership transfer processes

ANNEX-1.PT1.2.m Supports secure removal of data and settings during factory reset, decommissioning or ownership transfer

TP -01 -26 -016 -EN -N

ABOUT ENISA

The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common level of cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the European Union Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and processes with cybersecurity certification schemes, cooperates with Member States and EU bodies, and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building and awareness raising, the Agency works together with its key stakeholders to strengthen trust in the connected economy, to boost resilience of the Union’s infrastructure, and, ultimately, to keep Europe’s society and citizens digitally secure. More information about ENISA and its work can be found here: www.enisa.europa.eu.

ENISA

European Union Agency for Cybersecurity

Athens Office

Agamemnonos 14 Chalandri 15231, Attiki, Greece

Brussels Office

Rue de la Loi 107 1049 Brussels, Belgium

enisa.europa.eu

ISBN 978-92-9204-802-0