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 chain
- Firmware integrity and update path — signing, anti-rollback, key revocation
- Communication protocols — MQTT, 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
- 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 — for connected devices
- Architecture & Cloud Review — for SaaS / cloud
- Mobile & App Security — for mobile apps
- 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 and ISO/SAE 21434 inputs
- Consumer mobile and SaaS — privacy-impact assessment readiness (PIPL, GDPR)
Engagement model
Pre-launch product security is typically Scoped Assessment or Fixed Package where the product type matches a packaged offering. Multi-product or multi-quarter pre-launch engagement is typically 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 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 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 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 — Cloud and SaaS companies
- Industries — AI/ML product companies
- Companion case study: Pre-Launch Discovery of Secure-Boot Bypass in Smart-Home Hub
- Companion research: IoT Supply-Chain Vulnerabilities — Procurement Responsiveness Profile
- Engagement models — Scoped Assessment
- Engagement models — Fixed Package
Services that compose this solution
IoT & Embedded Security Assessment
Hardware teardown, firmware extraction, device-to-cloud ecosystem assessment.
Cloud & Architecture Reviews
Threat modeling, cloud backend assessment, Kubernetes, zero-trust design.
Mobile & Web Application Security
Mobile pentest (iOS / Android), web & API penetration testing.
AI & ML System Security
Adversarial testing, prompt-injection, AI pipeline architecture review.