How to Use This Handbook

The Secure-by-Design Handbook helps teams building connected products turn cybersecurity obligations into engineering, operating, and evidence tasks.

Use this page when you know your role or immediate problem, but not which handbook path to follow.

If you are new to the topic, start with What is Secure-by-Design?. If you need a short action plan, use the First-Sprint Checklist.

Choose By Task

If you need to...	Start here	Then use
Understand obligations	CRA 5-Minute Primer	CRA Overview, CRA Readiness Gap Analysis
Assess product readiness	CRA Readiness Gap Analysis	Secure-by-Design Evidence Pack, Maturity Model
Plan the first sprint	First-Sprint Checklist	Threat Modeling, Types of Embedded Device
Design core product controls	Threat Modeling	Secure Boot, Secure OTA Updates, Key Provisioning & Storage, Unique Device Identity
Handle vulnerabilities	Vulnerability Disclosure	Patch Cadence, SBOM & VEX Workflows, Policy Starter Kit
Assemble evidence	Secure-by-Design Evidence Pack	CRA Gap Analysis, Resources
Choose hardware or architecture	Types of Embedded Device	STM32 Hardware Selection, ESP32 Hardware Selection
Compare tools	Tools	Use tools only after the workflow or control is clear.

Choose By Role

Different readers usually need different routes through the same material.

Product Manager Or Team Lead

Your job is to make the work visible, owned, and planned.

Start with:

1. What is Secure-by-Design?
2. CRA 5-Minute Primer
3. First-Sprint Checklist
4. CRA Readiness Gap Analysis

Expected output: owners, first-sprint backlog, readiness gaps, and evidence owners.

Firmware Or Embedded Engineer

Your job is to design controls that fit the product architecture.

Start with:

1. Types of Embedded Device
2. Threat Modeling
3. Secure Boot
4. Key Provisioning & Storage
5. Unique Device Identity
6. Secure OTA Updates

Expected output: architecture decisions, control design, implementation backlog, and test evidence.

Cloud, DevOps, Or Security Engineer

Your job is to connect product security to pipelines, services, monitoring, updates, and vulnerability handling.

Start with:

1. CI/CD Pipeline Hardening
2. SBOM & VEX Workflows
3. Secure OTA Updates
4. Vulnerability Disclosure
5. Security Logging & Monitoring

Expected output: pipeline controls, dependency records, vulnerability workflow, update records, and monitoring evidence.

Compliance Lead Or Auditor

Your job is to understand obligations and check whether product evidence supports the claims.

Start with:

1. CRA Overview
2. CRA Readiness Gap Analysis
3. Secure-by-Design Evidence Pack
4. Policy Starter Kit
5. Resources

Expected output: scope notes, gap register, evidence register, policy set, and open issues.

Hardware Selector Or Architect

Your job is to choose hardware that can support the intended security case.

Start with:

1. Types of Embedded Device
2. STM32 Hardware Selection or ESP32 Hardware Selection
3. Secure Boot
4. Key Provisioning & Storage
5. Cryptography under the CRA

Expected output: hardware rationale, security feature mapping, supplier evidence, and lifecycle assumptions.

How The Sections Fit Together

Section	Use it for
Quick Start	Orientation, first actions, and role-based routing.
Standards & Regulations	Legal and standards context, including CRA, RED, NIS 2, PSTI, IEC 62443, FDA, and harmonised standards.
Implementation Guides	Engineering and operating guides for controls such as secure boot, OTA, identity, provisioning, SBOM/VEX, logging, CVD, and patch cadence.
Resources	Checklists, evidence guidance, policy templates, hardware-selection guides, cryptography guidance, examples, and vulnerability case studies.
Tools	Product and open-source tools that may support workflows after the requirements are clear.

Working Pattern

For most teams, the handbook works best in this order:

1. Define the product boundary and architecture.
2. Run a gap analysis.
3. Pick the highest-risk controls to design or improve.
4. Capture evidence as you go.
5. Review policies, vulnerability handling, updates, and support-period commitments.
6. Use tools to support the workflow, not to replace the workflow.

Contributing

This handbook is a living document. To suggest a correction or improvement, see the Contributing Guide or open an issue on GitHub.