Connected Device Security and Software Liability: Regulators, Standards, and the Duty to Patch

Summary. What actually binds a connected device maker, and where the duty to patch comes from.

There is no single connected device statute

Ask what law governs the security of a connected product and there is no clean answer. What exists instead is a convergence of five bodies of law, none of which was written for the problem:

Consumer protection enforcement, which has built a substantial body of security expectations out of the general prohibition on unfair and deceptive practices.
Product safety law, which treats a device that creates a hazard as a hazardous product whether the hazard originates in a hinge or in firmware.
Sectoral regulation, for medical devices, vehicles, financial services, and critical infrastructure.
Procurement standards, which set requirements for devices sold to government buyers and thereby shape the commercial market.
Ordinary tort and contract law, which is where the duty to patch is actually being constructed.

Manufacturers who ask "which statute applies?" get an unsatisfying answer. Manufacturers who ask "what would a regulator or a plaintiff say we should have done?" get a workable one, because the five bodies of law converge on a recognizable set of practices.

The unfairness and deception framework

15 U.S.C. § 45 prohibits unfair or deceptive acts or practices. Both prongs matter, and they operate differently.

Deception is the easier claim and the one most within a manufacturer's control. Where a company says its product is secure, encrypted, or protected, and it is not, that is deception. The representations that have drawn enforcement include:

"Bank-level encryption" where transmission was unencrypted
"Secure" in marketing where default credentials were hardcoded
Privacy assurances inconsistent with actual data flows
Security certifications displayed without the underlying compliance
Statements about the duration of security support that were not honored

Unfairness reaches practices that cause or are likely to cause substantial injury that consumers cannot reasonably avoid and that is not outweighed by countervailing benefits. This is the prong that permits enforcement against inadequate security without any misrepresentation, and it is the basis for the body of expectations that has developed:

Default credentials that are identical across units and cannot be changed
Failure to encrypt sensitive data in transit or at rest
No mechanism to deliver security updates
Known vulnerabilities left unremediated
No process to receive vulnerability reports
Excessive data collection unrelated to the product's function
Failure to test for well-known vulnerability classes

Consent orders are the operative source of guidance. Because these matters resolve by settlement rather than litigation, the practical standard appears in the orders: what conduct was found problematic, and what the company was required to implement. Reading them is more useful than reading the statute.

Typical remedial requirements: a written security program with a designated responsible individual; risk assessments; testing and monitoring; vendor oversight; independent third-party assessments for a period of years; specific technical measures; and reporting obligations. The programs are expensive and long, which is the point.

Product safety law reaches software defects

A connected device is a consumer product, and product safety law does not distinguish between a mechanical hazard and a software one.

Under 15 U.S.C. § 2064, a manufacturer, distributor, or retailer that obtains information reasonably supporting the conclusion that a product contains a defect which could create a substantial product hazard, or creates an unreasonable risk of serious injury or death, must report to the Commission. The reporting rule at 16 C.F.R. Part 1115 sets out the timing and content.

The obligations that surprise device makers:

The reporting trigger is low and the clock is short. The obligation attaches on information reasonably supporting the conclusion — not on certainty, and not on a completed investigation. The regulation contemplates reporting within days of obtaining the information, with a limited period to investigate before the clock runs.

Software can be the defect. A firmware flaw that causes a device to overheat, a control failure that permits unsafe operation, or a vulnerability permitting a remote attacker to disable a safety function are all product defects.

Remedies include recall. 15 U.S.C. § 2064 authorizes repair, replacement, and refund remedies. For a connected device, "repair" may be a firmware update — which is faster and cheaper than a physical recall, and which requires that an update mechanism exist.

Penalties. 15 U.S.C. § 2068 defines prohibited acts, and 15 U.S.C. § 2069 provides civil penalties. Failure to report is itself a violation, independent of the underlying defect.

Standards. 15 U.S.C. § 2056 authorizes mandatory safety standards, and voluntary standards developed by consensus bodies frequently become the practical benchmark.

The practical implication: a manufacturer's incident response process must include a product safety reporting analysis, run by someone who knows the reporting standard. Security teams routinely treat a vulnerability as a security matter and never ask whether it is a reportable defect.

Procurement standards shape the market

Government purchasing requirements reach far beyond government buyers, because manufacturers build one product line.

The federal framework for connected devices purchased by agencies establishes baseline capabilities developed through standards bodies, addressing device identification, configuration, data protection, interface access control, software update capability, cybersecurity state awareness, documentation, information dissemination, and education. Vendors selling to agencies must meet them, and the capabilities have become the common vocabulary for what a secure connected device does.

Labeling programs signal security capability to consumers and are voluntary but commercially significant: retailers and enterprise buyers increasingly require them, and a manufacturer that qualifies for a label has, in effect, documented the practices a regulator would ask about.

Radio equipment requirements under 47 U.S.C. § 302a reach devices that emit radio frequency energy, and equipment authorization has increasingly incorporated security considerations for certain categories.

Sectoral procurement — medical devices, vehicles, energy systems — carries its own security requirements that are frequently more prescriptive than anything in general consumer law.

The duty to patch

No statute says "you must patch." The obligation is being constructed out of ordinary doctrine, and it now has recognizable contours.

Contract. Where a manufacturer promises updates for a period, the promise is enforceable. Where it says nothing, buyers argue that a reasonable expectation of updates was part of the bargain, particularly for a product marketed as connected.

Warranty. An implied warranty of merchantability requires that goods be fit for their ordinary purpose. A connected device with a known, exploitable, unpatched vulnerability is arguably not. Express warranties about security create direct exposure.

Negligence. A manufacturer that knows of a vulnerability and fails to remediate it faces a straightforward negligence framing: a foreseeable risk, a feasible precaution, and a failure to take it. The difficulty is duty and damages, not breach.

Product liability. Whether software is a "product" for strict liability purposes has divided courts for decades. The analysis is easier where software is embedded in a physical device — the device is unquestionably a product, and a defect in its firmware is a defect in the product.

Unfairness. Regulators have treated failure to remediate known vulnerabilities as an unfair practice.

The emerging shape of the obligation:

Disclose the support period before purchase. A manufacturer that states a security support period and honors it is in a defensible position; one that says nothing is not.
Have an update mechanism. A device with no way to receive updates has a design defect once a vulnerability appears, because remediation is impossible.
Remediate known vulnerabilities within the support period, on a timeline proportionate to severity.
Notify at end of support. Continuing to sell a device whose support has ended, without disclosure, is a deception problem.
Notify affected users of serious vulnerabilities, particularly where user action is required.

Vulnerability disclosure

A manufacturer will receive vulnerability reports from researchers, customers, and coordinating bodies. How it responds is itself a compliance question.

A published policy is now an expectation. Consent orders require them, procurement standards reference them, and their absence is a finding. A workable policy states: where to report; what information to include; what the reporter may expect and when; a commitment not to pursue legal action against good-faith research within defined scope; and the coordinated disclosure timeline.

Safe harbor language matters. Researchers have historically faced exposure under computer fraud and anti-circumvention theories. A policy that commits not to pursue claims against research conducted within scope removes the disincentive to report, and its absence means researchers publish rather than notify. Note that a policy cannot waive third-party claims or criminal exposure — 18 U.S.C. § 1030 is a federal criminal statute, though its scope for unauthorized access has narrowed.

Coordinated disclosure. The norm is a period — commonly ninety days, adjusted for severity and remediation complexity — after which the researcher publishes. Manufacturers who negotiate in good faith get extensions; those who ignore reports or threaten researchers do not.

Known exploited vulnerabilities. Where a vulnerability in a manufacturer's product is being actively exploited, the calculus changes: the remediation timeline compresses, notification obligations may attach, and regulatory attention becomes likely.

Software bills of materials

An accounting of the components in a product — direct and transitive dependencies, versions, and suppliers.

Why it matters practically. When a widely used component is found vulnerable, every manufacturer faces the same question: are we affected? A company with a current bill of materials answers in hours. A company without one answers in weeks, during which it cannot tell customers anything.

Where the requirement comes from. Federal procurement requirements for software sold to agencies; sectoral regulation in medical devices and other areas; enterprise customer contract requirements; and increasingly, general expectations that a competent manufacturer knows what is in its product.

What it does not do. A bill of materials identifies components; it does not assess exploitability. A vulnerable component that is present but unreachable in the product's configuration may not be exploitable, and communicating that distinction to customers is its own discipline.

A worked incident

Wrenfield Domestic Systems makes a connected water leak detector with an automatic shutoff valve. About 340,000 units sold over four years, at $189 each.

On a Tuesday, a security researcher emails Wrenfield's general support address. The message describes a flaw in the device's local network interface permitting an unauthenticated attacker on the same network to issue commands — including closing the valve, and including disabling the leak detection function entirely.

The email sits in the support queue for nine days before anyone escalates it. That delay is the first and most consequential failure.

What Wrenfield's counsel, Ines Oyelaran-Stark, does on day ten

She convenes the right people immediately, and the composition matters: engineering, product safety, communications, and customer support — not just security. Her first question is not "how bad is the vulnerability" but "is this a reportable product defect?"

The product safety analysis. The device's function is to detect leaks and shut off water. A vulnerability that lets an attacker disable leak detection means the product may fail to perform its safety function. Under 15 U.S.C. § 2064 and the rule at 16 C.F.R. Part 1115, the question is whether Wrenfield has information reasonably supporting the conclusion that the product contains a defect that could create a substantial product hazard.

Engineering argues the attacker must be on the local network, which limits exploitability. Ines is unpersuaded that this resolves it: home networks are routinely accessible, the failure mode is water damage, and the reporting standard does not require certainty. She recommends reporting, and does so within the period the rule contemplates, measured from the day the information was escalated rather than from the day it arrived — a distinction she documents, and one she resolves to eliminate through process.

The disclosure analysis. Wrenfield's marketing says the device provides "secure, always-on protection." That is a representation. If the device can be silently disabled by anyone on the network, the representation is at least questionable, which is a 15 U.S.C. § 45 deception question independent of the safety question.

The support period question. Wrenfield has never stated a security support period. Devices sold four years ago are still in service. There is no basis to tell customers their device is out of support, and no defensible basis to decline to fix it.

The remediation

Day 10–14: engineering confirms the vulnerability and scopes the fix. Firmware update required. Fortunately, the device has an update mechanism — Ines notes in her memorandum that if it did not, the only remedy would have been a physical recall of 340,000 units.

Day 12: Ines contacts the researcher, thanks them, confirms the report, and proposes a coordinated disclosure date sixty days out. The researcher, who had heard nothing for nine days and was preparing to publish, agrees. This conversation is the difference between a coordinated disclosure and a surprise.

Day 14: report filed with the Commission, with the remediation plan.

Day 21: firmware update released. Approximately 71% of devices update automatically within a week.

Day 28: direct notification to registered owners, with instructions for the 29% that had not updated — devices offline, on networks blocking the update server, or owned by people who disabled automatic updates.

Day 45: Wrenfield publishes a security advisory and a vulnerability disclosure policy, including safe harbor language for good-faith research within scope.

Day 60: researcher publishes. Coverage is modest and largely favorable, because the fix predated the disclosure.

Day 90: 94% of active devices updated. Wrenfield's remaining problem is the 6% — devices that are offline, on networks that block updates, or abandoned — and it has no way to reach them beyond continued notification.

What it cost, and what it prevented

Direct cost: about $600,000 in engineering, legal, communications, and support. No enforcement action followed. No litigation followed.

The nine-day delay was the only thing that nearly went wrong. Had the researcher published before Wrenfield responded, the sequence would have been: public exploit, press coverage, regulatory inquiry, and a remediation conducted under pressure rather than on a plan.

The program Wrenfield built afterward

A monitored security@ address, published, with a triage commitment and an escalation path that does not run through general support.
A vulnerability disclosure policy with safe harbor language and a stated timeline.
A product safety reporting analysis built into the security incident process, run by someone who knows the 16 C.F.R. Part 1115 standard. This is the single most important process change, because security teams reliably fail to ask the safety question.
A software bill of materials for every shipping product, updated at each release.
A stated security support period — five years from last sale — published on the product page and in the box.
An end-of-support notification process.
A marketing claim review so that security representations are verified before publication.
Update mechanism as a design requirement for every new product, with a rule that no connected product ships without one.

Designing for the obligations

The regulatory and litigation exposure described above is substantially reducible through design decisions made early. The list below is not exhaustive; it is the set of things that appear in consent orders, in procurement standards, and in complaints.

No shared default credentials. Unique per-device credentials, or forced credential setting at first use. This is the single most frequently cited failing.

An update mechanism, authenticated and reliable. Signed firmware, rollback protection, and a delivery path that works for devices behind ordinary consumer networks. A device without one is undefendable once a vulnerability appears.

Encryption in transit and at rest for anything sensitive, with current protocols and certificate validation actually enforced.

Secure defaults. The device should be safe out of the box without configuration. Features that increase exposure should be off by default.

Minimized attack surface. Debug interfaces disabled in production, unnecessary services removed, unused ports closed.

Data minimization. Collect what the product needs. Excessive collection has been treated as unfair, and it converts every security incident into a privacy incident.

Logging sufficient to investigate. A manufacturer that cannot determine whether a vulnerability was exploited cannot answer the question customers and regulators will ask.

A documented support period, stated before purchase, with an end-of-support notification plan.

Component inventory maintained as a build artifact, not reconstructed on demand.

Third-party component monitoring, so that a vulnerability in a dependency reaches the right person automatically.

A published vulnerability disclosure policy with safe harbor language.

Design documentation showing that security was considered — threat models, design reviews, and testing records. When a regulator asks what the company did, the answer is this file.

Sectoral overlays

General consumer expectations are the floor. Several sectors impose more.

Medical devices. Premarket submissions require security documentation including threat modeling, a component inventory, and a plan for monitoring and addressing postmarket vulnerabilities. Postmarket management obligations continue for the device's life. A vulnerability affecting a device that has already shipped raises correction and removal reporting questions distinct from ordinary product safety reporting.

Vehicles. Safety regulation reaches software defects, and a vulnerability affecting vehicle control is a safety defect with recall consequences. Manufacturers face specific expectations about security programs, supplier management, and incident response.

Financial services. Devices and applications handling financial data carry obligations under 15 U.S.C. § 6801 and its implementing safeguards requirements, including a written program, designated responsibility, risk assessment, access controls, encryption, testing, and incident response.

Critical infrastructure. Sector-specific directives impose requirements on operators and, indirectly, on equipment suppliers. Reporting obligations for significant incidents are expanding.

Children's products. A connected toy or child-directed device collecting personal information — including persistent identifiers — implicates 15 U.S.C. § 6501 and 16 C.F.R. Part 312, requiring verifiable parental consent and data minimization. Connected toys have drawn specific enforcement attention.

Wireless equipment. Authorization requirements under 47 U.S.C. § 302a increasingly incorporate security considerations for certain device categories.

Frequently asked questions

Who inside the company should own this? Someone with authority to stop a shipment. Product security that reports into engineering without independent escalation becomes a schedule-driven function, and the decisions that produce liability — shipping with a known flaw, deferring a patch, approving a marketing claim — are made under schedule pressure. A named owner with a reporting line that does not run through the person accountable for the ship date is the structural fix.

How fast must we patch? There is no statutory timeline for consumer products generally. Practical expectations, drawn from consent orders, sectoral rules, and coordinated disclosure norms: critical and actively exploited vulnerabilities in days; high severity in weeks; lower severity in the next scheduled release. What matters most is having a documented severity-based standard and meeting it, because the plaintiff's exhibit is the backlog item that sat for eighteen months.

Do we have to tell customers about a vulnerability we have already fixed? Often yes, and usually you should. Users must install the update, which means they must know it exists and why it matters. Silent patching leaves the vulnerable population unaddressed and looks like concealment if it emerges later. Where the update is automatic and reaches nearly all devices, a published advisory may suffice.

Is there a federal IoT security law for consumer products? Not a comprehensive one. Procurement requirements bind devices sold to agencies; consumer protection enforcement under 15 U.S.C. § 45 and product safety law under 15 U.S.C. § 2064 reach the consumer market.

Do we have to patch forever? No, but you should state the support period before sale and honor it. Silence is the problem, not a finite period.

Is a vulnerability a reportable product defect? It can be. The question under 16 C.F.R. Part 1115 is whether information reasonably supports the conclusion that a defect could create a substantial product hazard. A vulnerability that defeats a safety function usually qualifies. Build the analysis into the incident process.

Can we sue a researcher who publishes? You can; it is almost always a mistake. Publish a disclosure policy with safe harbor language instead, and negotiate timelines in good faith.

Do we need a software bill of materials? For federal sales and several regulated sectors, yes. For everyone else, it is the difference between answering a component vulnerability question in hours and in weeks.

Is software a "product" for strict liability? Contested. The question is easier where software is embedded in a physical device, because the device is a product and a firmware defect is a defect in it.

What if we cannot reach devices to update them? Document the effort, continue notification, and consider whether the residual population creates a hazard requiring further action. This is why an update mechanism is a design requirement rather than a feature.

Supply chain and component liability

Very few device makers write all their own software, and the components they buy carry both the vulnerabilities and, sometimes, the remedy.

Where the exposure sits. A manufacturer is responsible to its customers and to regulators for the product it ships, regardless of which supplier's code contained the flaw. Enforcement and litigation run against the brand on the box. The manufacturer's recourse against its supplier is a separate matter governed by a contract that, in most cases, does not help much.

What supplier contracts should require:

Term	Why
Component inventory delivered with each release	You cannot answer the exposure question without it
Security requirements the component must meet	Establishes the standard
Vulnerability notification within a defined period	The clock starts when the supplier knows, not when you do
Remediation commitment with severity-based timelines	A supplier with no obligation will deprioritize you
Support period matching or exceeding your own	A component that loses support before your product does is a design problem
Source escrow or step-in rights	If the supplier fails, you still must patch
Cooperation in incident response and regulatory reporting	You will need their engineers
Indemnity for security defects	Rarely obtained in full; worth asking
Audit or attestation rights
Flow-down to their suppliers	The vulnerable component is usually three levels down

The support period mismatch is the trap. A manufacturer commits to five years of security support and builds on a component whose supplier supports it for two. In year three the component has an unpatched vulnerability and no supplier will fix it. The manufacturer's choices are to fork and maintain it, to redesign, or to break its own commitment. All three are expensive, and the problem was created at selection time.

Open source components have no supplier to obligate. The manufacturer inherits the maintenance burden entirely, and the practical mitigations are: choosing well-maintained projects, tracking upstream advisories automatically, contributing where the project's health matters to you, and budgeting for the possibility of maintaining a fork.

Contract manufacturers and white-label products. A company selling a rebranded device made by someone else bears the same customer-facing responsibility with less control. The agreement should address security requirements, update responsibility, vulnerability handling, and — critically — who reports to regulators. Ambiguity here produces a situation in which each party believes the other filed.

Diligence on acquisition. Acquiring a connected product line means acquiring its shipped fleet and its unpatched vulnerabilities. Ask for: the component inventory, the vulnerability backlog, the support commitments made to customers, the update mechanism's actual reach, the disclosure policy, and any regulatory correspondence.

The international layer

Connected products ship globally, and several jurisdictions have moved faster than the United States toward prescriptive requirements.

Baseline security requirements for consumer connected products. A recognizable common core has emerged internationally: no universal default passwords; a published means of reporting vulnerabilities; and a stated minimum period during which security updates will be provided, disclosed at the point of sale. Some jurisdictions have made these mandatory with market surveillance and penalties attached, and manufacturers selling into those markets must comply regardless of what United States law requires.

Horizontal cybersecurity regulation for products with digital elements. Broader frameworks impose essential requirements across the lifecycle: security by design and by default, vulnerability handling with a defined support period, coordinated disclosure, a component inventory, and reporting of actively exploited vulnerabilities and severe incidents to authorities within tight deadlines — sometimes measured in hours for an initial notification. Conformity assessment and product marking obligations attach, with penalties calculated as a percentage of global turnover.

Radio equipment security requirements in some markets condition market access on measures protecting network resources, personal data, and against fraud.

Sectoral rules for medical devices, vehicles, and machinery each carry their own cybersecurity provisions in most major markets.

Practical consequences for a manufacturer selling internationally:

Build to the strictest requirement. Maintaining separate product configurations for security baselines is impractical; the requirements are broadly compatible and the strictest one is close to good practice anyway.
The support period must be stated at point of sale. This is a labeling and documentation requirement in several markets, not merely a policy.
Incident reporting deadlines are short and vary. A twenty-four or seventy-two hour initial notification obligation cannot be met by a process that begins with a legal analysis. Build the notification decision tree in advance, with named decision makers and pre-drafted templates.
Conformity documentation is required, not optional. Technical files, risk assessments, and declarations must exist before market placement.
Actively exploited vulnerabilities carry the tightest obligations. Where a vulnerability in your product is being exploited in the wild, the reporting clock in some jurisdictions is measured in hours.
Coordinate the reports. A single vulnerability may trigger a product safety report in one jurisdiction, a cybersecurity incident report in another, a medical device correction report in a third, and a customer notification everywhere. These have different deadlines, different recipients, and different content requirements, and they must not contradict each other.

Litigation: what plaintiffs actually plead

Security defect litigation against device makers has settled into recognizable patterns, and knowing them shapes both defense and design.

The economic loss problem is the defense's best argument. Most plaintiffs have not been injured; they own a device that is less secure than represented. Purely economic loss is generally not recoverable in tort, which pushes plaintiffs toward contract, warranty, and consumer protection theories, and pushes them toward class treatment because individual damages are small.

The theories that survive:

Deceptive practices under state consumer protection statutes. The strongest claim where security representations were made. Statutory damages and fee-shifting in many states make these viable at scale, and the element — a material misrepresentation — is straightforward when the marketing said "secure."

Breach of express warranty. Where security was promised in the documentation or on the packaging.

Breach of implied warranty of merchantability. Contested but pleaded: a device with a known exploitable defect is arguably unfit for its ordinary purpose. Defendants argue that no product is perfectly secure and that the warranty does not guarantee invulnerability.

Unjust enrichment. Pleaded in the alternative; the measure of restitution is difficult.

Negligence where there is physical injury or property damage — the water damage case, the disabled safety function case. Here the economic loss rule does not bar recovery and the analysis is ordinary tort.

Privacy claims where the vulnerability exposed data, layering statutory privacy claims onto the security claims.

What plaintiffs seek in discovery: the vulnerability backlog and how long items sat; internal risk assessments; testing that identified the flaw before shipment; marketing claim approvals; support period decisions and the reasoning; and communications about whether to patch. The document that most often decides these cases is an internal message weighing remediation cost against risk.

Class certification is the battleground. Individualized issues about which devices were vulnerable in which configurations, what each purchaser relied on, and what damages each suffered are the defense. Plaintiffs respond that the defect is uniform and the representation was uniform.

What reduces exposure: accurate marketing, a documented support period, a vulnerability backlog managed on severity-based timelines, an update mechanism that actually reaches devices, and design documentation showing the security decisions were made deliberately. Each of those is also just competent engineering practice, which is the underlying point of this entire area.

End of support: the hardest decision

Every connected product eventually stops receiving updates, and how a manufacturer handles that transition determines whether it is an ordinary lifecycle event or a regulatory and reputational problem.

State the period before sale. This is the single decision that resolves most of the difficulty. A device sold with a clearly disclosed five-year security support period from last sale creates an expectation the manufacturer can meet. A device sold with silence creates an expectation of indefinite support that no manufacturer can meet, and every subsequent decision is made against that background.

Where to disclose it: the product page, the packaging, the documentation, and — for devices with a screen or an application — in the product itself. Several jurisdictions require point-of-sale disclosure, and it is good practice everywhere.

Notify before it ends. A reasonable sequence: notice at twelve months, six months, ninety days, and thirty days, delivered through every channel the manufacturer has — email to registered owners, in-app notification, and a published advisory. Include what the user should do.

Decide what "end of support" means operationally. Options, in decreasing order of user benefit:

Continue security updates for critical vulnerabilities only
Continue basic device function without cloud services
Provide a local-only mode so the device works without the manufacturer's servers
Provide a trade-in or discount toward a supported model
Simply stop, with notice

The cloud dependency problem. A device that requires the manufacturer's servers to function becomes inert when they are shut down — the user's property stops working through no fault of theirs. This has drawn regulatory attention and considerable public criticism. Where feasible, designing so core function survives without the cloud is both good engineering and a substantial risk reduction.

Do not keep selling. Continuing to sell a device whose security support has ended, or will end shortly, without prominent disclosure, is a deception problem under 15 U.S.C. § 45 and a straightforward one. Manage inventory so this does not happen, and disclose remaining support period on clearance sales.

Devices still in service after end of support. The manufacturer's obligations do not vanish entirely: a vulnerability that creates a substantial product hazard may still trigger reporting under 15 U.S.C. § 2064, and a manufacturer that knows of a serious flaw in devices still in use should consider notification even where it will not patch. The end of a support commitment is not the end of a safety obligation.

Where this is heading

Three trends are worth watching because each would change what a manufacturer must do.

Convergence toward mandatory baselines. The voluntary and procurement-driven requirements described above are becoming mandatory in more markets, with market surveillance and penalties. The practical effect for a global manufacturer is that the strictest jurisdiction sets the product specification, and the strictest jurisdiction is not the United States.

Software liability reform. There is a sustained policy argument that software makers should bear more of the cost of insecure products, and that contractual disclaimers of liability for security defects should not be fully enforceable. Proposals have included a duty of care for software developers paired with a safe harbor for those following recognized secure development practices. If such a framework arrives, the safe harbor becomes the thing worth building toward — and its likely elements are the practices in this article.

Shorter and harder reporting deadlines. Incident and vulnerability reporting obligations are proliferating, with deadlines measured in hours rather than days and with multiple recipients. The manufacturers who handle this well will be the ones who built the decision tree in advance; the ones who treat each report as a novel legal question will miss deadlines.

What to do about all of it now. Nothing in the preceding paragraphs changes the advice. State the support period, build an update mechanism, keep a component inventory, publish a disclosure policy, manage the backlog on severity-based timelines, run the product safety analysis on every security incident, and make sure the marketing claims are true. Those practices satisfy the current requirements, position the company for the emerging ones, and are — separately from any of that — what competent product engineering looks like.