IoT / Connected Devices
Every unit you ship carries the same firmware, the same update path and often the same secrets — so one flaw is a fleet-wide flaw. We test connected products the way an attacker does: by getting one and taking it apart.
Book a ConsultationShipped once, exposed for years
A connected product is hardware, firmware, one or more radios, a companion app and a cloud back end, shipped in thousands or millions of identical units. Once it is in customers’ homes and sites, every fix depends on an update path that many devices never take — and some flaws can only be fixed in the next hardware revision.
The rules have arrived. Since 11 September 2026, the EU Cyber Resilience Act has required manufacturers to report actively exploited vulnerabilities in their products — including products already on the market — with an early warning within 24 hours. In the UK, connectable consumer products have carried legal security requirements since April 2024.
“Requires physical access” is rarely a mitigation in IoT, because an attacker can buy their own unit. A secret recovered from one device on our bench is a remote, fleet-wide finding if every unit shares it — which is why the first thing we check is whether yours do.
Three services, tuned to the product
Artificial Intelligence Security (AI-BOM)
On-device and cloud AI in connected products — voice assistants, camera analytics, and agents that can trigger device actions — and the model and data pipeline that updates them. We test what the AI can reach and control, not just what it says.
Learn more →Post-Quantum Cryptography Readiness (CBOM)
A cryptographic inventory of the device and its back end: firmware and update signing, device identity and provisioning, and the TLS links to your cloud. Post-quantum signatures are large for constrained hardware, so decisions about keys, chips and update paths belong in the next hardware revision — not after it ships.
Learn more →Product Penetration Testing
Hardware and debug interfaces, firmware extraction and analysis, secure boot and updates, the radios — Bluetooth Low Energy, Wi-Fi, Zigbee, Thread, LoRaWAN, cellular — and the companion app, provisioning and cloud APIs behind them. We compare two units early to learn which secrets are shared across the product line.
Learn more →Built for hardware, not adapted from web testing
Three units, minimum
One for non-destructive work, one for invasive work, one kept pristine as a reference. Destructive techniques — desoldering, glitching, decapping — are agreed in writing, one by one, and only where your attacker would plausibly use them.
Rated on the attacker, not the bench
Severity weighs who the attacker is, the impact, and how many units are affected. Not everything found on a bench is critical — and a flaw that needs only a device, not the victim’s, is rated as the fleet-wide risk it is.
Fixes sorted by where they live
Cloud fixes reach the whole fleet at once; firmware fixes reach only devices that update; hardware fixes never reach units already shipped. Every finding says which it is, and whether it can be fixed in the field.
The questions that matter, up front
Are secrets per-device or shared? Is secure boot enabled and complete? Are updates signed and protected against downgrade? Does the device validate your server? And what happens when the cloud service ends? The summary page answers them.
Where the rules stand, market by market
Connected products now carry legal security obligations in the EU, the UK and beyond — some already live. Current as of October 2026.
| Market | Instrument | What it means for you |
|---|---|---|
| European Union | Cyber Resilience Act — reporting (Art 14) | Since 11 September 2026: an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident, a notification within 72 hours, and a final report — each sent at the same time to the coordinating CSIRT and to ENISA. It applies to products already on the market, too. |
| European Union | Cyber Resilience Act — Reg (EU) 2024/2847, full application | From 11 December 2027: security requirements by design, vulnerability handling, and a support period of at least five years unless the product’s expected use is shorter — with its end date, at least month and year, stated at the time of purchase. Smart-home assistants, smart locks, security cameras, baby monitors, alarm systems, internet-connected toys with social interactive or location-tracking features, wearables for children or for health monitoring, and routers are Class I important products, with stricter conformity assessment. |
| European Union | Radio Equipment Directive — Delegated Reg (EU) 2022/30 | Binding since 1 August 2025: cybersecurity requirements for internet-connected radio equipment, and for radio toys, childcare equipment and wearables that process personal data, with the EN 18031 harmonised standards (cited with restrictions). Repealed from 11 December 2027 by Delegated Reg (EU) 2026/339, when the Cyber Resilience Act takes over. |
| United Kingdom | PSTI Act 2022 — product security regime | Since 29 April 2024, connectable consumer products need no universal default passwords, a published contact for reporting security issues, and a published minimum security-update period with an end date that cannot later be shortened, backed by a statement of compliance. |
| United States | U.S. Cyber Trust Mark (FCC) | A voluntary labelling programme. Its first lead administrator withdrew in December 2025; ioXt Alliance was named in April 2026, and labels are not yet being issued. |
| United States (California) | SB-327 — Civil Code §1798.91.04 | Since 1 January 2020, manufacturers of connected devices sold in California must equip them with reasonable security features. Where a device can be logged into from outside the local network, a password unique to each device, or a credential the user must set before first access, is deemed reasonable. |
| Baselines | ETSI EN 303 645 (2024) NIST IR 8259 Rev. 1 (2026) OWASP ISTG | The European consumer IoT baseline (a voluntary European Standard), NIST’s foundational activities for IoT manufacturers (guidance, revised April 2026, superseding the 2020 edition), and the OWASP IoT Security Testing Guide (community guidance) we structure device testing around. |
| Post-quantum | No IoT-specific requirement | Standards for constrained devices are arriving — ML-DSA for COSE (RFC 9964, an IETF Standards Track RFC, May 2026) and stateful hash-based signatures for firmware signing (NIST SP 800-208, final, October 2020). There is no IoT deadline; the general timelines on our PQC page are the reference points. |
What you get
- Findings report — the key questions answered on the summary page, and every finding pinned to the hardware revision and firmware version tested, with attacker class and, for radio, range
- Remediation by delivery route — cloud, firmware or hardware revision, with field-fixable findings flagged
- Critical findings in writing, on the day — delivered through a channel agreed at scoping and timestamped, so you know exactly when you learned of an actively exploited flaw (we flag reporting triggers; we do not file on your behalf or give legal advice)
- Upstream register — flaws in shared modules, chipsets and SDKs, with coordinated disclosure agreed
- Cryptographic and AI bills of materials — device and back-end cryptography, and the AI behind your product, in CycloneDX format
- Retest of fixes — evidence that remediation landed, for your release gates and your conformity file
Find the fleet-wide flaw before someone else buys a unit.
A connected-device engagement starts with your product, how it updates, and the markets you sell into.
Get in Touch