The connected-product security questionnaire, pre-answered
The 25 questions every enterprise customer, FDA reviewer, and app-store reviewer asks about your connected product, with the answer pattern that holds up under an AI-augmented review.
If you are 8 to 16 weeks from launching a connected product, this is the document your security reviewer is about to make you fill out. It comes in three shapes, the enterprise procurement spreadsheet, the FDA pre-market cyber submission, the app-store cyber review, and the questions are 80% the same.
Here is the question, what the reviewer actually wants to hear, and the failure mode that gets the answer rejected.
1. How is each device uniquely identified?
Answer pattern: Per-device asymmetric key pair, generated at manufacture inside a secure element, with the public half registered to a cloud directory before the device leaves the factory.
What gets rejected: Shared keys across an SKU. Identity derived from a MAC address. "We use UUIDs."
2. How does the cloud know a device is genuine?
Answer pattern: Attestation, the device signs a fresh challenge with its per-device key, the cloud verifies against the directory.
What gets rejected: Pre-shared secrets. Bearer tokens. Anything an attacker who got firmware out of one device could replay across the fleet.
3. How does a user authenticate to the device through the mobile app?
Answer pattern: The user authenticates to the cloud (passkey / WebAuthn / OIDC). The cloud issues a short-lived, device-scoped credential. The mobile app presents that credential to the device. The device verifies it against an attestation chain that traces to the user's account.
What gets rejected: "The mobile app talks directly to the device." "There's a default PIN." "The QR code is the credential."
4. What happens when a user loses their phone?
Answer pattern: Documented recovery flow that does not depend on the lost device. Recovery does not bypass authorization, it re-establishes it. The fleet does not become orphaned.
What gets rejected: "They reset the device." Recovery flows that require physical access to the device customer-side. Recovery flows that bypass the audit log.
5. How do you rotate keys without a fleet-wide outage?
Answer pattern: Keys are versioned. Devices accept the new version before the old version is retired. Rotation is rehearsed quarterly. The runbook names a human owner.
What gets rejected: "We haven't had to rotate yet."
6–25 are in the engagement.
The remaining twenty cover OTA signing chains, secure boot evidence, supply-chain provenance, multi-tenant authorization, audit-trail retention, incident-response runbooks, third-party API access, and the regulatory-specific items (FDA 524B, ISO 21434 work products, EU CRA conformity-assessment evidence).
If your launch is 8 to 16 weeks out and your security team has not signed off, get in touch. The pre-launch identity sprint exists to make this conversation a two-week exercise instead of a six-month one.