How to prepare for an IoT security assessment.

In this guide

Identify the product and release

Identify the hardware revisions, firmware builds and regional variants you want assessed. Record whether the product is a prototype, a release candidate or a deployed product. Differences in chipsets, boot settings, radios and backend configuration can change what a result applies to.

State the reason for the review: a release decision, a new connectivity feature, a customer assurance request or a particular security concern. An assessment of one model and firmware build should not be treated as evidence that every product variant has been tested.

Map connected services

A device can depend on a mobile application, cloud API, management portal, identity service and update infrastructure. List those components and describe how the product is provisioned, operated, updated, transferred to a new owner and retired.

• Who owns the device identity and enrolment process?
• Which services can change device configuration or issue updates?
• What can an ordinary user, administrator or support operator do?
• Which functions remain available when the device is offline?
• Which systems belong to a third party and require separate permission?

Use this map to agree which device, cloud and companion-application components will be tested.

Arrange samples and recovery

Agree the number of samples with the testing team. Supply the required power adapters, cables and accessories, and identify any device that cannot be opened, altered or reset. Spare units can matter when recovery takes time or a sample becomes unavailable.

Provide the documented factory-reset or recovery process and a known-good firmware image where available. Explain handling restrictions, specialist equipment requirements, shipping arrangements and whether samples must be returned. Any work that could damage hardware needs explicit approval.

Prepare firmware and documentation

Useful inputs include firmware images, release notes, available source code, an architecture diagram, the update process and a description of device identity and key management. Share a software bill of materials if one is maintained, but do not treat its availability as a substitute for assessing the product's behaviour.

Record what can be shared, the permitted analysis environment and retention requirements. Do not email production signing keys, customer credentials or other secrets in an initial enquiry. Establish an agreed secure channel and use test material where possible.

Arrange test access

Arrange accounts for the agreed roles, a staging backend where available, and any subscriptions or connectivity needed to operate the product. Some devices require a SIM, a regional service, a mobile account or a functioning update endpoint before meaningful testing can begin.

Provide enough instructions to enrol the device, exercise its ordinary features, update it and remove it from the account. Identify an engineering contact who can resolve setup questions and explain behaviour that is not documented.

Separate lab and live OT work

A lab-based embedded-device assessment is different from an assessment of a live industrial environment. Operational technology work must account for process safety, availability, vendor support, change windows and recovery responsibilities.

If the product is used in OT, clarify whether the scope is the product itself, a representative lab deployment or an operational site. Do not move lab test activities into a live environment without a separately agreed approach and authorisation.

Agree reporting and retesting

Findings should identify the affected device and firmware versions, the access conditions, the evidence and the recommended changes. Issues that span device and cloud components need an identified owner on each side.

Plan how corrected firmware and backend changes will be validated. Shipping replacement samples, recovering devices or waiting for a stable build can affect the retest schedule. Security testing provides evidence about an agreed scope; it does not by itself certify a product or guarantee compliance.

Your scoping checklist

1. Product: models, revisions, firmware builds and intended deployment.
2. Objective: the decision or concern the assessment should address.
3. Ecosystem: applications, APIs, identity, management and update services.
4. Setup: samples, accessories, connectivity, test accounts and recovery.
5. Boundaries: excluded components, permissions and safety constraints.
6. Delivery: release dates, report audience, remediation and retest plans.

Related services and reading

Our IoT and embedded-device security testing service describes product assessment coverage. For operational environments, see the IoT and OT overview. If the management API is a priority, use our API scoping checklist alongside the engineering brief.