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.
// What we test
- 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, SBOM and dependency posture, CI/CD integrity, release controls, rollback protection, and update distribution.
// Safety and method
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.
// Delivery
01Discover & scopeDevices, firmware, cloud, sites, change windows, and safety constraints.
02Threat-led planPrioritised paths across the product ecosystem and operational environment.
03Test & validateFirmware and code review, lab or staging where possible, non-disruptive in OT.
04Report & clinicEngineering and operations findings, verification steps, and a working session.
05Retest & closeUsually within 60–90 days, aligned to release or maintenance windows.
Relevant standards
IEC 62443/
ETSI EN 303 645/
NISTIR 8259/
NIST SP 800-82/
OWASP IoT
- GSMA guideline authorship A Neonix principal consultant helped write the original GSMA IoT Security Guidelines for Endpoint Ecosystems — practical guidance for manufacturers and engineers building connected devices and services.
// Next step
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.