New Cybersecurity Regulations Make Remote Software Updates Practically Mandatory

Remote software updates used to be a feature you could skip. For most connected medical devices, that is no longer realistic. Section 524B of the FD&C Act requires cyber device manufacturers to make updates and patches available, on a regular cycle and out of cycle for critical vulnerabilities. FDA's premarket cybersecurity guidance (February 2026) then asks you to show how the device can be updated securely and in time. This post explains the statute, the guidance, and what to design and document.

From optional feature to practical necessity

A startup once told us they were leaning against remote updates for their device. The feature added value, but they feared it would complicate FDA review because of cybersecurity scrutiny. The instinct is understandable. It's also backwards.

FDA's current framework assumes you can fix a fielded device when a vulnerability appears. If you can't, your options are a field service visit, a return to the factory, or a recall. None of those scale, and none of them satisfy a reviewer who asks how you'll address a critical vulnerability "as soon as possible."

If you're deciding whether to build an update path, build it. The rest of this post covers why and how.

How FDA got here

FDA has treated cybersecurity as part of device safety for more than a decade.

• October 2014. FDA finalized its first premarket cybersecurity guidance. Manufacturers were expected to include a cybersecurity file with basic risk analysis. The bar was modest, especially for low-risk devices.
• December 2016. FDA finalized the postmarket cybersecurity guidance. It describes how to manage vulnerabilities in fielded devices and sets out conditions under which FDA does not intend to enforce 21 CFR 806 reporting.
• December 29, 2022. Congress passed the Food and Drug Omnibus Reform Act (FDORA), which added Section 524B to the FD&C Act. The section took effect on March 29, 2023. For the first time, FDA had statutory authority to require cybersecurity information for "cyber devices."
• February 3, 2026. FDA finalized the current premarket cybersecurity guidance. It superseded the June 2025 version, which had superseded the September 2023 version and absorbed a 2024 draft on Section 524B. The 2026 document is the one to cite.

For the full statute walkthrough, see our guide to FDA Section 524B requirements.

Is your device a cyber device?

Section 524B(c) defines a cyber device as one that meets all three of these criteria, quoted in Section VII.B of the 2026 guidance:

1. "includes software validated, installed, or authorized by the sponsor as a device or in a device;"
2. "has the ability to connect to the internet; and"
3. "contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats."

Teams often stop at the second prong. "We don't connect to the internet, so we're fine." FDA closed that door. Section VII.B says the ability to connect "include[s] devices that are able to connect to the internet, whether intentionally or unintentionally, through any means."

The guidance then gives this list, which it calls "illustrative, not exhaustive":

• "Network, server, or Cloud Service Provider connections;"
• "Radio-frequency communications (e.g., Wi-Fi, cellular, Bluetooth, Bluetooth Low Energy);"
• "Magnetic inductive communications; and"
• "Hardware connectors capable of connecting to the internet (e.g., USB, ethernet, serial port)."

A footnote drives the point home: a device serviced over USB has the ability to connect, even if the connection is brief. Software also includes firmware and programmable logic.

So the honest test is this. Does your device run software? Does it have any wired or wireless port? Could that port be attacked? If yes to all three, you have a cyber device. The remaining prongs still matter, but in practice most connected devices meet them.

What Section 524B requires about updates

Section 524B(b) sets three obligations for cyber device submissions. Two of them bear directly on update capability.

The plan under 524B(b)(1)

The statute requires "a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures."

FDA's guidance (Section VII.C.1) says this plan "should also describe the timeline, with associated justifications, to develop and release required updates and patches." Note the attribution: the timeline language is FDA's recommendation on how to satisfy the statute, not statute text itself.

The patch obligations under 524B(b)(2)

Section VII.C.1 of the guidance restates the two statutory duties verbatim:

• "Section 524B(b)(2)(A) of the FD&C Act requires manufacturers of cyber devices to make available updates and patches to the device and related systems for known unacceptable vulnerabilities, with these updates and patches made available on a reasonably justified regular cycle."
• "Section 524B(b)(2)(B) of the FD&C Act requires manufacturers of cyber devices to make available updates and patches to the device and related systems to address as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks."

Two phrases do the work here. "Reasonably justified regular cycle" means you need a routine cadence and a written reason for it. The guidance says the cycle length may vary with risk, and that the justification typically belongs in the cybersecurity management plan. "As soon as possible out of cycle" means critical fixes can't wait for the next release train.

Now ask the practical question. How do you make a patch "available" to a device in the field without a remote update path? A technician with a USB stick is a plan, but not one that meets "as soon as possible" across an installed base.

Related systems count too

Section VII.C.2 says FDA considers "related systems" to include manufacturer-controlled elements such as "software/firmware update servers." The update server is in scope for the cybersecurity you have to demonstrate. Building a remote update path means securing it, not just shipping it.

What the 2026 guidance expects you to show

The statute says what you must do. The guidance says what FDA wants to see. Four parts of the document speak to updates.

The updatability and patchability view

Section V.B.2 recommends a set of security architecture views. One of them is the updatability and patchability view. The guidance says it "should describe the end-to-end process that permits software updates and patches to be provided (i.e., deployed) to the device."

The example FDA gives is instructive. If you push software from an update server to an in-clinic cardiac implant programmer, "end-to-end" means the whole path from the server to the programmer that programs the implant. That path "will likely include traversing technology that the device manufacturer does not control," so your design should protect the whole route and account for the risk those third-party segments add. Our post on the architecture security view covers what goes into each view.

Appendix 1: Firmware and Software Updates

Updatability and patchability is one of the eight security control categories in Section V.B.1. Appendix 1 opens the category with a plain statement: "Devices should be capable of being updated in a secure and timely manner to maintain safety and effectiveness throughout the product's lifecycle."

The recommendations that follow are a design checklist:

• Design for future patches, which "will likely necessitate the need for additional storage space and processing resources."
• Consider how the update process behaves if communication is interrupted, including which phase of the update the interruption hits.
• Allow cybersecurity patches that are independent of regular feature update cycles.
• Build processes and architecture that allow rapid verification, validation, and distribution of patches.
• Preserve full build environments, regression suites, and tools so updates can be applied safely later.
• Maintain third-party licenses for the supported lifespan and plan for a supplier going out of business.
• "Implement a secure process and mechanism for providing validated software updates and patches for users."

That last line is as close as the guidance comes to saying "build remote updates." It doesn't name a transport. It does expect a secure mechanism.

The Cybersecurity Management Plan

Section VI.B lists the elements FDA recommends in the plan. Three of them are update-specific:

• Timeline to develop and release patches
• Update processes
• Patching capability, which the guidance defines as the "rate at which update can be delivered to devices"

A plan that says "updates are delivered by field service" has to defend that rate against the "as soon as possible" duty for critical vulnerabilities. A remote path makes the number defensible.

Labeling

Section VI.A asks for labeling that tells users how to obtain authorized updates and what happens at end of support, when "a manufacturer may no longer be able to reasonably provide security patches or software updates." You can't write that section well without a defined update path.

Beyond cybersecurity: the safety case for remote updates

The compliance argument is strong on its own. The engineering argument is stronger.

• Safety anomalies. Software defects that affect safety trigger corrections under 21 CFR 806. Without remote updates, a correction becomes a field action or a recall. With them, it becomes a release.
• Supportability. FDA's guidance notes that software "should be regularly updated to maintain the supportability of the software." Operating systems, libraries, and cryptographic algorithms age. A device you can't update becomes a device you can't support.
• Data. Connectivity that enables updates also enables telemetry, usage data, and service insight. Teams that avoid connectivity out of fear give up that value.

Our book chapter on developing and deploying patches covers how these timelines play out after launch.

Design the update path to be secure

A remote update path is also an attack path. FDA knows that, which is why the updatability view and the Appendix 1 controls exist. The essentials:

1. Authenticate the update. Appendix 1 recommends that devices "Require authentication, and authorization in certain instances, before permitting software or firmware updates." Sign every image and verify the signature on the device before installation.
2. Protect the channel end to end. Mutual authentication between device and update server, encrypted transport, and protection against replay of old or downgraded images.
3. Fail safe. Define what the device does if the update is interrupted. Dual-bank storage and rollback to a known-good image are common patterns.
4. Log it. Record update events so you can prove what version runs where. Section VII.C.1 notes that if updates are not applied to all fielded devices, the differing software configurations have different risk profiles, and vulnerabilities should be assessed for each.
5. Secure the server side. The update server is a related system under Section 524B(b)(2). Treat it with the same rigor as the device.

Our post on how to ensure secure software updates goes deeper on each step. The FDA cybersecurity requirements post shows where the update evidence lands in the submission.

The bottom line

Most connected devices are cyber devices under Section 524B. Cyber device manufacturers must make patches available on a justified cycle and out of cycle for critical vulnerabilities. FDA's February 2026 guidance expects an architecture view of the update path, security controls for it, a management plan that states your patching capability, and labeling that tells users how to get updates. The way to meet all of that at once is a secure remote update capability designed in from the start. Skipping it doesn't make the review easier. It makes the first critical vulnerability a recall.

Need help with cyber device requirements or your FDA cybersecurity documentation? Email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• FDA. Postmarket Management of Cybersecurity in Medical Devices. Final guidance, December 28, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
• Federal Food, Drug, and Cosmetic Act, Section 524B, Ensuring Cybersecurity of Devices (21 U.S.C. 360n-2), added by the Food and Drug Omnibus Reform Act of 2022. https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title21-section360n-2&num=0&edition=prelim