Building a Product Security Program for Connected Devices: A Practical Guide

Summary. The processes, owners, and documents that make the obligations manageable.

Start with ownership, not technology

The most common structural failure in product security is that the function reports to the person accountable for the ship date.

Every decision that produces liability — shipping with a known flaw, deferring a patch, approving a marketing claim about security — is made under schedule pressure. A function that cannot escalate independently will lose those decisions, and the record of losing them is the plaintiff's exhibit.

What the structure needs:

• A named owner of product security, with the authority to stop a shipment or an escalation path to someone who can.
• A reporting line that does not run through the engineering leader accountable for delivery.
• A standing forum — monthly is usually enough — where the vulnerability backlog and the shipping decisions are reviewed by engineering, legal, product safety, and communications together.
• Legal integrated from the start, because the reporting obligations under product safety law and the representations in marketing are legal questions that arise inside technical decisions.

Size it honestly. A company shipping one product line does not need a department. It needs one person who owns it, an escalation path, and the processes below.

PART ONE: THE FOUNDATION

Step 1 — Publish a vulnerability disclosure policy

Researchers will find flaws in your product. Whether they tell you or publish depends almost entirely on whether reporting is easy and safe.

Publish, at a discoverable URL and in a security.txt file:

• Where to report. A monitored address — security@ — that does not route through general support. The most common failure in this entire area is a report sitting in a support queue for a week.
• What to include in a report.
• What the reporter can expect: acknowledgment within a stated period (two business days is a reasonable commitment), triage within a stated period, and status updates.
• The coordinated disclosure timeline: typically ninety days, adjustable for severity and remediation complexity, with a commitment to negotiate in good faith.
• Safe harbor language: a commitment not to pursue legal action against good-faith research conducted within a defined scope. Be clear about what is out of scope — customer data, denial of service, physical attacks on other people's devices.
• Scope: which products and services are covered.
• Whether you offer a bounty, and if so, the terms.

On safe harbor. You cannot waive third-party claims or criminal exposure, and 18 U.S.C. § 1030 is a federal criminal statute regardless of what you promise. Say what you can: that the company will not initiate or support legal action, and that it considers research within scope authorized.

Never threaten a researcher. It converts a coordinated disclosure into a public one, guarantees coverage, and appears in every subsequent article about the company.

Step 2 — Build the triage process

A report arrives. What happens next should be defined in advance.

INTAKE (security@) — acknowledge within 2 business days
   |
VALIDATE — can we reproduce it?               [target: 5 business days]
   |
SEVERITY — assign using a documented scale
   |
   +-- Is it exploitable in a shipped configuration?
   +-- What is the impact? Data / control / safety function?
   +-- Is it being exploited in the wild?
   |
*** PRODUCT SAFETY ANALYSIS ***                [target: same day]
   Does this defeat or degrade a safety function?
   Could it create a substantial product hazard?
   -> If yes: reporting analysis under 15 U.S.C. 2064 STARTS NOW
   |
REMEDIATION PLAN — owner, timeline, release vehicle
   |
DISCLOSURE COORDINATION — contact the reporter, agree a date
   |
CUSTOMER NOTIFICATION DECISION
   |
RELEASE + ADVISORY
   |
UPDATE ADOPTION TRACKING
   |
POST-INCIDENT REVIEW

The product safety analysis is the step security teams reliably omit. A vulnerability that defeats a safety function is a potential product defect, and the reporting obligation under 15 U.S.C. § 2064 and 16 C.F.R. Part 1115 attaches on information reasonably supporting the conclusion — not on certainty and not after the investigation concludes. Someone who knows that standard must see every security report.

Step 3 — Define severity-based remediation timelines

Publish them internally and meet them. The plaintiff's exhibit in these cases is the backlog item that sat for eighteen months.

Document exceptions. A deferred item should carry a written rationale and a named approver. "We decided not to fix it" with reasoning is defensible; the same decision undocumented is not.

Step 4 — Maintain a component inventory

An accounting of every component in the product — direct and transitive, with versions and suppliers — generated as a build artifact rather than assembled on demand.

Why it matters operationally. When a widely used component is found vulnerable, every manufacturer faces the same question within hours: are we affected? A company with a current inventory answers immediately. A company without one spends weeks and can tell customers nothing in the meantime.

Requirements:

• Generated automatically at build, for every shipping version
• Retained for every version still in the field
• Covering firmware, application software, and any bundled third-party code
• Machine-readable, in a standard format
• Monitored against vulnerability feeds, with alerts routed to a named owner

What it does not do. It identifies components; it does not assess exploitability. A vulnerable component that is present but unreachable in your configuration may not be exploitable — and communicating that distinction to customers clearly, without appearing evasive, is its own discipline. Say what is affected, what is not, and why.

PART TWO: LIFECYCLE COMMITMENTS

Step 5 — Commit to a support period, and say so before sale

This single decision resolves most of the difficulty in the area.

• Choose a period — commonly measured from last date of sale rather than from purchase — and one you can actually fund.
• Disclose it before purchase: product page, packaging, documentation, and in-product where there is a screen. Several jurisdictions require point-of-sale disclosure.
• Confirm suppliers can support it. A component whose supplier support ends before your commitment does is a design defect created at selection time.
• Fund it. A five-year commitment on a product with a two-year development cycle means maintaining several versions concurrently.

Silence is worse than a finite period. A manufacturer that says nothing creates an expectation of indefinite support it cannot meet, and every later decision is judged against that.

Step 6 — Make the update mechanism a design requirement

No connected product ships without one. A device with no way to receive updates has a design defect the moment a vulnerability appears, because remediation is impossible and the only remedy is a physical recall.

Requirements: signed firmware with verification; rollback protection; delivery that works through ordinary consumer network configurations; automatic update by default with a user-visible status; and telemetry sufficient to know the adoption rate.

Track adoption. After a security release, you will be asked what percentage of the fleet has updated. A manufacturer who cannot answer has a second problem on top of the first.

Step 7 — Plan end of support before you need it

• Notification sequence: twelve months, six months, ninety days, thirty days, through every channel — email to registered owners, in-product notice, published advisory.
• Decide what end of support means operationally. Critical-only updates? Basic function without cloud services? A local-only mode? A trade-in offer? Simply stopping, with notice?
• Address the cloud dependency. A device that becomes inert when your servers shut down stops working through no fault of the owner. Designing core function to survive without the cloud is both good engineering and a substantial risk reduction.
• Stop selling. Continuing to sell a device whose support has ended, without prominent disclosure, is a straightforward deception problem under 15 U.S.C. § 45. Manage inventory accordingly.
• Remember the residual duty. A serious flaw in devices still in service may still require reporting under 15 U.S.C. § 2064 even after the support commitment expires.

PART THREE: PREVENTION

Step 8 — Build the security requirements into development

The measures that appear in consent orders, procurement standards, and complaints:

• No shared default credentials — unique per device, or forced setting at first use. The most frequently cited failing.
• Encryption in transit and at rest for anything sensitive, with certificate validation actually enforced
• Secure defaults; exposure-increasing features off unless enabled
• Debug interfaces disabled in production; unnecessary services removed
• Authenticated firmware update with rollback protection
• Data minimization — collect 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

Keep the documentation. When a regulator asks what the company did, the answer is the threat models, the design reviews, and the test records. Their absence is itself a finding.

Step 9 — Review marketing claims

Security representations are the easiest claim for a regulator to bring and the easiest for a manufacturer to prevent.

Require review before publication of: any use of "secure," "encrypted," "protected," or "private"; any claim about certifications or standards; any statement about the support period; and any comparative security claim.

The test: could an engineer demonstrate this is true today, and will it remain true? "Bank-level encryption" on a product with unencrypted local traffic is the paradigm enforcement case.

Step 10 — Push requirements to suppliers

A worked build

Calderwood Instruments makes connected industrial sensors — temperature, pressure, and vibration monitors installed in manufacturing plants and reporting to a cloud dashboard. About 60,000 units in service across 900 customers. Roughly 180 employees. No product security function.

The trigger is a customer's procurement questionnaire asking for a software bill of materials, a vulnerability disclosure policy, and a stated security support period. Calderwood has none of the three, and the customer represents 8% of revenue.

The general counsel, Boaz Nkemdirim-Halloway, is asked to "make us compliant." He starts by asking what would happen today if a researcher emailed.

Week one: the tabletop that changes the plan

He runs a ninety-minute exercise with engineering, support, and product management. The scenario: a researcher reports that an unauthenticated attacker on the plant network can alter sensor readings.

What the exercise reveals:

• There is no security address. The email would arrive at general support.
• Support's escalation path for "technical issue" routes to a tier-two queue with a four-day service level.
• Nobody in the room can say who decides whether to patch.
• Nobody has heard of the product safety reporting obligation. When Boaz raises it, the engineering director's response is that a sensor is not a safety device — which is wrong, because several customers use the sensors in interlock systems that shut down equipment on an alarm.
• There is no update mechanism for the two oldest product generations, representing about 14,000 units. Those devices cannot be patched at all.

Boaz's memorandum after the exercise is two pages, and the sentence the executive team reacts to is: "For 14,000 devices in service, the only available remedy for a serious vulnerability is a physical recall."

Weeks two to four: the cheap fixes

security@ stands up in three days, monitored by the platform engineering lead, with a two-business-day acknowledgment commitment and an escalation path that bypasses support entirely.

The vulnerability disclosure policy is published in week three: where to report, what to include, acknowledgment and triage commitments, a ninety-day coordinated disclosure default, safe harbor language for good-faith research within a defined scope, and an explicit statement of what is out of scope.

The severity scale and remediation timelines are adopted from an existing framework rather than invented, and published internally.

The product safety analysis is added to the incident process as a mandatory step, with Boaz named as the person who runs it. He writes a one-page decision aid describing the 15 U.S.C. § 2064 and 16 C.F.R. Part 1115 standard in plain terms, because he will not always be available and the analysis cannot wait.

Total cost of weeks two through four: about $40,000, mostly his own time and outside review of the policy.

Weeks five to twelve: the expensive ones

Component inventory. Engineering wires inventory generation into the build pipeline for current products. Reconstructing it for the two legacy generations takes six weeks and is incomplete — some components came from a supplier that no longer exists. Boaz documents the gap rather than pretending it closed.

Vulnerability feed monitoring is connected to the inventory, with alerts routed to a named engineer.

The support period. This is the hardest decision and it takes four executive meetings. Engineering wants three years; sales wants ten; finance wants to know the cost of each. They settle on seven years from last date of sale, with the reasoning documented: industrial customers keep equipment for a decade, competitors state five, and the incremental cost of years six and seven is maintenance of one firmware branch.

The commitment is published on the product pages, in the documentation, and in the datasheet.

The legacy problem. For the 14,000 unpatchable devices, Calderwood does three things: notifies affected customers of the limitation in writing; offers a trade-in credit toward current-generation units; and — for customers using the sensors in interlock applications — provides a network segmentation guide and offers engineering support to implement it. Boaz's assessment is that this is a genuine mitigation rather than a gesture, because the vulnerability class at issue requires network access.

Update mechanism becomes a hard design requirement for all new products, with a written rule that no connected product ships without one.

Month four: the customer questionnaire, and the first report

Calderwood answers the procurement questionnaire with a component inventory, a published disclosure policy, and a stated support period. The customer renews.

In month five, a real report arrives — an authentication bypass in the dashboard's API. It is triaged in two days, assessed as high severity, and found not to defeat any safety function, so no product safety report is required. The analysis takes Boaz forty minutes and is documented. A fix ships in eighteen days. The researcher, who received an acknowledgment within a day and status updates throughout, publishes on schedule with a favorable note about the response.

What Boaz would tell the next company

"The tabletop was worth more than the policy." Ninety minutes revealed that the process did not exist, that nobody knew who decided, and that 14,000 devices could not be patched. None of that was visible from an org chart.

"The support period decision was a business decision that took four meetings, and it should have." It is a multi-year cost commitment, and pretending it is a legal formality gets the wrong number.

"The product safety question is the one nobody asks." Engineering does not know the standard, and by the time legal hears about a vulnerability the reporting clock may have been running for a week.

"The unpatchable devices were the finding that mattered." Everything else was process. That was a design failure with 14,000 instances in the field, and it will take years to work through the installed base.

A build sequence

Items 1 through 5 can be done in a month and address most of the exposure. Everything else is improvement on a foundation.

The first incident runbook

Compress everything for actively exploited vulnerabilities, and note that some jurisdictions impose initial reporting deadlines measured in hours.

Staffing and budget

Budget items manufacturers underestimate: maintaining multiple firmware versions concurrently across the support period; the engineering cost of an update mechanism that works reliably; monitoring vulnerability feeds against the component inventory; and legal support for multi-jurisdiction reporting.

The cheapest line items are the highest value: the disclosure policy, the monitored address, and adding the product safety question to the triage process. Together they cost a few weeks and address the failures that most often become enforcement matters.

Failures that recur

A report sitting in a support queue. Fix with a monitored security@ and a triage commitment.

Nobody asks the product safety question. Security treats it as a security matter; the reporting obligation is missed.

No support period stated. Every later decision is judged against an expectation of forever.

No update mechanism. Turns a patch into a recall.

No component inventory. Weeks of silence when a common component is found vulnerable.

Marketing claims nobody verified. The easiest enforcement case there is.

Threatening a researcher. Guarantees the outcome you were trying to avoid.

Supplier support period shorter than yours. Created at component selection, discovered in year three.

Silent patching. Leaves the vulnerable population unaddressed and looks like concealment later.

Selling after end of support without disclosure. Straightforward deception.

Writing the advisory

A security advisory is a legal document written by engineers, and it is read by customers, researchers, regulators, and eventually by plaintiffs' counsel. Structure it deliberately.

What belongs in it:

SECURITY ADVISORY [ID]                         PUBLISHED: [date]

AFFECTED PRODUCTS AND VERSIONS
  Be precise. List what IS affected and what IS NOT.

SUMMARY
  One paragraph a customer's IT manager can act on.

IMPACT
  What an attacker could do. Plainly. Do not minimize.

PREREQUISITES FOR EXPLOITATION
  Network position, authentication, physical access, configuration.
  This is where honest scoping belongs — not in the impact section.

SEVERITY
  Score, and the vector, so customers can assess their own exposure.

REMEDIATION
  Version containing the fix; how to obtain and verify it.

WORKAROUNDS
  For customers who cannot update immediately.

TIMELINE
  Reported / acknowledged / fix released / advisory published.

CREDIT
  Name the reporter if they wish.

CONTACT

Drafting principles:

Do not minimize in the impact section. Scoping belongs in the prerequisites. An advisory that describes a serious flaw as "a potential issue in certain configurations" reads as evasion, and it will be quoted back.

Be precise about what is not affected. Customers with other products need to know they can stop worrying, and over-broad advisories generate support volume and unnecessary alarm.

Give the workaround. Many customers cannot update on your schedule. A network segmentation instruction or a configuration change that mitigates the risk is often more valuable than the patch in the short term.

Publish the timeline. It demonstrates responsiveness where the response was good, and it is going to be reconstructed anyway.

Credit the reporter. It costs nothing and materially affects whether the next researcher reports to you or publishes.

Have legal review it before publication, for three specific things: whether it contradicts any prior representation about the product's security; whether it is consistent with any regulatory filing made about the same defect; and whether the description of severity is defensible against the internal assessment.

Coordinate the channels. The advisory, the customer email, the release notes, and any regulatory filing should describe the same facts in compatible terms. Divergence between a filing that describes a defect and a customer notice that describes a minor issue is the sort of inconsistency that becomes an exhibit.

Making the recall decision

Sometimes a patch is not the answer, and the manufacturer must decide whether to conduct a corrective action campaign. The decision has a structure.

First, the reporting question is separate from the remedy question. Under 15 U.S.C. § 2064, the obligation to report attaches on information reasonably supporting the conclusion that a defect could create a substantial product hazard. That obligation exists whether or not the manufacturer has decided what to do about it, and delaying the report until the remedy is chosen is itself a violation.

Second, the remedy options for a connected device are broader than for a mechanical one:

Third, the analysis that determines which:

• Can the defect be remediated in software at all? If not, the physical remedies are the only ones.
• Does the update mechanism reach the affected population? Measure the adoption rate on prior releases; do not assume.
• What is the residual population after the update campaign? Devices offline, on restrictive networks, or abandoned. For a serious hazard, the residual population is the problem that remains after the easy fix.
• What is the severity of the hazard? A flaw permitting nuisance behavior is different from one defeating a safety function.
• Can affected owners be identified? Registration rates for consumer devices are frequently under half. Retailer records, cloud service accounts, and warranty registrations are the sources.

Fourth, run the campaign properly. Notification through every available channel, a monitored response mechanism, and tracking of completion rates. Corrective action campaigns are judged on effectiveness, and a campaign with a 12% completion rate will draw follow-up.

Fifth, document the reasoning. The decision memorandum — what was known, what options were considered, why the chosen remedy was adequate, and what the residual risk is — is the most important document in the file. It is also the document that will be read most carefully if something goes wrong afterward, which is a reason to write it carefully rather than a reason not to write it.

Managing multi-jurisdiction reporting

A single vulnerability can trigger reporting obligations to several authorities on different clocks with different content requirements. The failure mode is not usually ignorance; it is a process that starts with a legal research question when the deadline is measured in hours.

Build the decision tree in advance. For each product line, map: which markets it is sold in; which regulators have jurisdiction; what triggers a report in each; what the deadline is; who files; and what template is used. Maintain it as a one-page reference the incident lead can use at midnight.

Typical triggers and clocks:

Rules that keep this manageable:

One set of facts. All reports describe the same defect, the same impact, and the same remediation. Divergence between filings is the inconsistency that becomes an exhibit.

Initial notifications can be incomplete. Most regimes contemplate an initial report followed by supplements. Waiting for a complete picture is how deadlines are missed; file what is known and update.

Name the filer in advance. For each jurisdiction, a named person and a backup. Multi-jurisdiction incidents fail when everyone assumes someone else filed.

Track the supplements. An initial report creates an obligation to update, and closing the loop is part of compliance.

Coordinate with customer communication. Customers, distributors, and enterprise buyers frequently learn of a defect from a regulator's public database before the manufacturer tells them. Sequence the notifications so that does not happen.

Retain everything. The reports, the internal analysis supporting each decision, and the reasoning where a report was considered and not made. The last category matters most: a documented decision not to report, with the standard applied and the facts known, is defensible. An undocumented one is not.

Frequently asked questions

Where do we start if we have nothing? Name an owner, stand up a monitored security@, publish a disclosure policy with safe harbor, define severity-based remediation timelines, and add the product safety analysis to the incident process. Those five items take about a month, cost very little, and address the failures that most often become enforcement matters. Everything else builds on them.

How do we get engineering to take this seriously? Run the tabletop. Ninety minutes with a realistic scenario reveals — to the people who can fix it — that there is no intake, no decision maker, and possibly no way to patch some products. That conversation moves more than a policy memorandum, because the findings are the team's own.

What if a customer's security questionnaire asks for something we do not have? Answer honestly and state the plan with a date. Fabricating a component inventory or claiming a support period the company has not committed to creates a contractual representation and, if the product is sold to a government buyer, potentially worse. Enterprise buyers are generally accepting of a credible roadmap and unforgiving of a discovered misstatement.

Do we need a bug bounty? No. A disclosure policy with safe harbor is the requirement; a bounty is an optional accelerator that also generates volume you must be staffed to triage.

What if the reporter demands payment? Distinguish a bounty request from a demand not to publish. The first is a business decision; the second raises different questions and should go to counsel.

Can we require an NDA before hearing a report? You can ask; researchers generally refuse, and requiring one reads as suppression. It is not worth the reputational cost.

How do we handle a report about a product we no longer support? Assess whether it creates a substantial product hazard requiring reporting under 15 U.S.C. § 2064 regardless of support status. Consider notification even where you will not patch.

Do we report to regulators before or after fixing? The product safety reporting obligation attaches on information reasonably supporting the conclusion of a defect, not on completion of a fix. Report on the regulatory clock and describe the remediation plan.

What about vulnerabilities in components we did not write? Your product, your obligation to customers and regulators. Recourse against the supplier is separate and usually limited.

Should the disclosure policy promise a fix timeline? Commit to acknowledgment and triage timelines, and to negotiating a disclosure date in good faith. Committing to a fix timeline before triage means committing without knowing the scope.

Measuring the program

A product security program that is never measured drifts, and the metrics that matter are not the ones most often reported.

Metrics that mislead:

• Vulnerabilities found. A rising number may mean the program is working, or that the product is worse. Alone it says nothing.
• Patches shipped. Activity, not outcome.
• Scan coverage. Necessary and insufficient.

Metrics that matter:

Review monthly with engineering and product, quarterly with executives. The quarterly review should be the forum where the support period commitments, the residual unpatched populations, and the items past target are visible to people with budget authority — because those are business decisions being made by default when they are not made explicitly.

Set the target for the first year modestly. A program that begins by measuring time-to-acknowledgment, backlog age, and update adoption has enough to manage. Adding metrics before the basic ones are reliable produces a dashboard nobody trusts.

Related documents

• Connected Device Security and Software Liability: Regulators, Standards, and the Duty to Patch
• Connected Device Compliance Checklist: A Practical Checklist
• Product Security Toolkit: SBOMs, Vulnerability Disclosure, and Recall Decisions
• Cybersecurity Program Toolkit
• Data Breach and Incident Response Toolkit: From Detection to Notification
• Vendor Cybersecurity Diligence Checklist: A Practical Checklist
• Open Source Software Compliance Checklist: A Practical Checklist
• Business Continuity and Crisis Response Checklist: A Practical Checklist