Smart devices, vehicles and medical equipment can be picked up, opened and probed by anyone who buys one. Sumrite’s in-house hardware researchers test them the same way: the circuit board, the firmware, the radio links, and the app and cloud that control the fleet.
Find open debug ports, readable flash and hard-coded keys before a researcher posts them online.
Make sure one compromised unit, app account or API call cannot reach every other customer’s device.
Evidence for the EU Cyber Resilience Act, ETSI EN 303 645, UNECE R155, ISO/SAE 21434, FDA premarket and IEC 62443 reviews.
Confirm secure boot and over-the-air updates cannot be abused to run attacker firmware.
A web or API test never looks inside the hardware. Most serious IoT breaches start with something physical: an open serial port, a firmware image anyone can read, a key shared by every unit, or an update that is never checked.
Sumrite’s IoT & Hardware Security Testing is done in-house by researchers who break hardware for a living. We test the device, the firmware, the radio and the cloud as one system, the way a real attacker would approach it.
Methodology, scope, and deliverables in plain terms.
Hands-on testing based on the OWASP Firmware Security Testing Methodology, the OWASP IoT Security Verification Standard and PTES, extended for automotive and medical devices.
Risk-rated report with device evidence, reproduction steps and fixes for hardware and firmware engineers. Re-test included on standard engagements.
IoT and hardware security testing is a hands-on assessment of a physical device and everything it depends on: the circuit board, the firmware, the radio links, the companion mobile app and the cloud services it reports to. Our researchers open the device and look for debug ports such as UART and JTAG, read the firmware straight off the flash chip, and take it apart to find hard-coded keys, default passwords, outdated components and unsafe update logic. They then test how the device talks to the world over Wi-Fi, Bluetooth Low Energy, Zigbee, LoRa or cellular, and whether its app and cloud APIs let one customer reach another customer's devices. For vehicles the same approach covers ECUs, the CAN bus and telematics units; for medical and industrial devices it covers the clinical or control functions that must keep working safely. Every finding is reproduced on the device and reported with the evidence and a fix your hardware and firmware engineers can apply.
| Area | What we check | Example finding |
|---|---|---|
| Hardware interfaces | UART, JTAG, SWD and test pads, plus flash and eMMC read-out | A root shell on an open UART port with no password |
| Firmware | Extraction, unpacking, secrets, components and binaries | The same private key baked into every unit shipped |
| Boot and updates | Secure boot, signing, rollback and over-the-air update logic | An unsigned OTA image accepted and run by the device |
| Wireless and radio | Wi-Fi, Bluetooth LE, Zigbee, LoRa, NFC and cellular links | BLE pairing that lets a nearby phone unlock the device |
| App and cloud | Companion mobile app, device APIs and fleet management | Changing a device ID in the API to control a stranger's device |
| Automotive and embedded | ECUs, CAN bus, diagnostics (UDS) and telematics | Diagnostic commands accepted without security access |
Usually two or three production-grade units, the firmware image if you have it, the companion app and test accounts, and any hardware or protocol documentation you can share. We can work without documentation, as an attacker would.
Some tests involve opening the casing or reading chips directly, so one unit may not go back to service. We agree in writing which units can be opened and which tests are off-limits before any work starts.
Yes. We test ECUs, CAN bus and telematics units for vehicles, and connected medical, industrial and consumer devices. Findings can be mapped to ISO/SAE 21434 and UNECE R155 for vehicles, FDA premarket cybersecurity expectations and IEC 81001-5-1 for medical devices, IEC 62443 for industrial systems and ETSI EN 303 645 and the EU Cyber Resilience Act for consumer products.
Yes, and we recommend it. Many of the worst IoT flaws sit in the mobile app or cloud API that controls the fleet, so we test the device, the app and the APIs as one system.
See all IoT & Hardware Security Testing questions in the FAQ →
We run the full engagement for these frameworks, and where a formal audit or attestation is needed we route it through our local partner firms, so you deal with one team.
Every step from scope and NDA to a retested, final report, shown for IoT & Hardware Security Testing. No jargon, no surprises.
Submit your scope so our team can plan the engagement and get started, often the same day.
Every phase is run by a security expert, with tools used only to speed up the routine parts. Findings are reproduced and confirmed before they reach your report.
Findings are written for two readers at once: the firmware and hardware engineers who fix them and the product, compliance and safety teams who sign off.
Your team fixes the issues with guidance written for your stack, and the tester who found each issue answers questions directly.
Every fix is tested again. Nothing is marked closed on trust.
You receive a verified report in your company name, ready for clients, auditors and procurement.
Tell us what the device does and how many units you can share. We scope the lab work around it.
Test Your Connected Device. Or run a free scan