Overview
US device makers and the hospitals, retailers and plants that deploy their products face the same question from buyers: what happens when someone holds the hardware? You ship us sample units, and we test firmware, interfaces, pairing and the backend in one engagement. The report separates single-unit issues from flaws that affect every device in the field, which is what procurement and product teams need to know.
An IoT product is a full system scattered across a device, its radios, a mobile or web application, and a cloud backend, and an attacker can start from whichever is weakest. We test the whole picture, beginning with the device itself, because an adversary who holds the hardware can probe it in ways no network attacker can, and because flaws found there often affect every unit you have shipped.
On the hardware we look for exposed debug and serial interfaces, accessible storage, and the chance to read or modify firmware directly. Extracted firmware is analyzed for hard-coded credentials, keys and certificates, insecure update mechanisms, and vulnerable components. We then test the radios and protocols the device speaks, how it pairs and authenticates, and whether its traffic can be intercepted or spoofed, before carrying the assessment through to the companion application and the cloud APIs that the device trusts.
The findings are framed by what an attacker gains and how widely it applies. A key extracted from one device that unlocks the fleet is a very different problem from a local-only weakness, and we make that distinction clear. Each issue is scored with CVSS v4.0 and paired with a fix at the right layer, secure boot and storage, signed updates, stronger protocol authentication, or backend changes, so your hardware and platform teams each know their part.
How US engagements run
- Delivered remotely from India, 9.5 hours ahead of US Eastern in US daylight time and 10.5 hours in winter; calls and testing windows are set around your time zone at scoping
- Fixed-price proposals in US dollars, with scope, dates and the free retest written in before any work begins
- Written authorization signed by someone with authority over every target, because the federal Computer Fraud and Abuse Act and state laws make permission the dividing line
- Reports that name the requirement a test supports, such as PCI DSS 11.4, the FTC Safeguards Rule or SOC 2, without claiming a QSA, ASV or C3PAO role we don't hold
What's included
Our approach
- Device intakeWe take sample units, documentation and any companion app and credentials.
- Hardware analysisWe examine interfaces and attempt to access storage and firmware.
- Firmware reviewExtracted firmware is analyzed for secrets, update flaws and components.
- Protocol & cloudWe test radios, protocols, the companion app and the backend APIs.
- Report & debriefFindings are framed by fleet impact, scored and explained by layer.
What you receive
- Findings across hardware, firmware, protocol and cloud
- Firmware analysis with extracted secrets where present
- Assessment of fleet-wide versus local-only impact
- CVSS v4.0 scores and layer-specific remediation
- Free retest of fixed issues and an attestation letter
Standards & frameworks
- OWASP IoT Top 10
- PTES
- NIST SP 800-115
- OWASP MASVS
- OWASP API Security Top 10
- CVSS v4.0
- PCI DSS v4.0.1 Req. 11.4
- NIST SP 800-171
Frequently asked questions
How many devices do you need?
Usually two or three identical units. Hardware testing can alter or damage a device, so we need spares to continue after invasive work, and having more than one lets us compare behavior and confirm that a finding applies across the product, not just one sample.
Do you keep or destroy our devices afterwards?
We return or securely destroy them as you prefer, and we never retain extracted firmware or secrets beyond the engagement. Devices we have opened or modified are clearly marked so they are not mistaken for production stock.
Is the cloud backend included?
The backend a device trusts is central to its security, so companion-app and cloud-API testing are part of a meaningful IoT engagement. A very large, unrelated platform may be scoped separately as an API test, which we confirm with you up front.
Does an internal and external test cover PCI DSS Requirement 11.4?
It can, when scoped for it. PCI DSS v4.0.1 wants penetration tests from inside and outside the network every year and after significant changes, following a documented methodology, plus proof that segmentation holds. We aren't a QSA or ASV, so quarterly ASV scans and the assessment itself stay with those firms.
Can you test our US networks without traveling?
Network, Active Directory, cloud and Kubernetes testing run remotely through a VPN account, jump host or small test device you place on the network. Wireless and hardware work need someone near the equipment; tell us the sites at scoping and we'll say plainly whether and how we can cover them.