AI & Emerging Technology Security
Embedded and IoT security testing
Security testing of connected devices end to end: firmware, hardware interfaces, wireless protocols, companion apps and cloud services.
- Coverage
- Firmware, hardware interfaces, wireless protocols, companion apps and cloud back-ends
- Typical devices
- Smart meters, gateways, cameras, wearables, medical, industrial and consumer IoT
- Reference standards
- OWASP IoT Top 10, OWASP FSTM, ETSI EN 303 645, NIST IR 8259
- You receive
- Executive summary, technical report with evidence, debrief and optional retest
Overview
About embedded and IoT security testing
A connected device is only as secure as its weakest layer: the firmware, the debug port left open on the circuit board, the Bluetooth pairing, the mobile app that controls it, or the cloud API it reports to. Attackers look at all of them, so our testing does too.
Embedded and IoT security testing is penetration testing for hardware products. We examine the device itself and the whole ecosystem around it, then show you which weaknesses could let someone take control of a device, extract secrets from it or use it to reach the rest of your network. It is part of the same VAPT discipline as our network and application testing, applied to physical products.
A typical starting point
You build or deploy connected devices, such as smart meters or medical, industrial or consumer IoT, and need to know they cannot be taken over.
The security problem
Where connected devices are vulnerable
Exposed debug interfaces
UART, JTAG and similar ports left enabled let attackers read firmware or gain a shell on the device.
Insecure firmware and updates
Hard-coded credentials, outdated components and unsigned updates that can be replaced with malicious firmware.
Weak wireless and protocol security
Bluetooth, Wi-Fi, Zigbee or proprietary radio links without proper authentication or encryption.
Insecure companion apps and cloud APIs
The app and cloud services behind a device often let one account control other customers’ devices.
What’s covered
What we test in a connected device
Area 01
Firmware
- Firmware extraction and unpacking
- Hardcoded credentials, keys and certificates
- Outdated or vulnerable third-party components
- Insecure update mechanisms, including missing signature checks and downgrade attacks
- Secure boot and code integrity protections
Area 02
Hardware interfaces
- Exposed debug interfaces such as UART, JTAG and SWD
- Access to flash memory and on-board storage
- Protection of secrets stored on the device
- Physical tamper resistance, where it matters for your threat model
Area 03
Wireless and network
- Bluetooth Low Energy pairing, encryption and exposed services
- Wi-Fi provisioning and onboarding flows
- Other radio protocols such as Zigbee, where in scope
- Exposed network services, and MQTT, CoAP or HTTP communication
Area 04
Companion apps and cloud
- Mobile apps used to set up and control the device
- Device-to-cloud authentication and identity
- Cloud APIs that manage fleets of devices, and whether one user can control another user’s device
Good to know
Testing the device alone is not enough
Many serious IoT weaknesses are not in the device at all, but in the cloud API that manages it or the app that controls it. Testing the whole ecosystem shows how an attacker could move from one layer to another, for example from a leaked key in firmware to every device in a fleet.
Good to know
Testing supports certification; it does not replace it
Our findings help you prepare for product security requirements and certification schemes. Formal certification is issued by the relevant accredited bodies.
Our approach
How an IoT security test is carried out
Step 1: Scoping and threat modelling
We agree the device models, firmware versions, interfaces and back-end environments in scope, and the threats that matter most to your product.
Step 2: Information gathering
We review documentation, component datasheets, network traffic and the companion app to map the attack surface.
Step 3: Firmware analysis
We extract and analyse firmware statically and, where possible, through emulation to find secrets, vulnerable components and weak update logic.
Step 4: Hardware and interface testing
We examine the board for debug interfaces and storage, and test whether they give access to the device or its secrets.
Step 5: Wireless, app and cloud testing
We test radio protocols, the companion app and the cloud APIs, including attacks that move from one layer to another.
Step 6: Reporting and debrief
Findings are documented with evidence, severity and fixes that fit your hardware and release constraints.
Step 7: Retesting (optional)
We verify fixes in new firmware or hardware revisions and issue an updated report.
Standards and references we work to
- OWASP IoT Top 10
- The most critical security risks for connected devices.
- OWASP FSTM
- Firmware Security Testing Methodology: a structured approach to firmware analysis.
- ETSI EN 303 645
- European baseline cybersecurity requirements for consumer IoT devices.
- NIST IR 8259
- NIST’s foundational cybersecurity activities for IoT device manufacturers.
- CVSS
- Consistent severity scoring for every finding.
What you receive
What you receive from an IoT test
Executive summary
Overall product risk, the most significant issues and recommended priorities.
Technical findings
Each issue with affected layer, severity, evidence, impact and remediation guidance.
Attack-path narrative
How weaknesses combine across device, app and cloud, so teams fix the chain rather than single issues.
Debrief
A working session with your engineering teams.
Retest report
If in scope, confirmation that fixes in new firmware or hardware revisions are effective.
Sample finding
Root shell available through the device debug port
Smart meter model X2: UART header J4
ETSI EN 303 645 Provision 5.6 (minimise exposed attack surfaces); OWASP IoT Top 10
- What we found
- An unlabelled UART header on the circuit board gives a root shell without a password.
- Evidence
- With physical access to a test unit, we connected to J4 and obtained a root shell, then extracted the firmware and a hard-coded API key. Photos and console logs attached.
- Business impact
- Brief physical access to one device would expose credentials shared by every device of this model.
- Fix
- Disable the UART console in production firmware, require authentication on any debug interface, and replace shared API keys with per-device credentials.
- Status
- OpenFix in progress
Before we start
What we need to test your device
- Test units of each device model in scope. Some testing can damage a unit, so we agree how many are needed.
- Firmware images and release notes, if available, which speed up analysis.
- Access to the companion app, test accounts and a test or staging cloud environment.
- Any available documentation: architecture diagrams, protocol descriptions and component lists.
- A technical contact from the firmware or product team.
Not sure you have everything?
We confirm exactly what embedded and IoT security testing needs from your side during the scoping call, before any work is agreed.
Book a scoping callFAQ
Questions about embedded and IoT security testing
Still have a question?
Ask about scope, timing or cost for embedded and IoT security testing, even if you are not ready to commission work yet.
Contact our teamDo you need physical devices, or can you test remotely?
Firmware analysis and cloud and app testing can often be done with firmware images and test accounts. Hardware and wireless testing need physical units. Most engagements combine both.
Will testing damage our devices?
Some hardware techniques, such as removing a memory chip, can damage a unit. We agree in advance which techniques are in scope and how many test units to provide, so nothing in use is ever put at risk.
Can you test devices we have bought, rather than built?
Yes. Organisations often test cameras, access control systems or industrial devices before deploying them. We confirm that testing is permitted under the product’s terms, and we report findings to you. You can decide whether to raise them with the vendor.
What about industrial control systems and OT?
We test connected devices and the networks around them, and approach operational technology environments with particular care because availability comes first. Live industrial systems are tested only under strict, agreed conditions, and often in a lab or test environment instead.
How long does an IoT security test take?
It depends on the number of device models, how many layers are in scope and the availability of firmware and documentation. We provide a fixed estimate after scoping.
Related services
Often combined with embedded and IoT security testing
Talk to us about IoT and embedded
Tell us what has prompted the conversation. We will reply to arrange a short, no-obligation scoping call for embedded and IoT security testing.