ENISA's Secure by Design Playbook: What It Means for Product Teams Under the CRA

Joan Romero — Wed, 08 Apr 2026 07:35:40 +0000

On 19 March 2026, ENISA published the Security by Design and Default Playbook (v0.4), a draft for public consultation. Most CRA guidance published so far targets legal and compliance teams. This one is aimed at the people building the product.

Summary

The core deliverable: 22 one-page playbooks. Each one takes a security principle and breaks it into a checklist, a minimum evidence set, and a release gate you can copy into your pre-release review. The principles split into two pillars: Secure by Design (14 principles, how the system is engineered) and Secure by Default (8 principles, how the product behaves on first deployment).

Beyond the playbooks, the document defines 8 risk management activities and a 5-step threat modelling process built for teams without a dedicated security function. Annex C maps all 22 principles to specific CRA Annex I requirements.

This is a working document. Here's what engineers will actually use from it.

The Playbook Format

Each of the 22 playbooks follows the same five-section structure:

Principle: the security concept
Objective: what it achieves and what failure modes it prevents
Checklist: highest-impact actions, scoped for lean teams
Minimum evidence: the smallest artefact set that demonstrates the checklist was completed
Release gate: pass/fail criteria, copy-pasteable into a release review or CI gate

The evidence and release gate sections are the most useful parts. They give you a definition of done that is concrete enough to put in a PR template or a release checklist. No security theatre, no vague "ensure security is considered" language.

Playbook 4.13 in full: Vulnerability & patch management

To show the depth of the format, here is Playbook 4.13 as it appears in the document.

Principle: Vulnerability and patch management should be practical, repeatable, and prioritised by risk. Teams need a simple intake path for researchers and customers to report issues, and an internal triage process that produces decisions quickly.

Objective: Identify, prioritise, and remediate vulnerabilities fast enough to reduce real-world exposure across code, dependencies, infrastructure, and firmware. Focus: a simple intake-to-fix workflow, clear SLAs, and an update mechanism that makes patching reliable.

Checklist:

Action	Details
Establish intake channels	Dependency scanning, SAST/DAST findings, supplier advisories, customer reports, security email. Assign a single owner for triage.
Triage and prioritise consistently	Lightweight severity (Critical/High/Med/Low) plus "internet-exposed?" and "known exploited?" flags. Decision: fix now, mitigate, accept (time-bound), or defer with rationale.
Patch dependencies proactively	Regular cadence (weekly/monthly). Pin versions, remove unused dependencies, track transitives.
Fix, test, and release securely	Review and test fixes; verify no regressions in auth/authz and input validation. For devices/IoT: secure OTA path and safe rollback.
Communicate and close the loop	Track affected versions, customers, mitigation guidance. Publish release notes or advisories. Confirm rollout and update the risk register.

Minimum evidence:

Vuln tracking board: issue, severity, affected components/versions, owner, status, target date
Defined SLAs: Critical triage within 48 hours; remediation target within X days (set to your reality)
CI scan evidence: dependency scanning + SAST outputs (and DAST where applicable)
Proactive dependency patches: SBOM or dependency inventory per release
Patch release record: link from vuln ticket to PRs to tests to release version to rollout confirmation
Exception log: accepted risks with owner, expiry, and compensating controls

Release gate:

Dependency and SAST scans run; Critical/High findings addressed or documented exception with owner and expiry
SBOM generated and stored for the release
Known vulnerabilities triaged with severity, owner, and target date
Patch process validated: fix reviewed, tests passed, release notes updated
For internet-exposed components: Critical/High mitigations in place before release
Accepted residual risk is time-bound and tracked
OTA/update (if applicable) validated for secure delivery; rollback documented

That is the complete playbook. One page in the document, self-contained, ready to implement. The other 21 playbooks follow the same structure.

The Threat Modelling Process

The playbook defines a 5-step threat modelling process built on STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). The explicit target: teams with no dedicated security function, where threat modelling currently competes with feature delivery.

The anti-patterns ENISA calls out: treating threat modelling as a one-off compliance exercise, building models too detailed to stay current, and skipping it after significant product changes.

Step 1: Define scope and security objectives. Time-box this. Capture what's in/out of scope, the deployment context, and the assumptions you're relying on (e.g., "customer network is untrusted", "cloud APIs are internet-exposed"). State the security objectives. Identify the crown jewels. Deliverable: 1-page "Threat Model Scope & Objectives".

Step 2: Model the system. A single simple architecture or data-flow diagram: main components, external entities, data stores, entry points, data flows. DFD-style is the fastest. The document says "don't overthink it." Deliverable: diagram covering components, entities, stores, entry points.

Step 3: Mark trust boundaries and privileged paths. Annotate the diagram where data, identities, and execution contexts cross from trusted to untrusted zones. Identify highest-privilege operations: firmware/OTA update, remote admin, key provisioning, identity issuance. Deliverable: diagram with trust boundaries, privileged paths, top assets.

Step 4: Identify and prioritise top threats. A short list of realistic abuse cases mapped to entry points and boundaries: "credential stuffing to account takeover", "malicious update", "API authorisation bypass", "MITM on onboarding". Rank with High/Med/Low based on impact and plausibility. Deliverable: threats table with 5-10 abuse cases, impact and likelihood, top risks list.

Step 5: Define mitigations, secure defaults, and verification. For each top threat: mitigation strategy, required controls, and the secure-by-default setting that should ship (e.g., "admin interface disabled by default", "no default passwords", "signed updates enforced"). Map each control to a verification method: CI checks, tests, config validation, release gate. Define re-run triggers: new internet-exposed interface, auth model change, new sensitive data, new critical dependency. Deliverable: Controls, Defaults, and Verification checklist.

The document's own calibration: even 2 hours of collaborative threat modelling with your team produces actionable results. Minimum viable, then refine.

Machine-Readable Security Manifests

Section 5 is the most forward-looking part of the document. The shift it describes: from static PDF compliance evidence to machine-readable, verifiable security attestations that your CI/CD pipeline and customers can automatically verify.

A machine-readable security attestation is a structured claim (JSON or YAML) asserting that a specific security control or process has been met. Unlike a PDF audit report, it can be generated by your pipeline, consumed by automated systems, and updated continuously. Security becomes intrinsic to the release process rather than a post-delivery check.

The document defines four properties these attestations should have:

Demonstrability: you can show that requirements were implemented, not just claim it
Verifiability: an independent party can programmatically authenticate and validate the integrity of claims
Reusability: attestations plug into existing agile quality gates and can be built on across releases
Reliability: customers and supply chain partners can rely on them for due diligence

The four-layer model

The playbook illustrates a hierarchical structure where every high-level security claim is backed by granular technical evidence:

Metadata & Attestation (Identity domain): product identity, versioning, manufacturer's cryptographic signature
Control Layer (Governance domain): structured security objectives aligned with requirements and regulations
Implementation Layer (Operational domain): maps specific threats to implemented mitigations, design principles, default settings
Assessment & Verification Layer (Evidence domain): machine-readable pass/fail results from automated gates, with links to SBOMs

The document also defines two access tiers: a Public-Facing JSON with high-level claims, and a Restricted Technical Overlay with encrypted tool configurations and test telemetry.

Where this fits in the existing ecosystem

The playbook situates MRSM within standards that already exist:

OSCAL (NIST): compliance as code, standardised security control catalogues, assessment results
CycloneDX CDXA (OWASP/ECMA-424): expanded from SBOM to a full transparency standard, including attestations and VEX
OpenSSF Security Insights: machine-readable security facts in YAML
OWASP ASVS: application security verification requirements
TC54 (Ecma International): Transparency Exchange API for SBOM and attestation discovery

MRSM is illustrative, not a proposed standard. But the trajectory it describes is real: CRA conformity evidence is moving from PDF folders to verifiable artifacts.

Where to Start

Pick one upcoming release and apply three playbooks. Not all 22.

Four playbooks that work for almost any team:

Playbook 4.9 (Secure coding practices): SAST/SCA in CI, banned patterns, security-sensitive PR review. Most teams can wire this into an existing pipeline in a day.
Playbook 4.13 (Vulnerability management): the one above. If you have no defined triage process today, this comes first.
Playbook 4.2 (Least privilege): minimum permissions per role and service. Audit it against what's actually running in production.
Playbook 4.16 (Restrictive initial access): no shared or default credentials. Enforce before the next release ships.

For threat modelling: the 5-step process above is calibrated for a 2-hour session with a whiteboard. Run it before your next architecture change.

Use the release gate criteria as your pre-release agenda. They are the fastest path from "no formal security review" to a repeatable, documented process.

The full playbook is available from ENISA as a v0.4 draft during the consultation period.

Official source: ENISA Security by Design and Default Playbook v0.4 (PDF)

Full reference guide: ENISA's Secure by Design Playbook: What It Means for Product Teams Under the CRA , covers all 22 principles, the full lifecycle phase table, and the complete CRA Annex I mapping.

This article is for informational purposes only and does not constitute legal advice.

DEV Community: CRA Evidence