For IoT security
consultancies

A platform built for the firms that test connected devices end to end

Security consultancies that focus on connected devices carry a different operating burden than firms that test general SaaS or enterprise web. Every engagement crosses the silicon (the SoC, the secure element, the radio module, the debug interfaces), the firmware on the device, the radio protocols the device speaks, the mobile companion application that configures and pairs the device, and the cloud backend that supports the fleet. The deliverables sit alongside certification submissions (ISASecure, IoTSF Compliance Framework, ETSI EN 303 645 self-assessment, the Cyber Resilience Act conformity track), firmware build pipeline gates, and the security verification record the device product team already runs. The report has to map findings back to IEC 62443 component requirements, the matching OWASP IoT Top 10 category, and (for the cloud backend that supports the fleet) OWASP ASVS. The evidence chain has to survive a new firmware image the client ships without a missing link. Most IoT testing shops still run this delivery on a notes app, a screenshot folder, a hardware lab-bench photograph archive, and a spreadsheet that loses context the moment the engagement closes and the next firmware build version increments.

SecPortal gives IoT security consultancies one workspace for engagements, findings, evidence, retests, branded delivery, and invoicing. Findings carry CVSS scores from the moment they are opened, IEC 62443 and OWASP IoT tagging is part of the workflow, the client portal scopes secure-boot bypass material and firmware extraction artefacts behind authenticated access, and the AI-assisted reporting drafts the framework-aligned writeup the manufacturer is expecting. Whether the firm services a consumer device studio, a smart-home platform vendor, an industrial IoT manufacturer subject to IEC 62443 certification, a connected medical device maker under FDA premarket cybersecurity guidance, or an automotive supplier that ships connected ECUs, the platform scales without adding administrative overhead.

Capabilities IoT security consultancies actually use

How an IoT security practice runs inside SecPortal

IoT security delivery is most defensible when one operating picture covers scope, evidence, finding-to-framework mapping, retest verification across firmware versions and hardware revisions, and the report. SecPortal supports the full delivery rather than a single phase of it.

From engagement kickoff to verified close, on one record

The leverage in IoT security delivery is the durability of the audit chain across firmware version changes, hardware revisions, and backend releases. SecPortal runs a single delivery flow that the next release, the next retest, and the next certification review can build against without reconstructing context from a lab-bench photograph archive.

1. 1Open the IoT pentest engagement with assessed manufacturer entity, in-scope device models and hardware revisions, firmware versions and image hashes under test, radio protocols covered, companion app identifiers, cloud backend endpoints in scope, lab-bench rules of engagement (invasive hardware testing, glitching, decapping, supply-chain test fixtures), testers, and dates stamped against the record. The rules-of-engagement template populates the standard sections; the engagement record holds the bespoke IoT context.
2. 2Run the IoT testing programme inside the engagement record. Hardware-side activity (UART discovery, JTAG and SWD reactivation, secure boot bypass attempts, fault injection, key extraction), firmware-side activity (image extraction, binwalk and unblob analysis, decompilation, hardcoded credential search, update mechanism review), radio-side activity (capture, replay, fuzzing, downgrade and pairing weakness analysis), companion app activity, and cloud backend activity all consolidate to the same findings database, with raw outputs attached to the finding they support.
3. 3Tag each finding against the IEC 62443-4-2 component requirement, the OWASP IoT Top 10 category, and the matching ETSI EN 303 645 provision (or the relevant Cyber Resilience Act requirement) as it is logged. The tagging is part of the testing workflow, not a post-engagement reconciliation step.
4. 4Generate the technical report, executive summary, and remediation roadmap with AI assistance from the live record. The deliverable lands in the client portal alongside the underlying finding-level evidence (binwalk extract, decompiled snippet, UART or JTAG capture, radio recording, request and response, photograph of the lab bench setup), so the report and the source-of-truth point at the same data.
5. 5Run retests after the client ships the next firmware image, lifts the SoC family, tightens the secure boot configuration, ships a new hardware revision, or releases a new cloud backend version. Attach verification evidence to the same finding, record the firmware image hash, hardware revision, and backend release identifier that cleared the issue, and either close the issue with a status change actor recorded automatically or revert to open with regression notes captured in place. The audit chain stays intact for certification activities and for the next external assessment.

IoT-specific finding classes the platform is built to handle

IoT engagements surface a class of findings that frequently cross the silicon, the firmware, the radio, the companion app, and the cloud backend at the same time. The encyclopedia entries below cover the most common adversarial cases, with reproducibility evidence and remediation guidance the manufacturer team can act on. Each one can be tagged into a SecPortal engagement and tracked through the same workflow as a traditional pentest finding.

• Hardcoded device credentials, factory-default service accounts, and signing material baked into a firmware image fall under the hardcoded secrets entry and the default credentials entry.
• Insecure data transfer over BLE, weak certificate validation on the device-to-cloud TLS channel, and downgraded cipher suites on local management protocols fall under the TLS and SSL misconfiguration entry, while custom radio cryptographic flaws, weak pairing schemes, and rolled-from-scratch ciphers on resource-constrained devices are tracked under the weak cryptography entry.
• Insecure data storage in writable flash partitions, exposed file systems, and configuration logs that leak secrets are tracked under the sensitive data exposure entry.
• Cloud backend authorisation gaps that the device or companion app exposes (per-device record access, tenant scoping, vertical privilege escalation between owner and installer roles) sit under the broken access control entry and the broken object level authorization entry.
• Authentication bypass on local device management interfaces and bearer-token weaknesses on cloud APIs sit under the authentication bypass entry and the JWT vulnerabilities entry.
• Vulnerable open-source components carried by the firmware (BusyBox, OpenSSL, lwIP, Mbed TLS, Linux kernel modules, vendor SDK forks) and stale third-party libraries on the cloud backend are tracked under the vulnerable dependencies entry.
• Server-side request forgery against backend services accessible through device-to-cloud APIs is tracked under the server-side request forgery entry, and command injection through device shell endpoints, debug interfaces, or update handlers is captured by the command injection entry.

Where IoT security consultancies typically start

Most IoT-focused firms adopt the platform in three phases: bring the active manufacturer list and engagement records under one workspace, layer in finding-to-framework tagging and branded portal delivery, then consolidate retests, AI-assisted reporting, and invoicing onto the same record. The relevant capability and workflow pages explain each phase in detail.

• The core engagement and findings workflow lives in the penetration testing use case, and the cloud backend that supports every connected device leans on the API security testing use case for authenticated DAST coverage.
• The finding-tagging model that produces framework-aligned reports sits in the findings management feature, with multi-framework mapping covered by the compliance tracking feature. Branded delivery scoped per manufacturer client lives in the client portal feature, and the AI-drafted writeup produced from the live record sits in the AI reports feature.
• Coverage of the cloud backend that supports the device fleet relies on the authenticated scanning feature for the API endpoints behind device pairing and provisioning, and on the code scanning feature for the firmware repository (drivers, vendor SDK forks, bootloader, application partition) and the surrounding cloud backend repositories.
• The retest workflow that pairs verification to the original finding across firmware versions and hardware revisions is covered in the retesting use case, the report-delivery pattern that fits a manufacturer buyer is documented in the pentest report delivery use case, and remediation cadence between formal assessments lives in the remediation tracking use case.
• Methodology references the report can build on sit in the IEC 62443 framework page for industrial IoT engagements, the Cyber Resilience Act framework page for connected products entering the EU market, the NIST SP 800-115 framework page for the testing methodology base layer most engagements still build on, and the MITRE ATT&CK framework page (including ATT&CK for ICS where the device sits inside an industrial control system environment). The companion IoT penetration testing guide covers the practical scoping, hardware, firmware, radio, mobile, and cloud testing steps the firm walks through on each engagement.

SecPortal is built for IoT security consultancies that want one platform for the whole delivery: live engagements, framework-tagged findings, evidence, retests, branded portals, AI-assisted reporting, and invoicing. Manufacturer clients get a deliverable that ties to the IEC 62443 component requirements their certification track already references and to the firmware version their release engineering team is shipping, and the firm gets back the hours that used to disappear into post-engagement document production and capture-by-capture reconciliation across notebooks, lab-bench photograph archives, and chat transcripts.

If your firm is structured as a smaller partner-led practice between two and ten testers, the SecPortal for boutique security firms page covers the operating model that fits a specialist consultancy. If your firm runs a broader multi-vertical book of business, the SecPortal for cybersecurity firms page covers the multi-client delivery model. If your firm specialises in operational technology and industrial control system work, where active scanning is constrained and change windows cross plant maintenance schedules, the SecPortal for OT and ICS security consultancies page covers the IEC 62443 and NIST SP 800-82 assessment model that sits next to consumer and commercial IoT work. Firms that pair connected device work with mobile companion app review can read the SecPortal for mobile security consultancies page for the OWASP MASVS aligned delivery model, and firms that pair connected device work with AI and ML adversarial review (on-device models, edge inference, federated learning endpoints) can read the SecPortal for AI and ML security consultancies page for the technology specialism that overlaps when a connected device embeds an on-device model.

For broader context on how device findings hold up after the engagement closes, the aging pentest findings research and the severity calibration research cover what happens after the report ships and the manufacturer starts shipping new firmware images, new hardware revisions, and new backend releases the original findings need to be re-evaluated against.