The ENISA Secure by Design and Default Playbook
Twenty-two playbooks, published 30 July 2026, mapped here to the CRA Annex I essential requirements each one produces evidence for, using ENISA’s own Annex C mapping. With every release gate in full, and the requirements that rest on a single playbook.
Where the playbook fits in CRA compliance
ENISA published the playbook to explain secure by design and secure by default as repeatable actions that fit into engineering, product and release processes already in use. The audience is national and EU authorities and the private sector, with small and medium-sized manufacturers explicitly in view. That focus shows in the format, since each playbook is short and action-oriented rather than a specification to test against.
It is agency guidance rather than a standard, so it sits further from presumption of conformity than any harmonised or supporting standard does. Working through all 22 playbooks evidences the engineering work. It does not discharge the obligation, and nobody assessing your technical file will treat a completed playbook set as a conformity argument.
The practical value is organisational. The 22 map cleanly onto Annex I Part I, so using them as a work breakdown produces evidence in roughly the shape a technical file wants it. The route to presumption of conformity runs through the EN 40000 series instead, once those are cited in the Official Journal.
ENISA Secure by Design and Default Playbook
ENISA Secure by Design and Default Playbook, 22 playbooks, published 30 July 2026
Practical guidance on applying secure by design and secure by default principles across the life cycle of a product, written as repeatable actions that fit into existing engineering, product and release processes. The stated audience is national and EU authorities and the private sector, with small and medium-sized manufacturers explicitly in view.
Agency guidance, not a harmonised standard
ENISA guidance, not a standard and not a CRA harmonised standard. Applying the playbooks does not confer presumption of conformity with the CRA, because only a standard cited in the Official Journal does that. They are a good way to organise engineering work and to produce evidence a technical file can use. A completed playbook set evidences the work rather than discharging the obligation.
| Provision | Requirement & how the platform helps | CRA reference |
|---|---|---|
| Secure by design, architectural foundations | ||
| SBD-01 | Trust boundaries and threat modelling Identify where trust changes hands and model the threats that cross those boundaries. STRIDE threat catalogue and data-flow diagrams attached to each product record. | ANNEX I Part I (1) |
| SBD-02 | Least privilege Every component and account holds only the permissions its function requires. Elevation-of-privilege threats mapped to the Annex I access-control requirements. | ANNEX I Part I (2)(d) |
| SBD-03 | Strong identity and authentication architecture Identities are unique and authentication is designed rather than bolted on. Spoofing threats and authentication controls tracked per product. | ANNEX I Part I (2)(d) |
| SBD-04 | Attack surface minimisation Interfaces, services and features that are not needed are not shipped. Unnecessary-functionality review in the threat model and the Annex I checklist. | ANNEX I Part I (2)(j) |
| SBD-05 | Defence in depth No single control is load-bearing. Layers are designed to fail independently. Mitigation layering recorded against each threat, with residual risk after treatment. | ANNEX I Part I (2)(k) |
| SBD-06 | Open design Security rests on the strength of the design and its keys, not on secrecy of the mechanism. Design rationale captured in the risk assessment rather than assumed. | ANNEX I Part II (3) |
| Secure by design, operational integrity | ||
| SBD-07 | Life-cycle management Support windows, end-of-life and update commitments are defined and honoured. Support-period tracking and documentation-currency review per product. | ANNEX I Part I (2)(c) |
| SBD-08 | User-centric design The secure path is the easy path, so users are not pushed into unsafe workarounds. Annex II user-information obligations tracked alongside the secure-configuration requirement. | ANNEX I Part I (2)(b) |
| SBD-09 | Secure coding and verification practices Coding standards, review and testing are applied and their results retained. Security-review scheduling and test evidence attached to the technical file. | ANNEX I Part II (3) |
| SBD-10 | Logging, monitoring and alerting Security-relevant events are recorded and the records are usable after an incident. Monitoring-source configuration and the append-only audit log. | ANNEX I Part I (2)(l) |
| SBD-11 | Configuration and change management Changes are controlled and the shipped configuration is known and reproducible. Substantial-modification assessment and evidence versioning per product. | ANNEX I Part I (2)(f) |
| SBD-12 | Incident response and recovery Response roles, escalation and recovery paths are defined before they are needed. Article 14 three-stage workflow with the 24-hour, 72-hour and final-report clocks. | ANNEX I Part I (2)(h) |
| SBD-13 | Vulnerability and patch management Reports are received, triaged and remediated on a defined and evidenced process. The public disclosure portal, triage workflow, CSAF advisories and security.txt. | ANNEX I Part II (2) |
| SBD-14 | Supply-chain controls Third-party components are inventoried and monitored for newly disclosed vulnerabilities. SBOM registry with OSV and EUVD correlation, plus the findings ledger. | ANNEX I Part II (1) |
| Secure by default, default hardening | ||
| SBD-15 | Minimisation of default services Services and ports that are not needed for the intended purpose are off out of the box. Attack-surface review recorded against the Annex I secure-configuration requirement. | ANNEX I Part I (2)(j) |
| SBD-16 | Restrictive initial access The out-of-box state is closed rather than open, and opening it is a deliberate act. Secure-by-default configuration evidence and the factory-reset objective. | ANNEX I Part I (2)(b) |
| SBD-17 | Secure communication by default Transport protection is on by default rather than an option the user must find. Data-in-transit threats and the confidentiality controls tracked per product. | ANNEX I Part I (2)(e) |
| SBD-18 | Unique device identity and secrets by default No shared factory credentials. Each unit carries its own identity and secrets. Spoofing threats and the no-universal-default-password control in the Annex I checklist. | ANNEX I Part I (2)(d) |
| Secure by default, guided protection | ||
| SBD-19 | Mandatory security onboarding First-run forces the security-relevant decisions rather than deferring them indefinitely. Secure-setup guidance tracked as part of the Annex II user information. | ANNEX I Part I (2)(b) |
| SBD-20 | Automated maintenance and updates Security updates reach the field without requiring the user to go looking for them. Update-distribution tracking and CSAF advisory publication. | ANNEX I Part I (2)(c) |
| SBD-21 | Transparent security posture Users can see the security state of the product and what it is doing on their behalf. Public advisory publication and the portal status page for reported issues. | ANNEX I Part I (2)(l) |
| SBD-22 | Secure recovery and ownership life cycle Reset, resale and decommissioning remove the previous owner's data and access. Data-removal threats and the user-data deletion requirement in the Annex I checklist. | ANNEX I Part I (2)(m) |
Provision titles reproduced from the ENISA Secure by Design and Default Playbook, published by ENISA under CC BY 4.0. Descriptions and the evidence mapping are our own.
Which ones to do first
Twenty-two playbooks and 125 gate items is a lot to open cold, so ENISA suggests an adoption order (section 4.23). It is sequencing of effort, not permission to defer anything: a legal requirement that applies to your product applies from the start, whichever phase its playbook sits in.
Identify the threats, trust boundaries and security objectives that decide which of the remaining playbooks matter for this product, and in what order.
- SBD-01 Trust boundaries and threat modelling
The baseline ENISA suggests for most products, plus the secure-by-default playbooks that apply given what the product actually does.
- SBD-09 Secure coding and verification practices
- SBD-10 Logging, monitoring and alerting
- SBD-12 Incident response and recovery — availability-sensitive products may require early implementation
- SBD-13 Vulnerability and patch management
- SBD-14 Supply-chain controls
- SBD-16 Restrictive initial access — where the product provides user, administrative or maintenance access
- SBD-17 Secure communication by default — where the product communicates over a network or exchanges data with external components
- SBD-18 Unique device identity and secrets by default — where devices, product instances or services require identities or credentials
- SBD-20 Automated maintenance and updates — where the product can be updated after deployment
- SBD-22 Secure recovery and ownership life cycle — products supporting reset, ownership transfer or decommissioning
The remaining playbooks, prioritised by product context and identified risk. Later does not mean less important, and an applicable legal requirement is never deferred to this phase.
- SBD-02 Least privilege
- SBD-03 Strong identity and authentication architecture
- SBD-04 Attack surface minimisation
- SBD-05 Defence in depth
- SBD-06 Open design
- SBD-07 Life-cycle management
- SBD-08 User-centric design
- SBD-11 Configuration and change management
- SBD-15 Minimisation of default services
- SBD-19 Mandatory security onboarding
- SBD-21 Transparent security posture
Every release gate, in full
Each playbook ends in a release gate: the specific assertions a team should be able to make before shipping. There are 125 of them across the 22. This is the part that turns the guidance into something a release process can actually check, so it is reproduced here in full rather than summarised.
Secure by design, architectural foundations6 playbooks
Ensure that the system’s architecture and data flows are understood, trust assumptions are explicit and the highest-risk attack paths are identified early, so that security controls and secure defaults are designed in, not retrofitted.
- Diagram updated for this release (components, flows, dependencies reflect reality)
- Trust boundaries and privileged paths clearly marked
- Top threat scenarios reviewed; high risks have mitigations or documented exceptions
- Secure defaults confirmed for new/exposed interfaces (deny by default, least privilege)
- Verification in place: at least one negative test per critical boundary / privileged path (unauthorised access is denied)
- Threat model refresh triggered if any of the following are relevant: new API/interface, auth model change, new sensitive data, major dependency/supplier change, OTA/update changes, major architecture change.
Reduces unauthorised access, limits blast radius, blocks lateral movement and prevents permission creep.
- Unique service identities; no shared production admin keys
- Default-deny posture; only required paths enabled
- Admin access uses MFA and is time bound and logged
- Automated authorisation tests run verifying correct access restrictions for critical privileged functions
- Privilege review run; exceptions owned and time limited
Prevent impersonation and unauthorised access.
- Authoritative identity sources defined and documented
- Unique identities enforced; no shared production accounts or credentials
- Authentication required on all access paths (UI, APIs, device-to-cloud, management interfaces)
- Strong authentication enforced for privileged or sensitive actions
- Sessions and credentials are time limited, revocable and expire automatically
Reduce the likelihood and impact of compromise by eliminating unnecessary entry points and limiting attacker options.
- Exposed interfaces reviewed; only required APIs, ports, protocols and management interfaces enabled
- Default-deny posture confirmed; no unintended network paths or interfaces exposed
- Production build is minimal; unused libraries, services and optional components removed
- No development or diagnostic tools present in production unless there is evidence that it cannot impact security
- Attack surface review completed for this release; deprecated or legacy interfaces updates/removed
- Unnecessary data processing has been removed and required deletion mechanisms verified
Reduce the impact of security failures by layering independent controls that slow attackers, increase detection and prevent single points of compromise.
- Critical assets have more than one security control applied and the layering is documented.
- Layered controls are independent; no single identity source or enforcement point is a single point of failure.
- Security-relevant events are logged at multiple layers
- Alerts are in place for suspicious activity and a response action exists
Ensure that the product’s security does not depend on the secrecy of its design or implementation details (‘security through obscurity’). Open design makes security properties reviewable, testable and maintainable.
- Security design note updated for any architectural/security-relevant change (auth, crypto, update path, trust boundaries)
- No custom/proprietary crypto or undocumented security-critical protocols introduced
- API/security documentation updated (auth requirements, scopes/roles, rate limits, secure defaults)
- Secure configuration guide updated; defaults validated for new/exposed interfaces
- SBOM generated for the release and stored/published per policy
- Vulnerability disclosure channel tested (contact works) and ownership/triage defined
Secure by design, operational integrity8 playbooks
Ensure that security is maintained throughout the product’s full life cycle, from requirements and design through to deployment, maintenance and end of life, so that security does not degrade over time.
- Support status and life-cycle state for this release are clear (active, maintenance, etc.)
- Secure update path validated (integrity/authentication checks, rollback/recovery documented)
- Vulnerability triage completed for known issues (including third-party dependencies); decisions recorded (fix/mitigate/accept with expiry)
- SBOM generated (or dependency inventory updated) and stored for the release
- Security logging verified for critical events (authentication, admin actions, updates)
- Decommissioning actions defined for components introduced/changed (e.g. reset, wipe, key revocation)
- Any accepted residual security risk has an owner and review/expiry date
Ensure that security controls and secure defaults are usable, understandable and aligned with real user workflows, so that security outcomes do not depend on expert behaviour.
- Secure defaults reviewed and validated (no critical protections disabled by default)
- No default admin credentials active; onboarding enforces safe initial set-up
- Admin/security-critical actions have clear UX (confirmations, guidance and safe recovery paths)
- Roles and permissions match real user workflows; privilege escalation is explicit and auditable
- Security warnings / error messages are actionable (what, why, how to fix) and documented
- Basic usability check completed for key security flows (onboarding, admin tasks, recovery, updates); issues tracked/fixed or accepted with owner + date
Reduce common, high-impact vulnerabilities by eliminating relevant weakness classes through architectural and technology choices, where feasible, and by standardising how remaining risks are addressed in code, review and testing.
- Relevant vulnerability classes have been eliminated by construction where feasible; where not feasible, appropriate preventive and verification controls are in place.
- A secure coding baseline exists for the stack and is referenced in the repo
- SAST and dependency scanning run in CI; critical issues fixed or covered by a documented exception (with owner and expiry)
- Secret scanning enabled; no secrets committed; rotation performed if exposure occurred
- Security-sensitive changes were peer reviewed (auth/authz, crypto, parsers, external interfaces)
- Negative tests run on critical endpoints (unauthorised access denied; injection attempts fail)
- Dependencies reviewed for high/ critical vulns; patch/mitigation plan recorded for any accepted risk
Provide sufficient visibility to detect misuse, investigate incidents and maintain system integrity over time. The focus is on a small set of high-signal security events, reliable log retention and actionable alerts that do not overwhelm teams.
- Must-log security events implemented for new/changed components (auth, admin, updates, boundary events)
- Logs include attribution fields (actor, request/session ID, source) and are centralised
- Log access restricted, retention configured, time sync verified
- High-signal alerts enabled and assigned an owner (at least brute force events, new admin / role change, key/secret change, update failures)
- Triage runbook exists and has been tested recently (tabletop exercise or test alert)
- Logging/alerting exceptions are documented, with owner and review/expiry date
Prevent security regressions and outages by ensuring that system configuration is controlled, reviewable and reproducible and that changes are assessed for risk before reaching production. The priority is to eliminate ‘silent drift’, tighten defaults and make rollbacks reliable.
- Production config/IaC changes are versioned and peer-reviewed (no untracked manual edits)
- Secure baseline defaults applied; new components inherit baseline (network, IAM, logging)
- Dev/test/prod separated (accounts, projects, credentials); least privilege enforced for deployers
- CI/CD gates applied to config changes (policy checks, linting); approvals recorded
- Rollback plan exists for this release; rollback procedure tested recently or validated
- Security-impacting changes tagged and reviewed (exposure, IAM, secrets, crypto, updates, integrations)
- Exceptions (emergency changes) logged and post-reviewed, with owner and expiry date
Detect, contain and recover from security incidents quickly while limiting customer impact and preventing recurrence. The priority is a clear playbook, defined ownership, fast triage and reliable restore/rollback, supported by the minimum logging and backup evidence needed to act decisively.
- IR roles and escalation contacts are current
- Incident runbook exists and covers detect/triage/contain/recover with at least one common scenario
- Containment actions are ready
- Backups enabled for critical data/config; restore procedure documented and tested recently
- Post-incident, near-miss or tabletop notes exist and are updated
Identify, prioritise and remediate vulnerabilities fast enough to reduce real-world exposure, across your code, dependencies, infrastructure and (if applicable) devices/firmware. The focus is a simple intake-to-fix workflow, clear SLAs and an update mechanism that makes patching reliable.
- Dependency and SAST scans executed for the release; critical and high findings addressed or documented exception (with owner and expiry date)
- SBOM (or dependency inventory) generated/updated and stored for the release
- Known vulnerabilities affecting shipped components are triaged with severity information, owner and target date
- Patch process validated: fix reviewed, tests passed, and release notes updated as needed
- For internet-exposed components: mitigations or patches for critical- and high-severity issues are in place before release
- OTA/update (if applicable) validated for secure delivery; rollback/recovery documented
- Accepted residual risk is time bound and tracked to closure or review date
Reduce the risk of compromise through third parties (software components, libraries, build tools, CI/CD, contractors, hosting providers and hardware/firmware suppliers) by establishing minimum, repeatable controls that improve visibility, integrity and accountability across what you buy, build and ship.
- SBOM (or dependency inventory) generated and stored for this release
- Dependency scanning executed; critical- or high-severity issues fixed or covered by a documented exception (with owner and expiry date)
- New dependencies/suppliers reviewed and approved (recorded in PR/ticket)
- CI/CD and build secrets are protected; build/deploy permissions are least privilege and attributable
- Release artefacts signed (and provenance captured where feasible / per chosen SLSA target)
- Critical suppliers meet baseline expectations (security contact, vulnerability notification, support/patch commitments)
- Supply-chain risk exceptions recorded, with owner and review/expiry date
Secure by default, default hardening4 playbooks
Reduce the attack surface and ensure that products start in a hardened state, without relying on users to disable specific functionality.
- Only core functionality is enabled by default
- Optional features and services are disabled unless explicitly enabled by the user
- Users are informed of security implications when enabling non-essential features and services
- No new features or services are enabled by default without review
- Default configuration has been reviewed and confirmed for this release
To prevent immediate compromise after deployment by ensuring that attackers cannot gain access through default or weak initial access.
- No shared or default credentials present in production builds
- Unique credentials generated for each device or instance
- Secure set-up enforced before privileged or sensitive access
- Initial permissions are restrictive by default
- Initial access and onboarding paths are protected and reviewed
Protect data in transit and prevent interception, tampering or impersonation by ensuring that communications are always secure, without relying on user configuration or later hardening.
- External communications are encrypted and authenticated from first connection
- Insecure or plain-text protocols are disabled and unavailable
- Only approved secure protocol versions and configurations are enabled
- Endpoint authentication enforced where required
- Connection failures do not result in insecure fallback
- Cryptographic mechanisms can be replaced or migrated where required by the product’s risk assessment and support lifetime.
Prevent large-scale compromise by ensuring that a breach of one device or a leaked secret cannot be reused to attack other devices, customers or the wider installed base.
- Unique cryptographic identity generated for each device or instance
- No shared or default secrets present in production builds
- Secrets are protected against extraction
- Security-critical functions use per-device secrets
- Identity and secret revocation or replacement is supported
Secure by default, guided protection4 playbooks
Ensure that systems start in a secure state by preventing or limiting use before baseline security controls, such as strong authentication or encryption, are configured.
- Mandatory security steps are defined and enforced during initial set-up
- Users cannot bypass or skip critical security configuration
- Product cannot enter normal operation before onboarding completion
- Security onboarding provides clear guidance and secure defaults
- Onboarding is re-enforced if critical security settings are removed
Ensure that vulnerabilities are addressed quickly and the device is left vulnerable for as little time as possible.
- Security update functionality is enabled by default, with an installation approach appropriate to the product’s deployment context
- Security updates can be delivered independently of features
- Updates are cryptographically verified before installation
- Failed updates do not leave the system insecure or unusable
- Users are informed of update status without manual intervention
Reduce risk arising from accidental or uninformed misconfiguration by ensuring that users understand the security state of the system and can easily correct insecure settings.
- Secure baseline and degraded security states are defined and documented
- Current security state is clearly visible to the user
- Users are warned when security protections are reduced
- Security impact is explained in clear, non-technical language
- A simple action can be taken to restore the secure baseline
To enable users and administrators to recover access, reset systems or transfer ownership safely.
- Supported recovery and ownership transfer actions are defined
- Recovery and transfer actions require strong identity verification
- Recovery mechanisms cannot bypass normal access controls
- Factory reset and ownership transfer fully remove prior access
- Clear guidance is provided on recovery and transfer workflows
Playbook text from Secure by Design and Default Playbook by European Union Agency for Cybersecurity (ENISA), licensed under CC BY 4.0. Reformatted from Markdown into structured data. Section text unaltered.
Where the coverage is thin
ENISA’s own Annex C maps the 22 principles across all 22 Annex I essential requirements, so there is no requirement the playbook set ignores outright. The useful question is how thickly each one is covered, and the answer is uneven. The secure-by-default configuration requirement is supported by 10 of the 22, while the 6 below rest on a single playbook each.
That matters for planning rather than for compliance. A requirement supported by one playbook has one place where the work can quietly not happen, so these are the rows worth checking first if you are using the 22 as an Annex I work breakdown.
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.
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);
minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks;
put in place and enforce a policy on coordinated vulnerability disclosure;
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;
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.
Work all 125 gate items against your own product
The Compliance plan carries these 22 playbooks as a per-product tracker. Tick each release-gate item, link the evidence you already hold against the Annex I requirement it bears on, and record a named sign-off. Alongside the Annex I checklist and the Annex VII technical dossier export.