The economic case for pre-launch product security is well-established. Findings discovered before launch are remediable through normal engineering work. Findings discovered after launch — particularly those discovered by external parties — cost an order of magnitude more, both in direct remediation effort and in compounded reputational, regulatory, and commercial impact. This solution covers structured pre-launch assessment across the product types we work with: connected devices, IoT platforms, SaaS products, mobile applications, and AI-powered products. ## Where pre-launch assessment focuses Pre-launch assessment is scope-constrained by what's still changeable. Findings that require silicon revisions, fundamental architecture changes, or release-blocking work are valuable only when there's time to act on them. We frame engagement timing accordingly. ### For connected devices - Hardware attack surface — debug interfaces, fault-injection resistance, secure-element integration, [secure-boot](/knowledge/glossary/secure-boot/) chain - Firmware integrity and update path — signing, anti-rollback, key revocation - Communication protocols — [MQTT](/knowledge/glossary/mqtt/), [CoAP](/knowledge/glossary/coap/), BLE/Wi-Fi/Zigbee/Thread, TLS posture - Cloud control-plane — provisioning, fleet management, multi-tenant isolation - Companion mobile applications — pairing protocols, local-network discovery, command flows ### For SaaS and cloud products - Architecture review — identity model, tenant isolation, data flow and authorization boundaries - Authentication and session management - API surface — authorization gaps, rate-limiting, abuse-resistance - Infrastructure posture — Kubernetes configuration, secret management, CI/CD pipeline - Data flow — encryption at rest and in transit, audit logging ### For mobile applications - Static analysis — credential handling, certificate pinning, hardcoded secrets, debug interfaces left in production builds - Dynamic analysis — runtime behavior, IPC surface, deep-link handling - Server-side API authorization tested from the mobile-client perspective - Platform-specific issues — iOS keychain usage, Android keystore, intent filters ### For AI-powered products - Direct and indirect [prompt injection](/knowledge/glossary/prompt-injection/) - RAG-source security — retrieval authorization, vector-store poisoning - Tool-integration authorization boundaries - System-prompt extraction and replacement - Output-handling — where downstream code processes LLM output as trusted data ## Pre-launch engagement structure A typical pre-launch engagement runs in three phases: **Phase 1 — Threat modeling and scoping (1-2 weeks).** We work with the engineering team to surface the threat model the product is being built against, identify the highest-priority assessment areas, and agree the test envelope for the assessment phase. **Phase 2 — Assessment (2-4 weeks, scope-dependent).** Hands-on testing against the agreed scope, with finding discovery and triage executed as we go. **Phase 3 — Remediation support (1-3 weeks).** We work alongside the engineering team during remediation, providing technical guidance, validation, and post-fix re-testing for material findings. A formal re-test sign-off closes the engagement. ## What this solution is not Pre-launch security assessment is not a compliance certification — those are issued by accredited bodies (ISO 27001, SOC 2, MLPS-graded assessors, UN-R 155 Technical Services). Pre-launch assessment produces the security artifacts that compliance work then consumes. Pre-launch security assessment is not a marketing-grade "we are secure" statement. The deliverable is a technical assessment report with findings and remediation guidance, not a public-facing security claim. ## Service mapping Pre-launch product security draws across the relevant service depending on product type: - [IoT & Embedded Security](/services/iot-embedded-security/) — for connected devices - [Architecture & Cloud Review](/services/architecture-cloud-review/) — for SaaS / cloud - [Mobile & App Security](/services/mobile-app-security/) — for mobile apps - [AI/ML Security](/services/ai-ml-security/) — for AI-powered products ## Compliance and standards frame Where the product enters specific regulatory regimes, the pre-launch assessment is sized to support the regulatory path: - IoT in EU markets — ETSI EN 303 645, EU Cyber Resilience Act (CRA) preparation - IoT in China — MLPS readiness positioning - Automotive — [UN-R 155](/knowledge/glossary/un-r-155/) and [ISO/SAE 21434](/knowledge/glossary/iso-sae-21434/) inputs - Consumer mobile and SaaS — privacy-impact assessment readiness ([PIPL](/knowledge/glossary/pipl/), GDPR) ## Engagement model Pre-launch product security is typically [Scoped Assessment](/engagement-models/scoped-assessment/) or [Fixed Package](/engagement-models/fixed-package/) where the product type matches a packaged offering. Multi-product or multi-quarter pre-launch engagement is typically [Custom Engagement](/engagement-models/custom-engagement/). > "The cost curve of pre-launch findings versus post-launch findings is sharply non-linear. A finding discovered three weeks before launch costs a schedule slip. The same finding discovered three weeks after launch costs a public disclosure cycle and, depending on severity, a recall. Pre-launch assessment is the verification step that finds practice gaps before the product ships." — Tatiana K., CEO, Melina Security ## What buyers ask us first Three questions surface in nearly every initial pre-launch engagement discovery call: **"How early should we engage relative to launch?"** Connected products with hardware: as early as silicon-selection and bootchain-architecture decisions, because findings at this stage are remediable through specification changes rather than chip respins. Software products: as early as the first stable architecture, before application features lock in. The leverage curve degrades sharply as the launch window narrows — engagements with less than 4 weeks of remediation runway can produce useful findings but rarely produce architectural improvements. **"How does pre-launch assessment coordinate with regulatory submissions?"** Most pre-launch engagements double as regulatory-submission preparation. The artifacts that satisfy regulatory frames (CRA Annex I evidence, UN-R 155 cybersecurity case input, MLPS readiness documentation) are the same artifacts a thorough pre-launch assessment produces. Engagement scope can be shaped to satisfy both the internal security goals and the specific regulatory framing the product will enter. **"What does the leverage difference look like in practice?"** Our [Pre-Launch Discovery of Secure-Boot Bypass case study](/case-studies/iot-firmware-secure-boot-bypass/) documents one concrete data point — a finding discovered three weeks before CE submission cost the customer a six-week schedule slip; the same finding three weeks after launch would have meant a recall plus public disclosure cycle. The pattern recurs across product categories with the specific numbers shifting based on launch volume and regulatory exposure. ## Frequently asked questions ### How early in the product timeline should we engage? For connected products with hardware components: as early as silicon selection and bootchain architecture decisions. For software products: as early as the first stable architecture, before the application-layer features lock in. Pre-launch assessment loses leverage as the design moves further along — findings cost more per fix-cycle the closer you are to launch. ### Will pre-launch findings block launch? That's an engineering and business decision the client makes. We provide finding severity and remediation guidance — the launch decision factors in finding severity, remediation cost, exposure window, and business timing. Some findings are clear launch blockers (a remote code execution path in the device); some are launch-with-mitigation; some are post-launch hardening work. ### Do you test against our actual production-bound build, or against an earlier build? The agreed-scope build, ideally release-candidate quality. Assessing against an earlier build that will materially change before launch wastes engagement effort because the findings may not apply to the actually-shipped product. ### How does pre-launch assessment scope adjust for AI-integrated products? AI-integrated products extend the pre-launch scope to include the AI integration boundaries — input handling, retrieval-source authorization, tool-invocation logic, output processing. Our [Five-Boundary Attack-Surface Taxonomy](/research/llm-application-attack-surface-taxonomy/) maps these explicitly; pre-launch scope shaped around the boundaries surfaces cross-layer findings before they ship rather than after. For pure-AI products (LLM SaaS, agentic systems) the AI boundaries dominate the scope; for hybrid products the AI boundaries are one stratum in a broader assessment. ### What if our product spans hardware, firmware, cloud, and mobile companion app? Cross-surface engagements scope as [Custom Engagement](/engagement-models/custom-engagement/) because the most consequential findings typically live at the integration boundaries (BLE pairing, OTA delivery, cloud-to-device control flows) rather than within any single surface. Single-surface scope is acceptable when one surface dominates the threat model, but cross-surface scope produces materially better coverage for products where the surfaces are tightly coupled. ### Related - [Industries — IoT and connected-device manufacturers](/industries/iot-manufacturers/) - [Industries — Cloud and SaaS companies](/industries/cloud-saas/) - [Industries — AI/ML product companies](/industries/ai-ml-companies/) - Companion case study: [Pre-Launch Discovery of Secure-Boot Bypass in Smart-Home Hub](/case-studies/iot-firmware-secure-boot-bypass/) - Companion research: [IoT Supply-Chain Vulnerabilities — Procurement Responsiveness Profile](/research/iot-supply-chain-2026/) - [Engagement models — Scoped Assessment](/engagement-models/scoped-assessment/) - [Engagement models — Fixed Package](/engagement-models/fixed-package/)