Mobile Application Testing
Evaluate mobile apps and connected APIs for insecure data flows and client-side abuse paths.
View service detailsIoT & Embedded Security · Central Illinois
An attacker with your device on a bench has unlimited time and a soldering iron.
Connected products fail differently from software. The threat model includes someone who bought your device, opened it, attached probes to the debug header, dumped the flash, and extracted the credentials you shipped to every unit. We test the device, the radio, the firmware, the update mechanism, and the cloud behind it as one system.
What iot security testing actually covers
IoT security testing covers the full product ecosystem rather than one component. That means the physical device and its circuit board, the firmware running on it, the protocols it speaks over the air and over the wire, the companion mobile or web application, and the cloud services that tie a fleet of devices to a fleet of user accounts. Weaknesses in connected products are almost always about how those pieces trust each other.
We begin at the hardware. Boards get opened, components identified, and debug interfaces located — UART, JTAG, and SWD headers are frequently present and frequently unlocked on shipping hardware. Where they are not, flash memory can often be read directly off the chip. Either route usually produces the firmware image, and the firmware image usually produces the keys.
The finding that matters most in this space is shared secrets. A single hardcoded credential or a signing key embedded in firmware does not compromise one device — it compromises every unit you have ever shipped, and there is no patch that fixes the ones already in the field. Update integrity is the close second: if firmware updates are unsigned or delivered over cleartext, an attacker who can reach the device can own it permanently.
When you need this test
You are shipping a product and it is a one-way door
Hardware cannot be hotfixed. A key baked into a production run is in the field for the life of the product, so pre-production testing is worth several times what post-launch testing is worth.
The device sits on customer networks
A compromised connected device is a foothold inside somebody else's network, which makes your product their supply chain risk and their security team's problem to escalate to you.
Regulation is arriving
The EU Cyber Resilience Act, the US Cyber Trust Mark, and sector-specific medical and industrial requirements all expect documented security assessment of connected products.
It controls something physical
Locks, cameras, medical devices, industrial actuators, and vehicle components carry consequences that do not appear on a CVSS confidentiality axis.
You inherited the firmware from a contract manufacturer
Reference designs and vendor SDKs ship with default credentials, debug services, and test interfaces that nobody removed for production. This is extremely common.
What is in scope, and what is not
Included by default
- Hardware: board analysis, component identification, debug interface discovery and access
- Firmware: extraction, unpacking, filesystem and binary analysis, secret recovery
- Boot chain: secure boot verification, flash encryption, rollback protection
- Update mechanism: signature validation, transport security, downgrade and substitution attacks
- Radio and wired protocols: Wi-Fi, BLE, Zigbee, Z-Wave, sub-GHz, serial, and CAN where applicable
- Companion application and the cloud API tying devices to user accounts
Excluded unless contracted
- Silicon-level attacks such as decapping, fault injection, and side-channel analysis, unless specifically contracted
- Destructive testing beyond the sacrificial units provided for the engagement
- Manufacturing and supply chain process audit
- Safety certification, which is a separate discipline from security testing
Methodology, phase by phase
Every engagement follows the same documented arc. The percentages below describe how testing time is typically distributed — the balance shifts with what we find, but the phases do not change.
Scoping and hardware intake
Before testing beginsWe agree on the device variants in scope and how many units we need. Some units will not survive — flash removal and rework are destructive — so we ask for sacrificial hardware alongside working units, plus any documentation the manufacturer will share.
- Confirm device models, firmware versions, and hardware revisions in scope
- Arrange three to five physical units, including at least one designated sacrificial unit
- Collect available schematics, datasheets, and firmware images, noting that we test without them if unavailable
Hardware analysis and interface discovery
Roughly 25% of testing timeThe enclosure comes off and the board gets characterized. We identify the processor, memory, and radio modules, then hunt for the interfaces the manufacturer used during development and did not remove from production hardware.
- Board teardown, component identification, and datasheet correlation
- Test point mapping and identification of UART, JTAG, and SWD interfaces
- Attempt to obtain an interactive console or debug session, checking whether read protection fuses are actually set
- Direct flash memory read via in-circuit programming or chip removal where debug access is locked
Firmware extraction and analysis
Roughly 25% of testing timeFirmware is unpacked and read. We recover the filesystem, review the binaries, and search for the things that should never have shipped: private keys, API tokens, hardcoded passwords, debug backdoors, and libraries that stopped receiving patches years ago.
- Firmware unpacking and filesystem reconstruction from the extracted image
- Recovery of hardcoded credentials, private keys, certificates, and API tokens
- Third-party component inventory with known-vulnerability correlation against shipped versions
- Binary review of custom services, hardening checks, and evaluation of secure boot and flash encryption if present
Protocol, update, and ecosystem testing
Roughly 40% of testing timeWith the firmware understood, we attack the device as a live system. Radio traffic is captured and replayed, the update path is subverted, and the cloud API is tested for the cross-account and cross-device flaws that turn one compromised unit into fleet-wide access.
- Radio capture and analysis, including BLE pairing security, replay resistance, and key management
- Network service testing against the device's own listening ports and management interfaces
- Firmware update abuse: unsigned image acceptance, downgrade to a vulnerable version, transport interception
- Cloud API testing for device impersonation, cross-account device access, and provisioning weaknesses
Reporting and retest
5–10 business days after testing endsFindings are separated by where the fix lives — silicon configuration, firmware, protocol design, or cloud — and by whether they are fixable in the field. A hardcoded key in shipped hardware is a different conversation from a server-side authorization bug, and the report frames it that way.
- Findings organized by layer, each flagged as field-fixable or requiring a hardware revision
- Physical evidence including board photography, probe points, and extracted artifacts
- Design-level recommendations for the next hardware revision, not just patches for this one
- Free retest of remediated findings within 90 days
Standards this maps to
Auditors, insurers, and enterprise security reviewers all ask which methodology a test followed. These are the published frameworks our process is built on, and the report names them explicitly.
- OWASP IoT Top 10
- The reference list of recurring connected-device failures — weak default credentials, insecure network services, insecure update mechanisms — which frames the baseline coverage.
- NIST IR 8259
- NIST's foundational cybersecurity activities for IoT device manufacturers. Useful as the yardstick for whether a product was designed to be securable, not just whether it currently has bugs.
- PTES
- The Penetration Testing Execution Standard defines the engagement arc we follow: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting.
- CVSS v4.0
- Every finding carries a CVSS v4.0 vector so the base score is reproducible, plus a separate business-impact rating, because a 9.8 on a decommissioned host is not your biggest problem.
What you receive
A human writes your report. Not a scanner export with a cover page, and not a template with your logo dropped into it.
- Findings organized by layer
- Hardware, firmware, protocol, and cloud reported separately, because each one lands with a different team and carries a different remediation timeline.
- Field-fixable versus hardware-revision flags
- Every finding is marked according to whether shipped units can be remediated over the air or whether the fix requires a new hardware revision. This drives your response plan more than severity does.
- Extracted secret inventory
- Every key, credential, and certificate recovered from firmware, with fleet-wide impact assessment. Anything shared across units is treated as compromised across the entire installed base.
- Firmware component inventory
- A bill of materials for the third-party code in your firmware with known-vulnerability correlation — increasingly what regulators and enterprise buyers ask for by name.
- Physical evidence package
- Board photography with annotated probe points, captured radio traffic, and the extracted firmware image, so your engineers can reproduce our results on their own bench.
- Next-revision design guidance
- Recommendations aimed at the hardware you have not built yet: fuse configuration, key provisioning, boot chain, and update architecture.
Typical scope and duration
- Typical testing window
- 10–20 business days
- Report delivery
- 5–10 business days after testing ends
- Total elapsed time
- 5–8 weeks from kickoff
- Common scope size
- 1–2 device models plus companion app and cloud
- Hardware required
- 3–5 units, at least one sacrificial
- Retest window
- 90 days, included
What drives the price
We quote a fixed fee after a short scoping call. No hourly billing, no change orders mid-engagement. These are the variables that move the number:
- How many device models and hardware revisions are in scope, since each board must be characterized separately
- Whether debug interfaces are locked, which pushes the work toward chip-off extraction and rework
- The number and exoticism of radio protocols, since uncommon or proprietary protocols require more analysis time
- Whether the companion app and cloud API are full assessments or exercised only through the device
- Whether secure boot and flash encryption are implemented, which raises both the effort and the value of the test
Frequently asked questions
How long does an IoT security assessment take?
Most device assessments run 10 to 20 business days of active testing, with the report 5 to 10 business days later — roughly 5 to 8 weeks end to end. Hardware work is less predictable than software work; a locked debug interface that forces chip-off extraction can add several days on its own.
What does an IoT assessment cost?
Cost tracks the number of device models, whether debug interfaces are locked, how many radio protocols are involved, and whether the companion app and cloud API are included as full assessments. We scope after seeing the product, since a board photo answers questions that a specification sheet does not.
How many devices do you need, and will you destroy them?
Three to five units, with at least one designated sacrificial. Chip removal and board rework are destructive by nature. We start with non-destructive techniques and only escalate when necessary, but you should expect at least one unit not to survive.
Do you need schematics and source code?
No. Attackers do not have them, so a black-box assessment reflects the real threat. Schematics and source do reduce the reconnaissance time, which means more of the window is spent finding issues rather than locating test points — so we take them when you can share them.
Should we test before or after production?
Before, with a wide margin. Hardware findings such as unlocked debug interfaces, missing secure boot, or a shared key baked into every unit are extremely expensive to fix after a production run and impossible to fix in devices already installed. Pre-production testing on engineering samples is the highest-value point in the product lifecycle.
Do you test the cloud platform and mobile app too?
Yes, and we recommend it. Most connected products are compromised through the cloud API rather than the device, because the API is what lets one compromised unit reach other customers' devices. The device, the app, and the cloud form one trust chain and testing them in isolation misses the flaws between them.
Related engagements
API Security Testing
Analyze API endpoints for authorization flaws, data exposure, and abuse opportunities.
View service detailsExternal Penetration Testing
Assess internet-facing assets to identify exploitable weaknesses before attackers do.
View service detailsNot sure this is the right test?
Tell us what you are trying to prove and to whom. A twenty-minute scoping call is usually enough to determine which engagement answers the question, and we will say so if the answer is a cheaper one.