Skip to content
Melina Security

Security for IoT and Connected-Device Manufacturers

Pre-launch and post-launch security assessment for consumer, industrial, and infrastructure IoT manufacturers.

By Melina Editorial

Connected-device manufacturers ship products that, once in the field, are difficult to update, expensive to recall, and visible to security researchers worldwide. The cost of a security finding rises sharply between the prototype lab and the warehouse — and rises again between the warehouse and the field.

We work with IoT manufacturers across three points in the product lifecycle: pre-launch assessment before mass production, post-launch assessment for products already in the field, and continuous engagement as the platform evolves.

Where Melina engages on connected-device security

Pre-launch assessment

The assessment scope for a pre-launch engagement is shaped by what is still changeable in the design. We focus on:

  • Hardware attack surface — debug interfaces, secure-element integration, the secure-boot chain, anti-tamper mechanisms, fault-injection resistance for the platforms where it matters (payments, automotive, critical infrastructure)
  • Firmware integrity and update path — signing, anti-rollback, delta-update integrity, key-revocation mechanisms
  • Communication protocol attack surface — MQTT, CoAP, LWM2M, and BLE/Wi-Fi/Zigbee/Thread layers as deployed; TLS posture and certificate handling
  • Cloud control-plane attack surface — device provisioning APIs, fleet-management endpoints, multi-tenant isolation, telemetry-data confidentiality
  • Companion mobile applications — device-pairing protocol analysis, BLE/Wi-Fi handoff, local-network discovery and command flows

The output of a pre-launch engagement is a remediation plan that the engineering team can execute before the production run, plus the artifacts needed for any compliance or certification frame the product will enter (UN-R 155, ISO/SAE 21434, MLPS, regional radio-equipment certifications).

Post-launch assessment

Post-launch engagements work against products already in the field. The assessment scope is shaped by what is actually deployable as a remediation:

  • Findings that require silicon changes or boot-ROM changes are reported with workaround paths (compensating controls, fleet-side detection) because the firmware fix path is not available
  • Findings exploitable through the OTA channel are prioritized — those are the ones the manufacturer can ship a fix for
  • Findings discovered by external researchers and already disclosed are correlated with our findings to avoid duplicate work and to give the manufacturer a single coordinated view

Post-launch engagements often run alongside an active responsible-disclosure program. We coordinate scope-and-finding handoff between our work and the disclosure pipeline.

Continuous engagement

For manufacturers operating a connected platform with regular feature releases — a steady cadence of firmware updates, new cloud APIs, new mobile-app features — point-in-time assessment misses the changes that arrive between engagements. We support continuous engagement through a retainer model sized to the release cadence.

Service mapping

Connected-device manufacturers typically work with us across:

Compliance frameworks we work within

Depending on the product class and target markets, IoT manufacturer engagements operate within:

  • MLPS and CII for China-market products
  • PIPL and DSL for any product that processes mainland-China personal information
  • UN-R 155 + ISO/SAE 21434 for automotive-class IoT
  • IEC 62443 for industrial connected devices
  • ETSI EN 303 645 for consumer IoT in EU markets
  • The EU Cyber Resilience Act (CRA) for products entering the European single market post-2027

Engagement model

Pre-launch and post-launch assessments are typically Scoped Assessment engagements. Continuous engagement is typically Retainer. Where the scope is broad enough that scoping itself becomes substantial work (multiple product lines, multiple regulatory regimes), we run Custom Engagement framing.

What buyers ask us first

Three questions surface in nearly every initial conversation with a connected-device manufacturer:

“When is the right time to engage — before tape-out, before mass production, or after launch?” The leverage curve is sharply non-linear. Pre-tape-out assessment can change silicon decisions; pre-mass-production assessment can change firmware and supply chain; post-launch assessment can only change what’s OTA-updatable. Most cost-effective: pre-mass-production, when the engineering team can still ship remediation through normal release channels. Most leverage: pre-tape-out for products that ship millions of units.

“How does supply-chain risk fit into a pre-launch assessment?” Component-level CVE exposure is a procurement question, not a firmware-engineering question — which is why we use the Procurement Responsiveness Profile (a three-dimension framework: Disclosure Cadence, Time-to-Fix, Coverage Breadth) as a complementary input to the technical assessment. Healthy procurement choices reduce inherited risk before any firmware work begins.

“Will you coordinate with our silicon vendor on findings that affect their reference implementation?” Yes, where the manufacturer authorizes it. Findings at the silicon-reference layer (boot-ROM behaviour, secure-element integration patterns, vendor-supplied SDK code paths) are most cleanly resolved when the silicon vendor’s PSIRT is part of the disclosure conversation. We coordinate that pathway under the manufacturer’s authority and reporting frame.

“Most IoT manufacturers we work with discover that their highest-leverage security work is not new firmware code — it’s procurement discipline at component selection and end-of-line verification at manufacturing. Both happen outside the firmware team’s normal scope, which is exactly why they go unaddressed.” — Tatiana K., CEO, Melina Security

Frequently asked questions

Do you work with hardware we’ve already shipped, or only pre-launch designs?

Both. Post-launch engagements often produce more actionable findings — the field-deployment context tells us what attackers are actually targeting and what remediation paths are actually available.

Will you sign manufacturer-specific compliance attestation documents?

We provide assessment reports and remediation guidance. Compliance attestation documents that require a credentialed-assessor signature (e.g., MLPS-graded assessor attestation in China) are issued by the licensed assessor in that regulatory frame — we coordinate with that assessor to provide technical findings as input.

How do you handle vulnerability disclosure if we have not yet shipped a fix?

Per our Responsible Disclosure policy, we coordinate with the affected manufacturer through a 90-day default window with extensions available where the engineering reality requires more time. The disclosure timeline is set in collaboration, not unilaterally.

Can a single assessment cover hardware, firmware, cloud, and mobile companion app together?

Yes, but it scales as a Custom Engagement rather than a single Scoped Assessment. The integration surfaces (BLE pairing, OTA delivery, cloud-to-device control flows) are often where the most consequential findings live, so cross-surface scope is genuinely valuable when budget supports it. Single-surface scope is acceptable when one surface dominates the threat model.

What’s the realistic minimum schedule for a meaningful pre-launch assessment?

Three weeks for a single product line with narrow scope (e.g., hardware-only or firmware-only) and an engineering team prepared to support testing access. Six to ten weeks for a typical pre-launch sweep covering hardware, firmware, cloud control plane, and mobile companion app. Compressed schedules are workable but produce narrower coverage; we surface that trade-off explicitly at scoping rather than discovering it at reporting.

Services we run for IoT and Connected-Device Manufacturers

Outcomes we package for this sector

Related case studies