IoT, embedded & OT security testing.
We test the path between firmware, interfaces, cloud services, identity, update infrastructure, and operational environments. OT work is non-disruptive by default and planned around explicit safety constraints.
- Scope
- Firmware, ecosystem & OT
- Deliverables
- Engineering and operations findings
- Approach
- Non-disruptive OT by default
Our team includes a contributor to the original GSMA IoT Security Guidelines ↗.
- Device & firmwareFirmware and configuration, local interfaces, exposed services, device identity, secure boot, secrets, integrity controls, and controlled runtime validation.
- Connected ecosystemDevice-to-cloud APIs and messaging, companion mobile apps, web portals, service trust boundaries, tenancy, provisioning, and business-logic abuse.
- Wireless & radioWi-Fi, BLE, Zigbee, Thread, pairing, credential exchange, device discovery, transport security, and segmentation assumptions.
- OT / ICSAsset visibility, segmentation, remote and vendor access, engineering workstations, historian and management paths, gateway risk, monitoring, backup, and recovery.
- Build & updateFirmware build and signing, key management, software bills of materials (SBOMs), third-party components, CI/CD integrity, release controls, rollback protection, and update distribution.
Production-safe by default.
- Live environmentsSigned Rules of Engagement, named change windows, escalation paths, and clear stop conditions. Destructive activity requires explicit authorisation.
- Firmware & sourceSensitive artefacts stay within agreed client, local, or isolated lab environments. Public AI services are not used without explicit approval.
- AI-assisted triageLocal or private tools can help triage firmware extracts, dependencies, and unfamiliar protocols. Operators reproduce every reportable issue and decide exploitability, severity, and what is safe to attempt.
- EvidenceCross-component attack paths are documented explicitly, with verification steps and practical remediation for engineering and operations teams.
Separate the product from the operational environment.
- Product assessmentFor manufacturers and engineering teams, scope the hardware revisions, firmware, device identity and connected services. Our IoT and embedded-device testing service describes this lab-focused work in detail.
- Operational assessmentFor OT owners, begin with the process, asset inventory, network zones, remote access and operational constraints. Agree with operations and relevant vendors which reviews and validation activities are permitted.
- Safety and accessIdentify systems that cannot be interrupted, change windows, recovery responsibilities and stop conditions. Product samples and lab devices are not permission to test a live plant or third-party infrastructure.
- Time and deliverablesDevice variants, sites, documentation, lab setup and access determine effort. Findings are assigned to engineering or operations owners, with evidence, remediation priorities and agreed retest arrangements.
Can the work be performed without active testing on live OT?
The scope can prioritise documentation, architecture, configuration and access-path review, with validation in an agreed lab where available. The permitted activities and remaining evidence gaps are documented rather than implying that untested controls have been verified.
Does testing certify a product or an industrial system?
No. An assessment can provide evidence against agreed requirements, but it is not certification under IEC 62443 or any other standard. Formal certification and conformity programmes have their own requirements and processes.
Share the architecture and constraints.
Send the device models or firmware versions, connected cloud and mobile components, OT boundaries, and any change-window or safety constraints.