Summary. Everything a connected device maker has to build, in the order that matters.

Phase 1 — Ownership and governance

  • A named owner of product security.
  • Reporting line that does not run through the person accountable for the ship date.
  • Authority to stop a shipment, or a documented escalation path to someone who has it.
  • Standing monthly forum: engineering, legal, product safety, communications.
  • Legal integrated into the incident process from the start.
  • Executive review quarterly, covering backlog, support commitments, and residual unpatched populations.

Phase 2 — Vulnerability disclosure policy

  • Published at a discoverable URL and in a security.txt file.
  • A monitored security@ address that does NOT route through general support.
  • Acknowledgment commitment (two business days is reasonable).
  • Triage commitment.
  • Coordinated disclosure timeline stated (commonly 90 days), with good-faith negotiation.
  • Safe harbor language — no legal action for good-faith research within scope.
  • Scope defined: what products, what testing is out of bounds.
  • What a reporter should include.
  • Bounty terms if offered.
  • Note the limits: cannot waive third-party claims or criminal exposure under 18 U.S.C. § 1030.
  • Never threaten a researcher.

Phase 3 — Triage process

  • Intake acknowledged within the committed period.
  • Validation and reproduction, with a target.
  • Severity assigned using a documented scale.
  • Exploitability in a shipped configuration assessed.
  • Active exploitation checked.
  • PRODUCT SAFETY ANALYSIS RUN ON EVERY REPORT — does it defeat or degrade a safety function? Could it create a substantial product hazard under 15 U.S.C. § 2064 and 16 C.F.R. Part 1115?
  • The person running that analysis knows the standard, and sees every report.
  • Remediation plan with owner, timeline, and release vehicle.
  • Disclosure coordination with the reporter.
  • Customer notification decision.
  • Update adoption tracked after release.
  • Post-incident review.

Failure mode: a report sitting in a support queue for nine days while the reporting clock runs.

Phase 4 — Remediation timelines

  • Documented severity scale.
  • Critical / actively exploited: days, out-of-band release.
  • High: 2–4 weeks.
  • Medium: next scheduled release.
  • Low: next major release, or accept with documentation.
  • Every deferral has a written rationale and a named approver.
  • Items past target tracked and reported.

Phase 5 — Component inventory

  • Generated automatically at build, not assembled on demand.
  • Covers firmware, application software, and bundled third-party code.
  • Direct and transitive dependencies, with versions and suppliers.
  • Machine-readable, standard format.
  • Retained for every version still in the field.
  • Monitored against vulnerability feeds, alerts routed to a named owner.
  • Test: can you answer "are we affected?" for a new industry-wide vulnerability within hours?
  • Exploitability assessed separately — presence is not exposure, and communicate the distinction clearly.

Phase 6 — Support period

  • A period chosen and funded (commonly measured from last date of sale).
  • Disclosed before purchase: product page, packaging, documentation, and in-product where there is a screen.
  • Supplier support periods confirmed to match or exceed it.
  • Budget accounts for maintaining multiple firmware branches concurrently.
  • Silence is not an option — it creates an expectation of indefinite support.

Phase 7 — Update mechanism

  • No connected product ships without one. Written design requirement.
  • Signed firmware with verification.
  • Rollback protection.
  • Delivery works through ordinary consumer and enterprise network configurations.
  • Automatic by default, with visible status.
  • Telemetry sufficient to measure adoption at 7, 30, and 90 days.
  • Legacy products without a mechanism identified, counted, and a plan documented.

Phase 8 — Secure development

  • No shared default credentials — unique per device or forced setting at first use.
  • Encryption in transit and at rest for sensitive data; certificate validation enforced.
  • Secure defaults; exposure-increasing features off unless enabled.
  • Debug interfaces disabled in production; unnecessary services removed.
  • Data minimization — collect only what the product needs.
  • Logging sufficient to determine whether a vulnerability was exploited.
  • Threat modeling at design, documented.
  • Security testing before release, documented.
  • Third-party component review at selection, including supplier support period.
  • Documentation retained — it is the answer when a regulator asks what was done.

Phase 9 — Marketing claim review

  • Review gate before publication for: "secure," "encrypted," "protected," "private."
  • Certification and standards claims verified.
  • Support period statements checked against the actual commitment.
  • Comparative security claims substantiated.
  • Test applied: could an engineer demonstrate this is true today, and will it remain true?
  • Note that inaccurate security claims are the easiest enforcement case under 15 U.S.C. § 45.

Phase 10 — Supplier requirements

  • Component inventory delivered with each release.
  • Security requirements the component must meet.
  • Vulnerability notification within a defined period.
  • Severity-based remediation commitments.
  • Support period matching or exceeding yours.
  • Source escrow or step-in rights.
  • Cooperation in incident response and regulatory reporting.
  • Indemnity for security defects.
  • Audit or attestation rights.
  • Flow-down to their suppliers.
  • For contract-manufactured or white-label products: who reports to regulators, stated expressly.

Phase 11 — Recall and corrective action

  • Reporting decision is separate from the remedy decision — the obligation attaches on information reasonably supporting the conclusion, not after a remedy is chosen.
  • Remedy options assessed: automatic update / user-action update / server-side mitigation / configuration guidance / feature disablement / repair or replacement / refund.
  • Update mechanism reach measured, not assumed.
  • Residual population after the campaign quantified.
  • Affected owners identifiable? Registration, retailer, cloud account, warranty records.
  • Campaign run through every channel, with completion tracking.
  • Decision memorandum documenting what was known, options considered, and why the remedy was adequate.
  • Penalties noted: 15 U.S.C. § 2068 prohibited acts; 15 U.S.C. § 2069 civil penalties.

Phase 12 — Multi-jurisdiction reporting

  • Decision tree built in advance, per product line: markets, authorities, triggers, deadlines, filer, template.
  • Deadlines mapped — some are measured in hours for actively exploited vulnerabilities.
  • One set of facts across all filings.
  • Initial notifications filed on time even if incomplete; supplements tracked.
  • Named filer and backup for each jurisdiction.
  • Customer communication sequenced so customers do not learn from a public database first.
  • Everything retained, including documented decisions not to report with the standard applied.

Phase 13 — End of support

  • Notification sequence: 12 months, 6 months, 90 days, 30 days, through every channel.
  • Operational meaning decided: critical-only updates / basic function without cloud / local-only mode / trade-in / stop with notice.
  • Cloud dependency addressed — does the device become inert when servers shut down?
  • Stop selling, or disclose remaining support prominently on clearance.
  • Residual safety duty recognized: a serious flaw may still require reporting after support ends.

Phase 14 — Sectoral overlays

  • Medical devices: premarket security documentation; postmarket vulnerability management; correction and removal reporting.
  • Vehicles: software defects as safety defects; security program expectations.
  • Financial data: 15 U.S.C. § 6801 safeguards program.
  • Critical infrastructure: sector directives and incident reporting.
  • Children's products: 15 U.S.C. § 6501 and 16 C.F.R. Part 312 — persistent identifiers are personal information.
  • Wireless equipment: authorization requirements under 47 U.S.C. § 302a.

Phase 15 — Metrics

Track and review monthly with engineering, quarterly with executives:

  • Time from report to acknowledgment
  • Time from acknowledgment to severity assignment
  • Time from severity to fix released, by severity
  • Backlog age distribution
  • Items past remediation target
  • Update adoption at 7, 30, 90 days
  • Residual unpatched population by product
  • Products shipping without an update mechanism (target: zero)
  • Products in field past stated support period
  • Component inventory currency
  • Time to answer "are we affected?" for a new industry-wide vulnerability
  • Marketing claims reviewed before publication

Related documents