Connected devices and the software update problem

The blurring line

The distinction between firmware, software as a medical device, and connected accessories has effectively dissolved. A single product now spans all three. Regulatory strategy has to catch up.

Cyber requirements are now central

The FDA's cybersecurity guidance is no longer a checkbox appendix. Threat modeling, SBOMs, and coordinated vulnerability disclosure programs are being examined in first-round review comments.

Operational implications

Every connected device company should have a security lead by the first commercial launch. Outsourcing this function to a fractional consultant is no longer credible.

The upside

Teams that build modern software practices — CI/CD, staged rollouts, telemetry — into a regulated device gain a genuine durable advantage. Legacy competitors cannot catch up quickly.

Version control as a regulatory artifact

In traditional hardware-only devices, the design history file was largely static once the device cleared review. With connected devices, every software version potentially changes the risk profile of the product, which means the design history file has to become a living document that tracks each release with the same rigor previously reserved for the original submission.

Teams that have not built this discipline early often discover, mid-way through preparing a routine update, that they cannot cleanly reconstruct which software version was running on which deployed units at a given point in time. That traceability gap is exactly what regulators focus on when a field issue surfaces, and rebuilding it retroactively is far more expensive than building it in from the first release.

Cybersecurity documentation as an ongoing obligation

A software bill of materials is no longer a one-time deliverable submitted alongside a device application; it needs to be updated with every dependency change, including third-party libraries the device team may not think of as part of the “medical” software at all. A vulnerability disclosed in a widely used open-source library can trigger an obligation to assess and potentially patch devices already in the field.

Companies that treat this as a continuous engineering process, with a named owner and a defined cadence for dependency review, handle these events calmly. Companies that treat cybersecurity documentation as a document produced once for submission tend to discover the gap during an incident, which is the worst possible time to be building the process for the first time.

What changes on the org chart

The practical operational consequence is that quality and regulatory affairs staff need to sit much closer to the software engineering team than in a traditional device company. A quality lead who only reviews design changes at defined gates, rather than participating in sprint-level planning, will consistently be surprised by changes that should have triggered a regulatory assessment.

Several device companies have responded by embedding a regulatory-trained engineer directly on the software team, someone who can flag at the pull-request stage whether a change is substantial enough to require a filing update, rather than relying on a separate review months later.

Why this is still good news for the category

The added rigor is a genuine cost, but it also creates a moat for teams willing to absorb it. A connected device with a mature, well-documented update process can ship meaningful clinical improvements post-market — a refined algorithm, a new alert threshold — without the multi-year redesign cycle that a purely hardware device would require to achieve the same improvement.

That optionality is valuable to health system buyers, who increasingly ask device vendors how they plan to improve the product over its deployed lifetime, not just what it does on the day of purchase. Founders who can answer that question credibly are turning a compliance burden into a genuine sales advantage.