Question 1

Will you destroy our device?

Accepted Answer

Only if chip-off extraction is the only path to the firmware, and only with explicit written approval from your engineering and regulatory leads. The vast majority of engagements are non-destructive - we exhaust JTAG, SWD, UART, BDM, in-circuit SPI / QSPI, and bootloader recovery options before considering decap or chip-off. Even when chip-off is required, we typically need only one unit. We always ask for at least one extra unit as insurance and document chain of custody throughout.

Question 2

Do you need our source code?

Accepted Answer

No, but it dramatically accelerates analysis and reduces cost. Without source we reverse from binary in Ghidra (with IDA Pro and Binary Ninja as backup), build symbol tables manually, and reason about control flow from disassembly. With source we can target high-risk modules directly, validate compiler-introduced behavior, and produce deeper findings - root-cause analyses, exploit primitives, and remediation guidance keyed to specific files and functions - in the same calendar window.

Question 3

What if our debug ports are fused off?

Accepted Answer

Then we move to the alternatives in priority order: in-circuit SPI / QSPI flash readout, OTA package interception and replay, recovery-mode and bootloader exploitation, manufacturing test interfaces, and chip-off as a last resort. We also evaluate fault-injection paths against the lock bits themselves. A locked device is harder, not impossible - and the locking itself is something reviewers expect you to validate, which is part of what we test and document.

Question 4

Will you test our secure boot chain?

Accepted Answer

Yes - this is a primary focus and one of the highest-yield areas in firmware engagements. We validate the full chain from immutable ROM through bootloader stages to application image, test signature verification (RSA, ECDSA, post-quantum where applicable), attempt rollback and downgrade attacks, probe for partial-image acceptance, check anti-rollback counter implementation, and exercise the trust anchor provisioning flow. Findings are mapped to AAMI SW96 and IEC 81001-5-1 expectations.

Question 5

What about OTA updates?

Accepted Answer

Included in scope when the device supports OTA. We capture the update package over the air or from the update server, verify package signing and integrity validation, test downgrade and rollback prevention, attempt to inject modified images via the legitimate update path, validate transport security (TLS configuration, certificate pinning), and exercise the failure modes (interrupted update, mid-flash power loss, corrupted package). The OTA path is one of the most-cited areas in FDA deficiency letters.

Question 6

Do you do fault injection or side-channel attacks?

Accepted Answer

Voltage glitching and basic timing analysis are in scope for our Hardened / Locked tier when secure boot, secure-element security, or anti-tamper protections depend on it. Full power-analysis side-channel work (DPA, CPA against AES or ECC implementations) is a specialty engagement quoted separately and run on dedicated equipment. We'll recommend the right level of effort on the scoping call based on your threat model and the risk profile of the assets being protected.

Question 7

How does this map to FDA expectations?

Accepted Answer

FDA's February 2026 final premarket guidance and AAMI SW96 expect testing of secure-boot, integrity controls, the OTA update path, and the cryptographic implementations they rely on. IEC 81001-5-1 expects a secure development lifecycle that produces evidence at each phase. Our reports map findings directly to those frameworks plus your AAMI TIR57 risk file, so reviewers can trace each finding to the requirement, the test, and the residual risk without having to ask follow-up questions.

Question 8

How does this relate to your SBOM service?

Accepted Answer

We correlate our binary analysis against your SBOM to confirm that component versions in the actual built firmware match what's declared, identify undeclared third-party components surfaced during reversing, and verify whether known CVEs in declared components are actually exploitable in your specific build configuration. This is the kind of validated, build-grounded SBOM that FDA reviewers increasingly expect. If you don't have an SBOM yet, our SBOM service is the right place to start.

Question 9

How long does it take?

Accepted Answer

Three to four weeks for the Standard tier (open debug ports, source available, single processor). Four to six weeks for Hardened / Locked (fused debug ports, secure boot active, no source). Six to ten weeks for multi-processor systems with separate secure enclaves, multiple firmware images, or complex OTA architectures. Chip-off and reflow add roughly one week of lab time. The fixed-fee quote and timeline are confirmed in writing within 24 hours of scoping.

Question 10

What deliverables do we get?

Accepted Answer

Executive summary written for regulatory and product leadership, full technical findings with reversing notes and proof-of-concept where appropriate, an SBOM-to-finding correlation table, a secure-boot validation report, an OTA path assessment, an FDA-ready evidence appendix formatted for eSTAR submission, and a re-test report after remediation. Findings include CVSS scoring with a clinical-impact overlay aligned to your ISO 14971 hazard analysis.

Firmware Pen Testing. Done at the Silicon.

Why Most Pen Tests Never Touch the Firmware

No Hardware Lab

No Binary Reversing Skill

Secure Boot Treated as a Spec

What We Actually Test

Hardware Interface Discovery

Firmware Extraction

Binary Analysis & Reverse Engineering

Secure Boot & OTA

Engagement Methodology

Scoping & Hardware Intake

Interface Discovery & Extraction

Reverse Engineering & Exploitation

FDA-Ready Reporting & Re-test

Reviewer-ready deliverables in one engagement

Pricing Guidance

Standard Firmware

Hardened / Locked

Multi-Processor System

What drives the price

Related Premarket services

Full-Service FDA Premarket Cybersecurity

FDA Deficiency Response

FDA-Compliant SBOM Services

Firmware Pen Testing FAQs

Firmware Penetration Testing - scoped, fixed-fee, FDA-ready.