**Offensive-security testing for IoT devices, firmware, and connected-device ecosystems** Hardware teardown to device-to-cloud. We assess connected devices the way an adversary would — exploit-validated, not checklist-driven. Bilingual EN + 中文 reporting; 60-day remediation re-check on Standard+ engagements. [Request Assessment →](/contact/request-assessment/?service=iot-embedded-security) > "The most leveraged work in connected-device security is not the firmware code review or the cloud penetration test — it's the procurement decision and the end-of-line verification step. Both happen outside the firmware team's normal scope, which is exactly why they go unaddressed. Our assessments find that gap roughly half the time, and remediation produces compounding lifetime returns that no single security control matches." — Tatiana K., CEO, Melina Security --- ## Who this is for - **IoT and connected-device manufacturers** — consumer, industrial, medical, smart-home, or smart-city deployments - **Embedded teams** shipping products into regulated markets where security findings affect certification (MLPS, ISO 27001, ETSI EN 303 645, FCC, CE, FedRAMP) - **Security architects** evaluating device-to-cloud architecture before launch, mid-lifecycle, or before a market expansion - **Compliance leads** preparing for ISO 27001 readiness, SOC 2 Type 2, MLPS Level 2 / Level 3, or industry-specific frameworks (UN-R 155 / 156, IEC 62443) - **Procurement and risk teams** validating third-party connected devices before deployment If you ship anything that connects, has firmware, and reaches end-users, this is the assessment that surfaces the failure modes shipping has hidden. --- ## What we cover End-to-end across the connected-device stack. Engagement scope is set during [discovery and scoping](/methodology/scoping/); typical assessments include multiple of the following: ### Hardware - Silicon-level teardown and component identification (datasheet enumeration, debug-interface discovery) - Side-channel power analysis (key recovery, secure-boot bypass evaluation) - Voltage and clock glitching (fault injection to bypass secure-boot or recover sensitive data) - Chip-off firmware extraction (SPI flash, eMMC, NAND flash desolder + hardware programmer) - JTAG / SWD / UART discovery and exploitation (pad probing, voltage matching, baud-rate discovery) ### Firmware - Firmware extraction from on-device interfaces, OTA-update interception, or supply-chain BoM sources - Firmware reverse engineering (Ghidra / IDA / Binary Ninja workflows; bootloader, kernel, application-layer analysis) - Cryptographic implementation review (custom crypto, weak entropy sources, key reuse, hardcoded keys) - Secure-boot chain analysis (root of trust, signature validation, anti-rollback) - Privilege boundary analysis (kernel modules, SELinux / AppArmor policy, sandbox escapes) - Binary diffing across firmware versions (regression hunting, undocumented feature discovery) ### Wireless protocols - BLE (GATT enumeration, pairing analysis, MITM evaluation, link-layer fuzzing) - Wi-Fi (WPA2/WPA3 setup, captive-portal analysis, EAP attacks where applicable) - Zigbee, Z-Wave, Thread (mesh-network security, key-exchange weakness) - LoRaWAN (join procedure, frame counter handling, multicast security) - Custom 2.4 GHz and sub-GHz radios (SDR-based capture, protocol reverse engineering) - Cellular modems (AT-command auditing, IMSI catcher behavior, modem firmware exposure) ### Device-to-cloud ecosystem - Backend API security (authentication, authorization, rate limiting, injection) - Device provisioning and identity (X.509 lifecycle, JWT issuance, certificate rotation) - MQTT, CoAP, AMQP, custom IoT protocol implementations - Cloud architecture review (AWS IoT, Azure IoT Hub, Aliyun IoT, Tencent Cloud IoT) - Multi-tenant isolation (cross-tenant data leakage, privilege escalation in shared infrastructure) ### Mobile companion app - iOS and Android companion-app penetration testing (OWASP MASVS aligned) - SDK security (third-party device SDKs embedded in customer apps) - Local-mode versus cloud-mode separation - BLE and Wi-Fi setup-flow security (provisioning attacks) - Companion-app reverse engineering (frida, jadx, class-dump workflows) ### Lifecycle - Over-the-air update integrity (signature verification, downgrade attacks, supply-chain compromise) - Factory reset behavior (data remanence, key destruction effectiveness) - Decommissioning (revocation flows, end-of-life security, secondhand-device threat model) --- ## How we approach this We work through Melina's six-step methodology — confirmed at the start of every engagement, transparent to the buyer, documented in deliverable artifacts. 1. **[Discovery Call](/methodology/discovery/)** — understand your system, threat model, and goals. 2. **[Scoping & Proposal](/methodology/scoping/)** — concrete in/out-of-scope list, rules of engagement, timeline. 3. **[Threat Modeling](/methodology/threat-modeling/)** — STRIDE / PASTA / LINDDUN as appropriate for the system class. 4. **[Testing & Exploitation](/methodology/testing/)** — exploit-validated findings, not theoretical vulnerabilities. 5. **[Reporting](/methodology/reporting/)** — bilingual EN+ZH with executive summary, technical findings, and remediation guidance. 6. **[Remediation Re-check](/methodology/re-check/)** — 60-day verification window included on Standard+ engagements. For day-by-day detail including sample evidence package, NDA flow, and how engagements close, see **[Inside a Melina Engagement](/methodology/inside-an-engagement/)**. --- ## Deliverables Every IoT engagement produces, at minimum: - **Bilingual EN+ZH report** — executive summary (3–5 pages, suitable for a non-technical product owner or board) + full technical findings - **Per-finding artifacts** — reproduction steps, evidence files (screenshots, packet captures, code), CVSS rating, exploit complexity rating, time-to-fix estimate - **Remediation guidance** — concrete code, configuration, or architectural changes; ordered by impact - **60-day re-check** — formal verification that remediations work, included on Standard+ engagements per [locked default §6](/about/company/#architecture-decisions) - **Optional knowledge-transfer workshop** — 2-hour synchronous deep-dive with your engineering team - **Optional CVE coordination** — for findings that meet public-disclosure threshold, Melina manages responsible-disclosure timing with the vendor per our [Responsible Disclosure](/trust/responsible-disclosure/) policy --- ## For security firms reselling this capability Security firms, MSSPs, and licensed assessment organizations can engage Melina at wholesale through the [Partnership program](/partnerships/) — White-Label Delivery, Named Specialist, or Preferred Partner. See [/partnerships/](/partnerships/) for models and wholesale day rates. --- ## Selected research Research authored by Melina's team on IoT and adjacent topics: - [IoT Supply-Chain Vulnerabilities — Methodology and Procurement Guidance](/research/iot-supply-chain-2026/) — Tatiana K. - [TARA Quality Anti-Patterns — Observations from Automotive Cybersecurity Practice](/research/tara-quality-patterns/) — Tatiana K. - See [Research](/research/) for the full set. --- ## Related services, industries, and solutions **Related Melina services:** - [Automotive Security (ISO/SAE 21434)](/services/automotive-security/) - [Robotics & Autonomous Systems Security](/services/robotics-security/) - [Architecture & Cloud Review](/services/architecture-cloud-review/) (for the cloud side of device-to-cloud ecosystems) **Industries we serve in IoT:** - [Connected Device Manufacturers](/industries/iot-manufacturers/) - [Industrial IoT](/industries/industrial-iot/) (P1.5) - [Medical IoT](/industries/medical-iot/) (P1.5) **Solutions where this service applies:** - [ISO 27001 & SOC 2 Readiness](/solutions/iso-27001-soc2-readiness/) (P1.5) - [MLPS Readiness](/solutions/mlps-readiness/) - [Pre-Launch Product Security](/solutions/pre-launch-product-security/) (P1.5) - [Supply-Chain Security](/solutions/supply-chain-security/) (P1.5) --- ## What buyers ask us first Three questions surface in nearly every initial discovery call with a connected-device team: **"When in the product timeline is the engagement most valuable?"** Pre-mass-production is the leverage sweet spot. The engineering team can still ship remediation through normal release channels, the silicon decisions are mostly locked but the firmware is iterating, and there's enough working code to assess substantively. Pre-tape-out engagement provides higher leverage for products shipping millions of units. Post-launch engagement is the latest the cost curve still favors — see the [Pre-Launch Discovery of Secure-Boot Bypass case study](/case-studies/iot-firmware-secure-boot-bypass/) for the dynamics. **"How does the assessment coordinate with our silicon vendor?"** Findings at the silicon-reference layer (boot-ROM behaviour, secure-element integration, vendor 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. The [Procurement Responsiveness Profile](/research/iot-supply-chain-2026/) framework structures the procurement-side evaluation of vendor responsiveness; the assessment work uses the same lens at engagement time. **"Can you assess pre-tape-out silicon under NDA?"** Yes. Pre-tape-out engagements require tighter NDA framing and typically a longer scoping window, but they are the highest-leverage point in the connected-product lifecycle — silicon-level findings at this stage cost a fuse swap, not a chip respin. ## Frequently asked questions *(Rendered as visible Q&A blocks on the page; matching `FAQPage` JSON-LD emitted in `` — see top of file.)* ### How long does an IoT security assessment take? Typical engagement: 3–6 weeks. Discovery and scoping take 1 week; technical testing 2–4 weeks depending on system complexity; reporting and remediation workshop 1 week. The 60-day remediation re-check is scheduled at engagement close. Hardware-heavy assessments (silicon-level work, fault injection) extend testing 1–2 weeks. ### Do you assess hardware, firmware, or just the cloud side? All three, end-to-end, in a single engagement. Most IoT vulnerabilities surface at integration boundaries — between hardware and firmware, between firmware and cloud, between device and mobile companion app. Assessing components in isolation misses these failure modes. We scope by system, not by component. ### What's the difference between an IoT security assessment and an IoT compliance audit? A compliance audit verifies that a system meets a published standard (ISO 27001, ETSI EN 303 645, OWASP IoT Top 10) by checking against a control list. A security assessment attempts to break the system as an adversary would. Both have value; compliance audits answer "are we documented" and security assessments answer "can we be exploited." Our engagements focus on the second question and provide compliance evidence as a byproduct. ### Can you test pre-release prototypes? Yes — pre-release is often the highest-leverage moment because findings can change product design rather than require patches. We work with pre-tape-out silicon (under NDA), engineering samples, beta firmware, and early-stage cloud architectures. Pre-launch product security is documented as a [dedicated solution](/solutions/pre-launch-product-security/). ### How do you extract firmware when JTAG and UART are disabled? Multiple paths: chip-off (desolder SPI flash or eMMC and read with a hardware programmer), side-channel power analysis to recover keys, glitching to bypass secure-boot, OTA-update interception to capture firmware in transit, vendor-supplied debug interfaces (often left enabled in test mode), and supply-chain firmware retrieval from BoM sources. The right method depends on the silicon and the threat model. We document the path used and the cost-to-replicate for each finding. ### What does the deliverable look like? Bilingual EN+ZH report: executive summary (3–5 pages, decision-maker readable), technical findings (one section per finding with reproduction steps, evidence artifacts, CVSS rating, exploit complexity, remediation guidance), sample evidence package (PoC code, screenshots, captured traffic), and a 60-day remediation re-check appointment. Sample evidence package is anonymized and available for review under NDA — see [Inside an Engagement](/methodology/inside-an-engagement/). ### Do you offer this as a white-label / partner channel? Yes. Security firms reselling this capability to end clients can engage Melina at wholesale via the [Partnerships program](/partnerships/) — White-Label Delivery, Named Specialist, or Preferred Partner. Wholesale day rates published on the [partnership pages](/partnerships/named-specialist/). --- ## Authorized testing disclaimer All techniques described on this page are performed under authorized rules of engagement with the system owner. Unauthorized access to systems is illegal. --- ## Ready to start? [Request Assessment →](/contact/request-assessment/?service=iot-embedded-security) — a discovery call with Tatiana takes 30 minutes and clarifies scope, timeline, and starting-from pricing within one session.