25 docs tagged with "secure-by-design"

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. Why this guidance matters

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. Why EN 303 645 matters now

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

1. Why NIS 2 matters now

1. Why it matters for Connected Devices

1. Why PSTI matters now

1. Why the RED cyber rules matter now

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

1. Introduction to Secure Configuration

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.

1. Introduction to Security Logging

1. Why the Rules matter now

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.

A unique device identity is the product design that lets a device prove it is genuine, distinguishable from other devices, and entitled to access the services, updates, commands, data, and support paths assigned to it.

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.