Medical device cybersecurity and regulatory compliance have an inherent tension. The U.S. Food and Drug Administration (“FDA”) wants manufacturers to monitor, patch, and update connected devices throughout the product lifecycle. That is sensible. A networked device that cannot be updated is not really secure for long. But the 510(k) requirements can make the same update feel risky. If a cybersecurity fix changes software, architecture, connectivity, performance, or user workflow, the manufacturer has to ask whether the change could significantly affect safety or effectiveness and therefore require a new 510(k). That tension is not new, but it has become more visible now that FDA updated its premarket cybersecurity guidance to integrate cybersecurity into quality management system thinking and to address the statutory requirements added by section 524B of the Federal Food, Drug, and Cosmetic Act (“FD&C Act”).[1]
A manufacturer must submit a new 510(k) when a marketed device is about to be significantly changed or modified in design, components, method of manufacture, or intended use, including a change that could significantly affect safety or effectiveness.[2] In October 2017, FDA updated/issued a pair of guidances meant to provide a framework to analyze when changes to software would trigger a change requiring a 510(k). These guidances highlight that cybersecurity updates do not receive a free pass, but they also do not automatically trigger a new 510(k).[3]
That is where ambiguity enters. A narrow patch to address a known vulnerability in a third-party software component may be easy to document internally if it does not affect clinical function, performance, architecture, intended use, or risk controls. But many cybersecurity updates are not so tidy. Adding multifactor authentication may improve security, but it could also affect emergency access or clinical workflow. Encrypting data in transit may be prudent, but it could introduce latency. Replacing a communications protocol may reduce exploitability, but it may also change interoperability. Adding remote update capability may be essential for future patching, but it introduces its own cybersecurity and failure-mode questions.
In other words, a manufacturer can be pulled in two directions at once. On one side, FDA expects a structured process to monitor, identify, and address vulnerabilities. The current cybersecurity guidance emphasizes secure design, vulnerability management, software bills of materials (“SBOM”), and processes for post-market updates and patches.[4] Section 524B also requires sponsors of cyber-device submissions to include a plan to monitor, identify, and address postmarket vulnerabilities and exploits; make updates and patches available; and provide an SBOM.[5] On the other side, if the act of patching or updating changes the device in a way that could significantly affect safety or effectiveness, the manufacturer may need to submit a new 510(k) before distribution. This matters most for legacy connected devices. A manufacturer may discover that a meaningful security fix requires architectural changes that were not contemplated in the original clearance. The better security solution may be broader than a simple patch. Yet the broader the solution, the more likely the company will need to conduct a formal 510(k) assessment and perhaps file a new submission. That can create a perverse incentive to choose a narrower workaround, not because it is the best security answer, but because it is easier to justify as not requiring a new 510(k).
An additional incentive problem is driven by FDA’s limited ability to identify and enforce against products that lack appropriate cybersecurity controls. FDA’s primary means for identifying whether a cybersecurity update is adequate is by reviewing a premarket submission. For those that do not seek clearance, FDA likely would not be aware of a cybersecurity-compelled change to the product unless it was discovered during an inspection, which can be targeted or routine. Thus, companies are incentivized to avoid FDA detection by not filing a 510(k) out of fear of raising FDA awareness to cybersecurity updates, and to internally-document cyber security updates in a way that would not raise red flags for inspectors.
FDA has tried to mitigate these problems. Its software-change guidance recognizes that not all software changes require a new submission, and its cybersecurity materials repeatedly frame cybersecurity as a lifecycle responsibility. FDA also confirms that section 524B does not retroactively apply to submissions filed before March 29, 2023, but does apply when a previously authorized cyber device undergoes a change that requires premarket review.[6] That is an important distinction. Section 524B affects what must be in a covered premarket submission. It does not create a standalone obligation to file a 510(k) every time a manufacturer makes a cybersecurity update.
A remaining problem is predictability. Manufacturers need clearer examples of when cybersecurity changes cross the 510(k) line. FDA could help by describing practical scenarios covering authentication changes, encryption updates, SBOM-driven component replacements, cloud migration, remote patching, protocol changes, and emergency vulnerability fixes. For example, FDA could create a presumption that changes to comply with Cybersecurity Maturity Model Certification (“CMMC”) or Federal Information Processing Standard (“FIPS”) 140-3 are, or are not, grounds for requiring a supplemental 510(k). FDA could also encourage more use of predetermined change control plans for cybersecurity updates, so that defined categories of future patches can be implemented without repeated submission uncertainty.
The policy goal is simple: do not make companies afraid to patch. But admittedly, this is a complicated goal given the existing framework governing significant changes to a 510(k) device. FDA is right to treat cybersecurity as a patient-safety issue. But patient safety is not served if regulatory ambiguity slows fixes for known vulnerabilities. Meanwhile, medical device companies must have a plan for addressing this ambiguity. In general, this means it must have procedures that mandate that regulatory considerations are factored into any software update; particularly, any cybersecurity changes that implicate risks to safety and efficacy of the product.
For more information or assistance, please contact Tom Sundlof, Merle M. Delancey, or any member of Blank Rome’s Healthcare or Life Sciences industry teams.
[1] FDA, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (Oct. 2, 2014); FDA, Postmarket Management of Cybersecurity in Medical Devices (Dec. 28, 2016); FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Feb. 3, 2026).
[2] 21 C.F.R. § 807.81(a)(3)
[3] FDA, Deciding When to Submit a 510(k) for a Change to an Existing Device (Oct. 25, 2017); FDA, Deciding When to Submit a 510(k) for a Software Change to an Existing Device 11 (Oct. 25, 2017).
[4] FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Feb. 3, 2026).
[5] FD&C Act § 524B(b)(3) (21 U.S.C. § 360n-2(b)(3)).
[6] FDA, Cybersecurity in Medical Devices: Frequently Asked Questions (“FAQs”) (last visited June 26, 2026).