Skip to content
Invadel

Hardware

Hardware & IoT
Penetration Testing

Starts at $5,200, fixed scope, free retest. See all pricing →

Get a fixed quote

Reply in one business day

Full scoping questionnaire 
Senior certified testers, manual-first185+ years combined experienceOnboarding within 24 hoursFree retest includedOur methodology

When you need it

When you need hardware & IoT penetration testing

The situations that bring teams to this engagement, and where it fits alongside the rest of your program.

  • A connected product is about to ship and nobody outside the engineering team has attacked it.
  • You are preparing an FDA premarket submission for a medical device and need cybersecurity testing evidence in the file.
  • An OEM, distributor, or enterprise customer requires third-party security testing before they will carry or deploy the device.
  • A researcher, customer, or field incident reported a device weakness and you need the rest of the attack surface checked.
  • Plant, building, or fleet equipment is joining the corporate network and IT wants to know what it exposes, with an internal test.
  • A defense or critical-infrastructure contract requires product security assurance, for example under CMMC or IEC 62443.

Firmware

Firmware penetration testing

Firmware penetration testing targets the part of a device that holds the secrets, the update logic, and the code that trusts every interface. We recover the image over UART, JTAG, or SWD debug ports, or by reading the SPI, I2C, or eMMC flash directly, then analyze it for hardcoded credentials and keys, private certificates, debug backdoors, and the boot chain that is supposed to reject unsigned code. Where the image is encrypted, we look for the key in the bootloader, the flash, or the update package.

From there we attack what the firmware exposes: an update mechanism that accepts an unsigned or downgraded image, a bootloader that drops to a shell, a partition that can be rewritten, or a secret that unlocks the rest of the fleet. Each finding comes with a secure-design fix your engineers can apply in the next build, such as signed updates with rollback protection, secrets moved into a secure element, or debug ports locked before units ship.

Embedded

Embedded systems penetration testing

Embedded systems penetration testing covers the hardware around the firmware: the microcontroller, the debug and flash interfaces, the radios, and the physical package. On the bench we identify every exposed interface, then test each one for the access it grants, from a UART console that skips authentication to a JTAG port that reads memory to a flash chip that can be desoldered and dumped. We also check that the microcontroller’s readout protection and debug-lock settings are actually enabled on production units, because a development configuration shipped by mistake leaves the whole device open.

The threat model decides how far we go. Where it justifies it, testing reaches the physical layer: tamper-response checks, chip-off flash extraction, fault injection against secure boot, and side-channel leakage analysis. Every technique is agreed during scoping, and the report explains what each finding means for the whole fleet, not just the unit on the bench.

Attack surface

Interfaces and radios we test

A connected device exposes far more than a network port. These are the interfaces and radios we probe, and what each one gives away.

What it is

UART
Serial console and debug output
JTAG and SWD
Chip debug and programming ports
SPI and eMMC flash
External and embedded flash storage
BLE
Bluetooth Low Energy
Wi-Fi
Wireless networking
Zigbee and LoRa
Low-power mesh and long-range radio

What we test for

UART
Unauthenticated shells, verbose boot logs, and hidden commands
JTAG and SWD
Memory read and write, firmware extraction, and boot manipulation
SPI and eMMC flash
Direct firmware dumps, secret recovery, and partition rewrites
BLE
Weak pairing, replay and relay, and unauthenticated characteristics
Wi-Fi
Provisioning flaws, weak keys, and traffic interception
Zigbee and LoRa
Missing encryption, replayable commands, and weak key management

Devices we test

IoT penetration testing services, from consumer devices to plant floor equipment

The attack surface changes with the device class, and so does the standard the report has to satisfy. These are the categories we test most.

Consumer and industrial IoT

Cameras, gateways, smart building controls, sensors, and the fleets behind them. Shared credentials across a fleet and insecure over-the-air updates are the common failures.

Medical device penetration testing

Connected diagnostic, monitoring, and therapy devices that meet the FD&C Act definition of a cyber device fall under section 524B, which requires cybersecurity information, including an SBOM, in FDA premarket submissions. We test to that scope and map findings to the FDA premarket guidance, from $5,200. Read our medical device penetration testing guide and the hardware testing price tiers.

Automotive and telematics

ECUs, telematics units, infotainment, and fleet trackers. Testing aligned to ISO/SAE 21434 and UNECE R155 expectations for cybersecurity management.

Operational technology and ICS

PLCs, HMIs, RTUs, and the protocol gateways between plant and enterprise networks. A single controller or HMI is tested here on the bench, from $5,200. Work inside a live plant, against IEC 62443 zones and conduits with passive discovery first and active steps only in agreed maintenance windows, is our OT and ICS penetration testing service. See also penetration testing for manufacturers.

Embedded and payment hardware

Point-of-sale terminals, kiosks, access-control readers, and custom embedded boards where secure boot, key storage, and tamper response decide the outcome.

What we look for

Hardware and IoT flaws we hunt for

Connected devices expose attack surfaces most security programs never see. We test at the firmware, interface, and physical layers to find the flaws before they reach the field.

Firmware Weaknesses

Extractable or poorly protected firmware that reveals keys, credentials, and device logic.

We test for

  • Firmware extraction and analysis
  • Hardcoded secrets and keys
  • Insecure update mechanisms
  • Signature and integrity checks

Debug & Physical Interfaces

Exposed ports that give an attacker direct access to the device internals.

We test for

  • UART, JTAG, and SWD access
  • SPI and I2C flash readout
  • Boot process manipulation
  • Console and debug shells

Wireless & Radio Protocols

Insecure communication an attacker can intercept, replay, or spoof.

We test for

  • BLE, Wi-Fi, and RF review
  • Replay and relay attacks
  • Weak or absent encryption
  • Pairing and authentication flaws

Physical & Side-Channel

Tamper and analysis attacks against the physical hardware itself.

We test for

  • Tamper resistance review
  • Chip-off and fault injection
  • Side-channel leakage
  • Secure element usage

The bench

Our hardware lab

Hardware testing is hands-on work, so devices come to our bench, shipped or accessed as agreed during scoping. Firmware extraction and the interface work described above happen there, and wireless and RF testing covers Bluetooth Low Energy, Wi-Fi, and sub-GHz protocols using software-defined radio, including replay, relay, and pairing attacks. The companion app and the cloud back end the device reports to can be tested remotely in the same engagement.

Standards

Standards we test against

  • OWASP IoT Security Verification Standard (ISVS) and the OWASP IoT Top 10 as the baseline for every connected device.
  • FDA premarket cybersecurity guidance and section 524B of the FD&C Act for medical devices, including SBOM and update expectations.
  • ISO/SAE 21434 and UNECE R155/R156 for automotive components and their update mechanisms.
  • IEC 62443 for industrial control systems, including zone and conduit segmentation testing.
  • ETSI EN 303 645 for consumer IoT and the security expectations of the EU Cyber Resilience Act.
  • Findings mapped to CWE and rated with CVSS, with a secure-design recommendation for each hardware weakness.

Methodology

Hardware penetration testing methodology

Full methodology →

Every engagement follows the Penetration Testing Execution Standard and the relevant OWASP guides.

These are the phases your hardware & IoT penetration testing runs through.

  1. 01

    Device teardown

    Components, interfaces, debug ports, and radios identified on the bench.

  2. 02

    Firmware extraction

    Firmware recovered over debug ports or from flash, then analyzed for secrets and logic flaws.

  3. 03

    Interface & radio testing

    UART, JTAG, SPI, BLE, Wi-Fi, and proprietary RF probed for access and replay.

  4. 04

    Physical & side-channel

    Tamper, fault-injection, and leakage testing where the threat model calls for it.

  5. 05

    Report & retest

    Secure-design guidance, then a free retest of the fixes.

How it works

How your engagement runs

From scope through the final retest, your team stays in the loop at every step, with findings tracked live in our platform.

  1. 01

    Scope & kickoff

    Targets, roles, and rules of engagement defined in writing, with a fixed scope and timeline.

  2. 02

    Testing goes live

    Findings post to your live platform dashboard the moment our testers confirm them.

  3. 03

    Track remediation

    Follow every finding from open to fixed, with severity, evidence, and status in one place.

  4. 04

    Report & retest

    Executive and technical reports land, then request a free retest in one click.

Compliance

Compliance frameworks this test satisfies

Findings are mapped to the requirement or control they evidence, so the same report serves your auditor, your customers, and your engineers.

HIPAATechnical safeguard evidence for medical and monitoring devices that create, store, or transmit ePHI.CMMC Level 2Product and OT security assurance for defense suppliers, alongside the enclave testing CMMC scoping depends on.ISO 27001Annex A 8.8 evidence for connected devices inside your ISMS scope, from building controls to field equipment.PCI DSSTesting of payment terminals, kiosks, and the networks they sit on as part of Requirement 11.4 coverage.
Common inHealthcare & MedTechReal Estate & PropTechManufacturingAll industries

Proof

Proof in the field

Every engagement is confidential, so the work below is anonymized to sector and engagement type.

All case studies →

Free

Retest on every penetration test

185+

Years combined experience

14

Senior in-house specialists

24h

Onboarding after signing

Fintech · Payments

Web Application Penetration Test

High risk

Critical: a remote code execution flaw in the application’s web framework that could have given an attacker full control of the server. We escalated it to the development team while the test was still running.

Outcome. The critical RCE was reported and remediated during the engagement via an emergency framework upgrade, which also closed the server-side request forgery, and the remaining findings were retested to confirmation.

1

Critical (RCE)

Mid-test

Critical remediated

2

High

Read the case study

HR & Payroll SaaS

Web Application Penetration Test

High risk

Critical: a file-inclusion flaw that let an attacker read sensitive files from the server through the application itself. High: stored cross-site scripting capable of session theft, insecure direct object references, and an authorization bypass that let an administrator create or delete organization owners.

Outcome. Delivered a remediation plan sequenced by real business impact, critical and high findings first, with a complimentary retest to verify every fix.

28

Findings

1

Critical

5

High

Read the case study
LatentPerygeeCity National BankAubaDesteiaDTCC
Request a reference 

Resources

Field notes from the offensive side

All articles →

IoT Penetration Testing: Firmware, Radio, and Physical Attacks

How IoT penetration testing works: firmware extraction, debug ports, BLE and RF attacks, cloud backends, and the standards a secure device maps to.

Medical Device Penetration Testing: The FDA Premarket Cybersecurity Guide

What FDA expects in premarket cybersecurity submissions under section 524B, how medical device penetration testing produces that evidence, and what to test.

Types of Penetration Testing: Every Kind, Explained

The types of penetration testing by target (web, API, mobile, network, cloud, hardware, AI), by method, and by cadence, with fixed prices and how to choose.

Want to see a report first?

Read a sample report for a fictional client, or request a redacted one from a real engagement. Our guide explains what a penetration testing report should contain.

See the sample report

FAQ

Frequently asked questions

What teams most often ask before scoping hardware & IoT penetration testing.

Still have questions? 
01What kinds of devices do you test?

We test IoT, embedded, medical, automotive, and operational technology hardware, covering the firmware, debug interfaces, wireless protocols, physical layer, and any companion apps or APIs.

02Do you need physical access to the device?

Yes. Hardware testing involves hands-on work with the device, so we agree how units are shipped or accessed during scoping. Companion applications and cloud services can also be tested remotely.

03How long does a hardware penetration test take?

Most engagements run one to three weeks depending on device complexity and the number of interfaces, followed by reporting and a complimentary retest.

04Which standards do you test against?

We align hardware testing to the OWASP IoT Security Verification Standard (ISVS) and the OWASP IoT Top 10, and for medical devices we map findings to the FDA premarket cybersecurity guidance so the report supports your regulatory submission.

05How much does a hardware penetration test cost?

Hardware penetration tests start at $5,200 for a small device, fixed before work begins, with a free retest included. Larger devices with more interfaces are quoted after scoping. Starting prices for every service are on our pricing page.

06Do you test the companion mobile app and cloud backend too?

Yes, and we recommend it. Most connected devices are only as secure as the app that configures them and the cloud service they report to. A hardware engagement can include the iOS and Android companion app and the backend APIs, tested by the same team under one fixed price, so the report covers the whole product rather than the box alone.

07Can you test pre-production prototypes and engineering samples?

Yes. Testing before manufacturing is the cheapest point to fix a hardware flaw, because a debug port left enabled or an unsigned firmware image is a design change before production and a recall afterward. We test engineering samples, development boards, and pre-certification units, and the report is written so it feeds your design review and any regulatory submission.

08What does an IoT security assessment include?

An IoT security assessment tests the whole product, not just the device: the firmware and its debug and flash interfaces, the wireless and radio protocols, the physical package where the threat model calls for it, and the companion app and cloud back end the device reports to. We align it to the OWASP IoT Security Verification Standard and the OWASP IoT Top 10. Read our IoT penetration testing guide for how the pieces fit together.

Ready to test your defenses?

Talk to our team about scoping hardware & IoT penetration testing.

Prefer the full scoping questionnaire? 
RelatedOT & ICS Internal Network Secure Code Review Red Teaming

Get a Fixed-Scope Quote

Tell us what you need tested. We reply within one business day.