IoT and embedded-device security testing.
Security testing across device hardware, firmware, companion applications and cloud services, with scope agreed for each product and release.
- Scope
- Device, firmware & connected services
- Environment
- Agreed lab or staging setup
- Audience
- Manufacturers and product teams
Connected-product testing coverage.
- Firmware & configurationFirmware, exposed services, configuration, third-party components, known vulnerabilities and sensitive data. Runtime testing uses the agreed lab setup.
- Local interfacesPhysical and maintenance interfaces, diagnostic access and the separation between normal operation and privileged device functions. Opening or altering hardware requires explicit agreement.
- Identity & provisioningDevice enrolment, unique identities, ownership transfer, pairing, credential lifecycle and decommissioning. These controls need to work across the device and its supporting services.
- Boot & updatesBoot integrity, firmware authenticity, update distribution, signing arrangements and rollback controls. Documented recovery paths are agreed before tests that could affect device availability.
- Companion & cloud servicesThe mobile apps, portals, APIs and messaging systems that manage the product. These components must be named in scope; a hardware assessment does not automatically include the whole cloud platform.
- Wireless boundariesPairing, access and transport assumptions for the supported radio interfaces. Permitted protocols, equipment, locations and interference constraints are agreed before any radio testing.
What to prepare.
- Devices & recoveryAgree the number of samples, hardware revisions, power supplies, accessories and spare units. Provide a reset or recovery procedure and identify any sample that cannot be modified.
- Firmware & designIdentify the release to assess and supply available firmware, architecture diagrams and update-flow documentation through an agreed secure channel. Source-assisted review can be included where useful.
- Connected environmentProvide test accounts, device-management access and a staging backend where available. Note subscriptions, SIMs, regional dependencies and external services needed for normal operation.
- Constraints & ownershipList third-party components and permissions, handling and return requirements, safety limits and excluded work. Certification, destructive hardware analysis and live OT testing are not implied by a product assessment.
Use our IoT assessment preparation guide to assemble the engineering brief.
Findings and recommended fixes.
Findings identify affected hardware and firmware versions, required access, evidence and recommended fixes. The report records coverage limits and identifies which device, backend or application teams need to act.
- Engineering prioritiesPrioritised findings and a walkthrough with your product team, including release constraints and remaining risks.
- Retest planningAgree the corrected firmware, replacement samples, backend changes and retest window. A later hardware revision or substantially different release may require a fresh assessment.
- Timing & costThe number of variants, available documentation, recovery arrangements and connected components determine effort. Shipping, lab setup and release readiness affect the schedule as well as testing time.
Embedded-device testing questions.
Is this the same as an OT security assessment?
No. This service is focused on a product and its supporting ecosystem. An OT assessment concerns an operational environment, where safety, availability and change control govern the work. See our IoT and OT overview for operational assessment coverage.
Do you need physical devices and source code?
Physical samples are needed where hardware, local interfaces or real device behaviour are in scope. Firmware review can be scoped separately. Source access is useful for some questions but is not assumed to be available.
Will the assessment certify our product?
No. Testing can inform engineering work and provide evidence against agreed requirements, but it is not a product certification or a guarantee of compliance. Any formal conformity programme needs its own process.
Can you assess a product before release?
Yes, provided there is a stable, representative build and an agreed test environment. Record what differs from the planned production release, and allow for validation after the relevant fixes or design changes.
Discuss the scope and timing.
Tell us what needs testing and when. Keep credentials, source code and customer data out of the initial enquiry; we will arrange a secure exchange if needed.