Highlights | At The MedTech Conference 2026 in Boston, hosted by the Advanced Medical Technology Association, discussions on AI, governance, and cybersecurity reinforced the need for medical device security to span the full device lifecycle, from design through decommissioning. Mender supports stringent security requirements with robust, secure software updates that help medical device manufacturers keep deployed devices patched and protected long after launch.
Historically, a medical device was considered finished once it shipped. At The MedTech Conference 2026, sessions on AI, regulation, cybersecurity, and compliance kept returning to the opposite view: for a connected medical device, shipping marks the start of the software lifecycle, not the end of development.
The Advanced Medical Technology Association (AdvaMed) hosted this year’s conference in Boston, attracting more than 4,450 attendees from over 2,000 organizations and 40 countries. Speakers covered global market access, investment and growth strategy, workforce challenges, and healthcare transformation. Across the conversations, one requirement stood out — keeping a connected medical device secure, compliant, and reliable after launch depends on updating its software in the field. Robust, secure software updates have become the most practical way to meet that requirement at scale.
The key takeaways from the conference illuminate what the teams responsible for maintaining medical device software after launch must consider.
The session, “AI in MedTech: Where Will Value Actually Be Created?,” kept returning to one question: which capabilities justify in-house engineering, and which are better sourced from a proven supplier? Panelists raised the question in the context of AI, but it applies more broadly to medical device development.
The most successful companies involve clinicians early, so they understand how a product will actually be used before development begins. Clinician-focused design takes engineering time and attention, and every capability a team builds in-house draws on the same limited pool of both, panelists noted.
Compliance makes the trade-off more demanding. Panelists described meeting standards as one of the most significant barriers in medical device manufacturing. AI adds additional complexity, as AI models are increasingly treated as software as a medical device (SaMD), bringing them under the same regulatory expectations as the device itself.
For software update infrastructure, the cost of building in-house is clear. An in-house software update system must be designed, validated, documented, and maintained to the same standard as the rest of the device, and every hour spent on it is an hour not spent on clinical value. A proven software update solution lets teams focus engineering effort on the device, while relying on established update infrastructure to support compliance requirements on the software management side.
Within the next few years, regulators are expected to evaluate both the product and the data and governance behind it. Predictability has become a regulatory objective in its own right, and regulators want to know, in advance, how a device will change once it is on the market.
Post-market surveillance came up as a priority throughout the conference. Speakers suggested that strong post-market surveillance could reduce the pre-market burden because ongoing oversight in the field gives regulators evidence that a pre-market review alone cannot provide.
The U.S. Food and Drug Administration (FDA) has already moved in this direction for AI. Its final guidance on Predetermined Change Control Plans (PCCPs) for AI-enabled device software functions, issued in December 2024, allows manufacturers to implement modifications pre-authorized in the initial marketing application, rather than submitting a new application for each change. A PCCP also asks manufacturers to describe how each modification will be implemented, including whether it will be delivered automatically through a software update or require human intervention.
A predictable post-market strategy depends on the same element at every stage: software updates that are planned, controlled, and auditable. An auditable record is the kind of evidence a PCCP and post-market surveillance program rely on.
Cybersecurity discussions at the conference started from a pragmatic premise: cyber incidents are inevitable. What separates manufacturers is how well they prepare before an incident, through threat modeling, device architecture, and the ability to respond to threats once a device is in the field. The consensus is that the era of the set-and-forget medical device is over; a static device will not only fail to deliver competitive value but will also fail ongoing compliance and safety requirements.
U.S. regulation already reflects the reality of dynamic devices. Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act) requires manufacturers of cyber devices to submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities, including coordinated vulnerability disclosure. Manufacturers must also provide a software bill of materials (SBOM) and make postmarket updates and patches available. Section 524B sets two cadences for those updates: patches for known unacceptable vulnerabilities on a reasonably justified regular cycle, and prompt out-of-cycle patches for critical vulnerabilities that could cause uncontrolled risks.
Reacting to cybersecurity threats across the lifecycle requires the ability to update devices securely once they are in the field, on a planned schedule and at short notice. Secure software updates form the foundation for meeting postmarket patch obligations across a deployed fleet.
One of the most practical warnings at the conference came from a digital health panel: you can still build broken systems out of great components. A well-tested application on proven hardware can still fail if the parts don’t work together across its lifecycle, or if the system isn’t designed around how clinicians actually use it.
The compatibility management risk grows after launch. A connected medical device is a system of software components, including the operating system, applications, AI models, and third-party libraries, each with its own patches and release cycle. Without a software update management strategy, those components drift apart over time. Devices in the field end up running different versions, fixes go out unevenly, and nobody has a clear picture of what is actually deployed. A system that worked at launch can gradually become broken.
The update process itself is part of the system and needs the same discipline. An update that fails partway through and leaves a device unusable trades one risk for another. For medical devices, downtime has clinical and commercial consequences.
Visibility into what each device is running, along with controlled rollouts across the fleet, helps teams keep deployed systems consistent long after devices ship. For complex systems of components, such as a gateway with attached microcontrollers, component orchestration allows teams to define the intended software configuration for the whole system and update across its components.
Taken together, the discussions at the MedTech Conference 2026 pointed to the same reality. Regulators, clinicians, and security experts all expect connected medical device manufacturers to actively maintain devices throughout their lifecycles, rather than authorize them once and leave them unchanged.
For engineering, product, and regulatory teams, the shift raises four practical questions:
Answering these questions well depends on a reliable way to update device software once it is in the field.
Download our guide or contact us to learn more about future-proofing the software infrastructure of connected medical devices.