# Will you attempt secure-boot bypass during a hardware engagement, and what evidence do you provide? **slug:** `secure-boot-bypass-scope` · **URL:** `/knowledge/faq/secure-boot-bypass-scope/` · **category:** Hardware Engagement Scope · **reviewer:** Gleb ### Short answer Yes, when secure-boot integrity is in the engagement scope. We follow a documented escalation from non-invasive techniques (firmware extraction via debug interfaces, boot-flow observation) to semi-invasive (chip decapsulation, fault injection) only when the scope requires it and the client has approved the destructive cost. Evidence includes the exploitation path, reproduction guide, and an architectural-remediation recommendation that distinguishes immediate workarounds from long-term hardware-revision-required fixes. ### Long answer Secure boot covers a chain — boot ROM, first-stage bootloader, second-stage bootloader, kernel, root filesystem — where each stage cryptographically validates the next. A "secure boot bypass" in a real engagement is rarely a single defeat; it is a chain of weaknesses connecting one stage to the next. For each engagement we agree the bypass-attempt scope in three tiers. Tier 1 — Non-invasive analysis: firmware extraction from accessible interfaces (JTAG, SWD, UART, eMMC pin sniffing on populated boards), boot-flow observation, key-handling review in the readable bootloader. Tier 2 — Semi-invasive: chip decapsulation, optical fault injection, voltage glitching to bypass signature verification, electromagnetic fault injection. Tier 3 — Invasive: probing, microprobing, focused ion beam analysis. Tier 3 is rare and requires laboratory infrastructure outside our standard delivery. The Tier-2 escalation decision involves destructive cost — fault-injection equipment is non-trivially expensive to amortize per engagement, sample devices may be destroyed in the process, and the test methodology requires multiple identical hardware revisions for statistical confidence. We surface this decision to the client before incurring the cost. Our evidence package for secure-boot findings includes: written exploitation path documenting the chain of weaknesses, reproduction guide with required equipment list, captured artifacts (firmware images, glitch waveforms, fault-injection setup photos), and a remediation recommendation distinguishing software workarounds applicable to deployed devices in the field from hardware-design changes that require a board revision. This distinction matters for the client's remediation planning — a board revision is a months-long product effort that ships with the next hardware refresh, while a software workaround can ship in a firmware update. ### Related - [IoT & embedded security service](/services/iot-embedded-security/) - [ECU](/knowledge/glossary/ecu/) ---