36 docs tagged with "cra"

A secure-by-design case study showing how a default cryptographic key created a shared failure domain across connected patient monitors.

A secure-by-design case study showing how hard-coded credentials, weak firmware integrity, exposed interfaces, and insufficient logging affected a portable ventilator.

A secure-by-design case study showing how hidden firmware functionality, insecure update behavior, and patient-data exposure affected a connected patient monitor.

A secure-by-design case study showing how service credential exposure in a networked medical imaging ecosystem can affect patient-data integrity and availability.

A secure-by-design case study showing how local access, hard-coded credentials, kiosk escape, and command injection can affect clinical devices.

1. Introduction to CI/CD Hardening

The EU Cyber-Resilience Act (CRA) is a landmark law that makes cybersecurity a mandatory, legal requirement for all "products with digital elements" sold in the European Union. For the first time, secure-by-design principles are moving from best practice to a legal obligation, enforced through CE marking.

Why this matters now

A practical CRA readiness checklist for connected-product teams assessing scope, secure-by-design controls, vulnerability handling, technical documentation, evidence gaps, and next actions.

Practical guidance for connected-product teams assessing cryptographic algorithms, protocols, keys, firmware integrity, data protection, crypto agility, and CRA evidence.

1. Why the CRA matters now

1. Introduction to Data Privacy

1. Introduction

A practical guide to assessing whether Espressif ESP32 chips and modules can support secure-by-design controls, CRA readiness, supplier evidence, and lifecycle commitments.

Why this matters now

Use this checklist when a connected-product team needs to start secure-by-design work quickly and turn it into sprint-sized actions.

This glossary defines key terms, acronyms, and concepts used throughout the Secure-by-Design Handbook.

Patch cadence is the operating commitment for how quickly a manufacturer assesses, remediates, releases, communicates, and evidences fixes for vulnerabilities. Rollback strategy defines when reverting an update is safe, when it is dangerous, and how the product recovers without reintroducing known risk.

1. Introduction

A practical hub for secure-by-design case studies, routing real product vulnerabilities by failure pattern, control area, evidence lesson, and product-team check.

A Software Bill of Materials (SBOM) records the software components in a product or release. A Vulnerability Exploitability eXchange (VEX) record explains whether a known vulnerability in one of those components affects the product.

Secure boot is the product control that prevents unauthorised firmware or software from running during startup. For connected products, it is one of the main ways to protect firmware integrity, support trustworthy updates, and retain evidence that the released product boots only code approved by the manufacturer.

1. Introduction to Secure Configuration

Secure over-the-air (OTA) updates let a manufacturer deliver security fixes to deployed products without weakening firmware integrity, bricking devices, or losing evidence of what changed. For connected products, the update mechanism is part of the security architecture, not just a delivery channel.

1. Introduction

A secure-by-design evidence pack is a structured collection of documents, records, and technical artefacts that helps show how a connected product was designed, built, assessed, released, supported, and maintained.

A practical secure-by-design maturity model for connected-product teams assessing CRA readiness, product-security practices, evidence quality, vulnerability handling, secure updates, and lifecycle support.

Starter policy templates and outlines for connected-product teams covering coordinated vulnerability disclosure, vulnerability handling, security updates, secure development, and CRA evidence records.

1. Introduction to Security Logging

1. Introduction

A practical guide to assessing whether STM32 parts and ST collateral can support secure-by-design controls, CRA readiness, supplier evidence, and lifecycle commitments.

Threat modeling is the structured process for understanding how a connected product could be attacked, what risks matter most, which mitigations are needed, and what evidence supports those decisions.

A practical guide to classifying embedded device architectures and understanding how MCUs, embedded Linux systems, and hybrid designs affect secure-by-design controls, CRA readiness, and evidence.

1. Introduction to User Documentation

Coordinated Vulnerability Disclosure (CVD) is the process that lets researchers, customers, users, and partners report potential vulnerabilities to a manufacturer so the issue can be triaged, remediated, communicated, and evidenced.

Secure-by-design means making security part of product architecture, defaults, development, update, vulnerability handling, and lifecycle evidence. It is not a final test before release, a feature added by the security team, or a burden passed to the customer.