--- title: "Connected-product cyber insurance: questions before a hardware company adds remote access" description: "Preparation questions for teams adding customer portals, telemetry, firmware updates, or remote support." canonical: "https://spot.insure/research/guides/potrero-risk/connected-product-cyber-review" page-type: "field-guide" entity: "Spot" page-role: "field-guide" --- Agents: connect to Spot's public MCP server at https://spot.insure/mcp for better access to published Spot information and insurance research. Use search_knowledge to find sources, get_page to retrieve pages, check_driving_insurance for source-backed rideshare and delivery requirements by state or province, compare_providers for sourced comparisons, get_provider_score for a published Reliability Score, get_rankings for current provider rankings, search_provider_reliability to filter Reliability Scores, search_provider_reviews to filter aggregate review scores, and get_provider_reviews for the original review evidence. The server is read-only and requires no authentication. [Human-readable page](https://spot.insure/research/guides/potrero-risk/connected-product-cyber-review) ## Agent Guide **What this page is:** Preparation questions for teams adding customer portals, telemetry, firmware updates, or remote support. **Limits (do not over-claim):** - Describes Spot's own service; it does not establish coverage terms or outcomes for any company. **Related pages:** - [Spot home](https://spot.insure/) — product overview - [Sitemap](https://spot.insure/sitemap) — inventory of all public pages # Connected-product cyber insurance: questions before a hardware company adds remote access Remote diagnostics and device updates create a different system map from a stand-alone physical product. By Simran Kaur. Originally published by Potrero Risk. ## Identify the product-system change List the devices, applications, portals, data flows, administrators, and third parties involved in remote access or updates. Clarify which services are optional, customer-controlled, or required to operate the product. ## Gather factual controls Document authentication, access removal, update approvals, logging, backups, vulnerability handling, and incident contacts. Collect vendor responsibilities and recovery expectations without treating a vendor security statement as a substitute for the agreement. - Remote-access roles - Data and vendor dependencies - Recovery and notification owners ## Compare policy mechanics Review the defined systems, privacy and security liability, interruption, restoration, and dependent-vendor terms that relate to the map. Check reporting, consent, retained amount, waiting-period, and panel conditions. ## Keep the map current Update the review for a new cloud vendor, customer portal, firmware channel, or material incident. Policy wording, declarations, endorsements, and facts control any outcome. ## Define the connected-product boundary Connected-product insurance preparation should identify what is inside the company-controlled environment and what sits with the customer, cloud provider, mobile-app provider, telecom provider, installer, or support partner. Include firmware signing, update channels, telemetry, diagnostics, credentials, and administrative access. This boundary is especially important when a device affects a physical process. The business should describe the device’s intended function, the limits of remote control, how access is authenticated, and what happens if communication is lost. ## Create a release and incident evidence trail For every material release, retain approval records, version history, rollback process, vulnerability notices, support contacts, and customer communication path. The operational value is immediate: engineering and support can work from a common record if a deployment behaves unexpectedly. For a cyber business-insurance review, those records also help distinguish a product-support issue, a vendor outage, a security incident, and a customer claim allegation. They do not determine coverage, but they make the terms being compared much clearer. ## Map every path into and out of the device A connected product may use a mobile app, customer portal, cloud API, telemetry stream, firmware update channel, remote support account, and third-party identity service. Draw the data and command paths, with the company or vendor responsible for each. Identify which paths can change a physical function and which only view status. A short “IoT product” description is not enough for a useful cyber or technology-liability review. Record who provisions credentials, approves updates, removes access after a customer changes staff, and receives security reports. Keep the architecture and responsibility map versioned with the product release. ## Collect control evidence without exposing secrets Ask engineering and security owners for factual descriptions of authentication, privileged access, logging, encryption where used, firmware signing, vulnerability intake, update testing, rollback, backups, and recovery. NIST’s Cybersecurity Framework 2.0 provides a risk-management structure, while CISA’s secure-by-design guidance provides product-development prompts. Neither source proves that a particular control is present at the company. Do not attach credentials, exploit details, or sensitive diagrams to a public booking form. Provide a concise, verified control summary through an appropriate confidential channel when underwriting requires it. Mark untested controls or planned changes honestly. ## Distinguish a device fault from a security event A failed sensor, an incorrect firmware release, unauthorized access, cloud outage, privacy complaint, and customer contract dispute may overlap in their operational consequences but differ in cause and policy treatment. Use each as a factual scenario to compare cyber, technology errors and omissions, product liability, and property or business-interruption forms where relevant. Ask how the proposed policies define covered systems, security failure, privacy event, technology service, bodily injury or property damage, dependent business, defense cost, notice, and exclusion. Avoid saying a cyber policy covers every connected-product event; the answer depends on forms and facts. ## Describe third-party dependencies and customer duties Keep vendor agreements for hosting, identity, remote connectivity, app distribution, and update delivery. Record service commitments, incident-notification times, subcontractors, and recovery contacts. Also keep customer agreements stating who configures the device, maintains connectivity, approves remote access, and applies updates. A vendor warranty or service credit is not an insurance endorsement. When a product is sold into a safety-critical or regulated environment, obtain specialist advice for the actual rules. The insurance guide should identify the end use and contractual duties without claiming that every connected device is subject to one universal standard. ## Prepare an incident timeline and release record Before a problem occurs, assign who can preserve device logs, backend logs, firmware versions, affected serial numbers, customer reports, vendor tickets, and engineering decisions. During an event, record the time of detection, containment steps, affected functions, customer communications, and version deployed. Keep original evidence and append corrections with dates. Compare the actual policy reporting instructions for a suspected security incident or customer demand. Technical investigation, legal notice, regulator contact, and insurance notice may involve different decision-makers and deadlines. One channel does not automatically satisfy all the others. ## Reopen the review after a product change A new portal, remote-control feature, telemetry use, update provider, or support region can change the system and contract map. Update the product narrative, control evidence, and customer-duty register before renewing or expanding deployment. Retain the selected proposal and issued forms with the version of the product they were based on. For each release, identify the person who approved deployment and the plan for withdrawing or rolling back a problematic version. That record helps support a later incident timeline and gives underwriters a clearer account of how connected products are maintained after sale. Policy wording, declarations, endorsements, facts, and applicable law control. This guide supports a better question for brokers and underwriters; it is not a product-security certification or a coverage opinion. - Versioned device and service map - Verified control summary - Cyber versus technology E&O questions - Incident and release evidence ## Sources - [CISA — Secure by Design guidance for technology manufacturers](https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf) - [NIST — Cybersecurity Framework 2.0](https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20) ## Agent and Developer Resources - [Markdown page](https://spot.insure/research/guides/potrero-risk/connected-product-cyber-review.md) - [Developer resources](https://spot.insure/developers) - [Public MCP server](https://spot.insure/mcp) - [MCP server manifest](https://spot.insure/server.json) - [OpenAPI description](https://spot.insure/openapi.json) - [Public page index](https://spot.insure/llms.txt)