REDLINGS / THE BOOK

How
Device
Security
Fails.

Design Lessons from Real Attacks on Connected Devices

Ewan Fleischmann explains real attacks on connected devices: how attackers exploit weaknesses in firmware, hardware and backends, and which changes to the product can stop them.

Sign up for book updates Explore the contents
Written in EnglishRelease: Q4 2026 (planned)
3D working cover: How Device Security Fails by Ewan Fleischmann
HOW DEVICE SECURITY FAILSCover concept
ATTACKS ON CONNECTED DEVICES

Security features alone do not make a secure product.

Secure boot is enabled, firmware is signed and keys are stored encrypted. The checklist looks good. Yet an unchecked boot path can bypass signature verification, or malicious code can read a key while the device is running.

How Device Security Fails examines the gap between having security features and the protection they actually provide. Through real attacks, the book explains where implementation and architecture fail, which changes help, and how to verify their effect with targeted security tests.

Device keys and their reach

Which data and functions does a key unlock? The book examines how per-device keys, appropriate permissions and key replacement limit the damage after extraction.

Secure boot through to execution

A valid signature does not settle the security of the boot process. The book follows the path from the signed image to the code that runs, including metadata and alternative loading paths.

Updates, rollback and recovery

A failed update should not leave a device unusable. Recovery should not bring back an old vulnerability either. The book examines version and rollback policies that address both problems.

CONTENTS

Four parts.
14 chapters.

Start with a real attack, build a threat model, then apply it to firmware, hardware and backend security.

IFollow the Attack, Build the ModelAn attack on an industrial controller and a practical threat model.
  1. One Compromised Controller, a Shared Secret
  2. Draw the Boundaries — A Working Threat Model
IIExamine the BoundariesParser bugs, boot verification, isolation and device keys.
  1. A Way In — Parsers and the Work They Trigger
  2. The Image You Meant to Trust — Secure Boot Beyond the Signature
  3. What Compromised Code Can Still Do — Isolation and Privileged Interfaces
  4. One Key for the Whole Fleet — Device Secrets and Their Reach
IIIKeep the Product Secure Through ChangeProvisioning, recovery, key migration, physical access and shipped fixes.
  1. The Door That Never Closed — Provisioning, Service, and Ownership
  2. Turning Back Time — Firmware Rollback and Recovery
  3. When Trust Must Change — Key Migration Across Device Generations
  4. The Device Is in Their Hands — Physical Access and Hardware Protection
  5. Following the Fix — From Advisory to Shipped Firmware
IVDefend the Function, Make the DecisionAvailability, compromised backends and security testing.
  1. The Function Is the Target — Availability Under Hostile Input
  2. Trusted Commands, Hostile Intent — When the Backend Is Compromised
  3. Making the Call — Design Review and Retesting
ENGINEERING AND PRODUCT SECURITY

For engineers and security testers.

Written for firmware developers, hardware engineers and product security teams who build or assess connected devices. The examples examine code, memory access, keys and communication between devices and backends.

  • Firmware and hardware engineeringImplement protections that hold up against malicious input and compromised components.
  • Product architectureDefine permissions across devices, manufacturing, service and backends. Plan updates and key changes throughout the life of the product.
  • Product securityInvestigate attack paths in a threat model, design targeted security tests and check whether fixes address the vulnerability.
THE BOOK

Planned for Q4 2026.

The book is written in English by Ewan Fleischmann, founder of Redlings and a cryptographer with a PhD.

About Dr. Ewan Fleischmann
Release
Q4 2026 (planned)
Language
English
Author
Ewan Fleischmann