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](/knowledge/glossary/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](/knowledge/glossary/mqtt/), [CoAP](/knowledge/glossary/coap/), [LWM2M](/knowledge/glossary/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](/engagement-models/retainer/) sized to the release cadence. ## Service mapping Connected-device manufacturers typically work with us across: - [IoT & Embedded Security](/services/iot-embedded-security/) — primary service - [Architecture & Cloud Review](/services/architecture-cloud-review/) — for the cloud control-plane side - [Mobile & App Security](/services/mobile-app-security/) — for companion apps - [AI/ML Security](/services/ai-ml-security/) — where the product integrates LLM-driven assistants or on-device ML ## Compliance frameworks we work within Depending on the product class and target markets, IoT manufacturer engagements operate within: - [MLPS](/knowledge/glossary/mlps/) and [CII](/knowledge/glossary/cii/) for China-market products - [PIPL](/knowledge/glossary/pipl/) and [DSL](/knowledge/glossary/dsl/) for any product that processes mainland-China personal information - UN-R 155 + [ISO/SAE 21434](/knowledge/glossary/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](/engagement-models/scoped-assessment/) engagements. Continuous engagement is typically [Retainer](/engagement-models/retainer/). Where the scope is broad enough that scoping itself becomes substantial work (multiple product lines, multiple regulatory regimes), we run [Custom Engagement](/engagement-models/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](/research/iot-supply-chain-2026/) (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](/trust/responsible-disclosure/), 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](/engagement-models/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. ### Related - [IoT & Embedded Security service](/services/iot-embedded-security/) - [Pre-Launch Product Security solution](/solutions/pre-launch-product-security/) - Companion research: [IoT Supply-Chain Vulnerabilities — Procurement Responsiveness Profile](/research/iot-supply-chain-2026/) - Companion case study: [Pre-Launch Discovery of Secure-Boot Bypass in Smart-Home Hub](/case-studies/iot-firmware-secure-boot-bypass/) - [Industries — pillar](/industries/) - [Solutions — pillar](/solutions/) - [Engagement models](/engagement-models/)