IoT Hardware Testing
Security testing for connected devices, firmware, embedded systems, and hardware attack surfaces, aligned with the EU Cyber Resilience Act (CRA), the CSA Singapore Cybersecurity Labelling Scheme, and regional IoT and critical-infrastructure expectations across Southeast Asia.
Connected devices create attack surfaces that span hardware, firmware, wireless protocols, mobile applications, cloud APIs, supply chains, and physical interfaces. Vantage Point's IoT Hardware Testing service helps product teams, manufacturers, and enterprises identify exploitable weaknesses before devices are deployed into customer, enterprise, industrial, or critical environments.
IoT and embedded products often combine physical access, firmware, wireless communications, cloud management, mobile applications, and long device lifetimes. A weakness in any layer can expose credentials, enable device takeover, compromise customer data, bypass product controls, or create a foothold into enterprise and operational environments.
Engagements are evidence-led and consultant-driven. Findings are reproduced, scored, and mapped to the standards that apply to your product, market, and deployment environment, including the CRA and ETSI EN 303 645 for European market access, and the CSA Singapore Cybersecurity Labelling Scheme (CLS) for consumer devices entering the Singapore market.
Connected hardware expands the attack surface beyond software.
Firmware exposure
Hardcoded credentials, insecure update packages, leaked keys, vulnerable libraries, unsafe bootloaders, and unauthenticated services routinely surface in firmware that has never been independently reviewed.
Hardware attack surface
Exposed UART, JTAG, SWD, SPI, eMMC, NAND, USB, debug pads, removable storage, and insecure production interfaces give physical attackers direct access to secrets and trust boundaries.
Wireless and protocol risk
Weak BLE, Wi-Fi, Zigbee, MQTT, CoAP, and proprietary radio implementations, insecure pairing, replay, downgrade, and unauthenticated command channels are common in shipping products.
Cloud and mobile ecosystem risk
Device APIs, mobile apps, onboarding flows, access tokens, telemetry, cloud storage, and fleet management platforms are often the easiest path to large-scale device compromise.
Lifecycle and update risk
Insecure OTA updates, lack of signed firmware, weak rollback protection, poor vulnerability handling, and limited product support all turn into long-tail security debt for shipped devices.
Regulatory and market access risk
Product teams increasingly need evidence that devices were designed, tested, maintained, and updated against recognised cybersecurity expectations, the CRA for European market access, the CSA Singapore Cybersecurity Labelling Scheme for consumer IoT entering Singapore, and MAS, OJK, and Bank of Thailand frameworks where devices touch regional financial or critical-infrastructure workflows.
What we test.
Coverage spans hardware, firmware, communications, companion applications, and cloud. Engagements scope which layers are in play based on the device, deployment, and standards alignment required.
Hardware interfaces
Physical access changes the threat model. We inspect the device, locate debug and storage interfaces, and validate whether they can be used to extract secrets or modify trust.
- UART, JTAG, SWD, SPI, I²C
- eMMC, NAND, removable storage
- USB and serial consoles
- Debug pads and boot-mode access
- Physical tamper points and casing
Firmware and embedded software
Firmware contains the operational logic, credentials, libraries, and trust decisions that determine whether the device can be compromised end-to-end.
- Firmware extraction and unpacking
- Filesystem, bootloader, kernel review
- Embedded Linux / RTOS analysis
- Binary and library analysis
- Hardcoded secrets and configuration
- Update mechanism and secure boot review
Device communications
Pairing, provisioning, and runtime communications often carry weaker security than the equivalent enterprise channels, and authenticate fewer things than they appear to.
- Wi-Fi, BLE, Zigbee, Z-Wave
- MQTT, CoAP, HTTP(S), proprietary protocols
- Pairing and provisioning flows
- Replay and downgrade resistance
- Encryption and authentication
Companion applications
Mobile apps and web portals frequently hold the credentials, tokens, and onboarding logic that an attacker needs to compromise the device.
- iOS and Android applications
- Local storage and token handling
- API communication and transport security
- Onboarding and pairing workflows
- Cryptographic implementation
Cloud and fleet management
Device identity, registration, and management platforms are increasingly where large-scale device compromise actually happens.
- Device identity and registration
- Cloud APIs and access control
- Firmware delivery and telemetry
- Tenant isolation and storage permissions
- Administrative and support interfaces
Product lifecycle
The CRA and modern product security expectations look beyond the device itself, at how vulnerabilities are handled, how updates are delivered, and how risk is managed over the product's life.
- Vulnerability disclosure and handling
- Patching and secure update process
- SBOM and third-party component risk
- Production hardening
- Factory reset and decommissioning
- Logging and auditability
Typical findings from IoT hardware assessments.
Drawn from common categories our consultants surface across engagements of this type. Severity and prevalence vary by environment and maturity.
Debug interfaces in production
Unauthenticated UART shell exposed on production devices; JTAG/SWD enabled without lock; recovery / boot modes reachable without authentication.
Firmware secrets
Hardcoded credentials, embedded private keys, API tokens, and signing material extracted from production firmware images.
Update mechanism weaknesses
OTA update packages can be modified or downgraded; devices accept unsigned firmware; rollback protection missing or bypassable.
Secure boot gaps
Secure boot disabled in shipped builds; signature verification bypassable; firmware readout protection not enabled on flash.
Wireless and protocol abuse
BLE pairing replayed or hijacked; MQTT topic permissions overly broad; proprietary radio commands accepted without authentication.
Ecosystem compromise paths
Cloud API allows horizontal access to other devices; mobile app exposes device tokens in local storage; factory reset does not remove sensitive data.
How we run the engagement.
Scope and threat model
Define the device, deployment environment, interfaces, data flows, companion services, user roles, cloud dependencies, and realistic attacker profiles.
Hardware reconnaissance
Inspect PCB, components, chips, flash storage, debug interfaces, test pads, radio modules, boot modes, external ports, and physical trust boundaries.
Firmware acquisition and analysis
Extract or obtain firmware, unpack images, inspect filesystems, review binaries, identify secrets, assess update packages, and map vulnerable components.
Interface and protocol testing
Assess local, wireless, serial, debug, cloud, mobile, and management interfaces for authentication, encryption, replay resistance, command validation, and access control.
Exploit path validation
Safely validate realistic attack paths, firmware modification, debug access, secure boot bypass, command injection, credential extraction, API abuse, privilege escalation, or device takeover, where authorised.
Evidence, reporting, and remediation
Document findings with test-case mapping, reproducible evidence, CVSS scoring, business impact, affected components, remediation guidance, and standards alignment through Velocity.
Reports built for audit, engineering, and executive review.
Every engagement produces verifiable, traceable, regulator-ready artefacts, generated by Velocity and signed cryptographically.
PDF · JSON · XML · CSV · Multi-Language Reporting Supported · CVSS 3.0 / 3.1 / 4.0
- Executive summary
- Technical findings report
- Firmware analysis summary
- Hardware interface findings
- Ecosystem (cloud / mobile) risk summary
- Standards mapping and CRA readiness observations
- Reproduction steps, screenshots, serial logs, packet captures
- CVSS scoring and CWE mapping where appropriate
- Prioritised remediation roadmap
- Retesting on remediated findings
- Optional JSON, XML, CSV exports for downstream tooling
Common buyer questions.
What is IoT Hardware Testing? +
IoT Hardware Testing is a security assessment of connected devices and their supporting ecosystem, including hardware interfaces, firmware, wireless protocols, mobile applications, cloud APIs, device management platforms, and update mechanisms.
Is this the same as application penetration testing? +
No. Application testing focuses on software such as web, mobile, and APIs. IoT Hardware Testing includes physical device review, firmware analysis, debug interface testing, protocol testing, and hardware-based attack paths, while also assessing companion applications and cloud services where relevant.
Does this provide CRA, Singapore CLS, or any other certification? +
The service provides aligned security testing, evidence, findings, and remediation guidance that can support readiness for the CRA, the CSA Singapore Cybersecurity Labelling Scheme (CLS), and similar frameworks.
How does this map to the Singapore Cybersecurity Labelling Scheme (CLS)? +
The CLS is a voluntary CSA Singapore labelling scheme for consumer IoT, with four levels of progressively stronger requirements. Levels 1 and 2 are largely a self-declaration against ETSI EN 303 645, the testing baseline already covered by our methodology. Levels 3 and 4 require independent assessment, including penetration testing of the device. Our engagements can be scoped to produce evidence aligned with the CLS level you are targeting and to support a third-party laboratory submission where required.
What devices can be tested? +
Examples include consumer IoT devices, industrial IoT devices, smart sensors, gateways, routers, appliances, healthcare devices, access control devices, payment-adjacent devices, building automation devices, wearables, and custom embedded products.
Do you need physical access to the device? +
Yes, physical access is mandatory for hardware and firmware testing, and engagements typically require multiple device samples (often 3 or more) to allow concurrent disassembly, instrumentation, and side-by-side comparison. Devices must be shipped to one of our offices (Singapore, Indonesia, or Thailand) where they are tested in a controlled lab environment.
What does firmware testing include? +
Firmware testing may include extraction, unpacking, filesystem analysis, binary analysis, credential discovery, update mechanism testing, secure boot review, vulnerable component analysis, and configuration review.
Can you test device cloud platforms and mobile apps? +
Yes. IoT security often depends on mobile applications, cloud APIs, provisioning workflows, device identity, update services, and fleet management platforms. These can be included in scope.
What standards can the assessment be mapped to? +
Depending on product type, market, and deployment environment: EU Cyber Resilience Act and ETSI EN 303 645 for European market access; CSA Singapore Cybersecurity Labelling Scheme (CLS) for consumer IoT entering Singapore; Singapore Cybersecurity Act and CCoP requirements where devices are deployed into Critical Information Infrastructure; IEC/ISA 62443 for industrial and OT deployments; EN 18031 (EU's Radio Equipment Directive) for radio equipment cybersecurity; and OWASP IoT, OWASP FSTM, and NISTIR 8259.
What do we receive at the end? +
You receive an executive summary, technical report, evidence, reproduction steps, affected components, risk scoring, standards mapping, and remediation guidance. Where supported, findings can be exported in PDF, JSON, XML, or CSV.
Test your connected products before attackers do.
Whether you are preparing for CRA readiness, targeting the CSA Singapore Cybersecurity Labelling Scheme, or testing hardware deployed into enterprise environments, Vantage Point Security Group can help identify practical exploit paths and prioritise remediation.