Most medical device teams treat cybersecurity the way they treat audits: something you deal with when it becomes unavoidable. That instinct is understandable. It is also expensive.

The FDA's cybersecurity requirements have been in place, in draft form, since 2013. What changed in December 2022, when the Omnibus bill amended the Food, Drug, and Cosmetic Act, was not the expectation. It was the legal authority. For the first time in its history, the FDA can deny market clearance for a device solely on the basis of its cybersecurity profile, even if the device is otherwise safe and effective. That is not hypothetical. It is happening.

Deferral feels like a reasonable tradeoff until it isn't. This article is about where that tradeoff breaks down.

BONUS RESOURCE: Click here to download your free Cybersecurity Gap Assessment Checklist!

The "it doesn't apply to us" misconception

The most common mistake manufacturers make is assuming that because their device isn't connected to the internet, the cybersecurity requirements don't apply. They do.

The decision tree here is simpler than most teams expect. If your device has software or any form of programmable logic, including firmware on a microcontroller or field-programmable gate array (FPGA), then all of the FDA’s cybersecurity requirements apply.. It does not matter whether it has Wi-Fi. It does not matter whether it has Bluetooth. It does not matter whether it has any external communication interface at all. If there is software/firmware then the full set of cybersecurity requirements applies.

One useful way to think about it: if your device is not made of solid wood, you should assume it's subject to cybersecurity requirements.

The FDA does not calibrate these requirements to the size of your company or the perceived safety risk of the device category. A software-enabled device with a low severity profile still requires a full cybersecurity program. Ignoring that assumption is what turns an otherwise smooth submission into a 30-item deficiency letter.

What the FDA actually wants to see

When you submit a 510(k) or De Novo application for a device with software, the FDA's electronic submission portal, eSTAR, automatically looks for 14 cybersecurity artifacts. These are not optional items you can argue around. Each one needs to be a substantive document, not a paragraph, with clear traceability throughout.

The artifacts fall into two categories: design inputs and design outputs.

Design inputs include the security risk management plan, risk management report, threat model report, security risk assessment report, software bill of materials (SBOM), an SBOM support report, the software component safety and security assessment report, a vulnerabilities with uncontrolled risk report, an unsolved anomalies risk report, a cybersecurity metrics report, and a cybersecurity controls report.

Design outputs include the architecture views report and the cybersecurity testing report, which summarizes independent testing results including fuzz testing, Static Application Security Testing, penetration testing, and attack surface analysis.

The SBOM itself is a machine-readable JSON file. The format matters. The FDA accepts both CycloneDX and SPDX formats, and tooling exists to convert between them. Ultralight includes SBOM generation using SPDX natively.

The cybersecurity controls report is one area where FDA expectations are evolving faster than published guidance. The agency now asks manufacturers to indicate the page numbers of specific required sections within that document. What that means in practice is that the structure is increasingly prescribed, even if the published guidance hasn't caught up to what reviewers are requesting in deficiency letters.

The SBOM support report is not the SBOM

One distinction worth spending time on: the SBOM support report is a separate document from the SBOM itself. The SBOM lists your components. The SBOM support report describes the support status of each component, including end-of-support dates and, critically, your plan for handling components that go end-of-life or whose vendor disappears. This document is where a lot of submissions fall short. Teams generate the SBOM, assume that covers it, and miss the support narrative entirely.

Cybersecurity risk is not safety risk

Teams that have spent years operating within ISO 14971 frameworks sometimes try to fold cybersecurity risk into their existing safety risk management processes. The logic is understandable. The result is a deficiency.

Safety risk and cybersecurity risk are different in almost every way that matters. Safety risk accumulates statistical evidence over months and years. Cybersecurity risk moves on a timeline of days and weeks. Safety risk is managed with probability of harm. Cybersecurity risk does not use likelihood at all. The two metrics are severity and exploitability, and those are the only metrics.

That distinction has a practical consequence for your submission. If your cybersecurity risk assessment includes language like "this device is low risk because it is not connected to any network," expect a deficiency. The FDA is not interested in how you think attackers would use your device. It is interested in the exploitability of vulnerabilities and the severity of outcomes if they are exploited.

There is one area of overlap: if a cybersecurity risk analysis reveals a finding that also has safety implications, it enters both processes. That does not remove it from the cybersecurity process. It now runs through both, and mitigating controls in each process are independent.

What happens to legacy devices

One of the more uncomfortable truths about FDA cybersecurity enforcement is that it reaches beyond new submissions. If you submit a new device and the review surfaces cybersecurity deficiencies, you may find that the FDA uses that submission as an entry point to inspect your broader product portfolio, including devices already on the market.

There is a documented pattern of manufacturers receiving deficiency letters on a new submission, then receiving an inspection, then receiving a warning letter that includes enforcement action against legacy devices that were never updated for cybersecurity compliance. In at least one case, a manufacturer was required to replace devices already implanted in patients at no cost to patients or facilities, because the devices in the field did not meet current cybersecurity standards.

This is not a hypothetical risk. The practical implication for your team is that making changes to any existing device, even what seems like a minor update such as supporting a new version of a companion smartphone, is likely to trigger a full cybersecurity review. Swapping a phone model without changing the app has been enough to generate a two-dozen-item list of cybersecurity questions from the FDA. If you touch a legacy device, all of it applies.

When to bring in cybersecurity

The longer you wait to address cybersecurity, the more expensive and time consuming are the corrections. This is not a general principle. It is a hardware reality.

If your device is implantable and battery life matters, your microcontroller choices constrain what is cryptographically possible. Legacy chips, the ones designed a decade ago that power plenty of current-generation products, frequently lack the hardware acceleration needed to run encryption and authentication without destroying battery performance. There is no software workaround for insufficient CPU bandwidth or memory. If you discover this during submission preparation, you are looking at an architecture redesign.

The teams that avoid this problem are the ones engaging cybersecurity expertise before prototyping, during the phase where microcontroller selection is still a design decision rather than a sunk cost. At that stage, the cost of getting it right is the cost of a conversation. After first silicon, the cost is measured in months and dollars.

The FDA has 180 calendar days to respond to a deficiency letter, and that window is clearly stated in the letter. What is less obvious is that the clock on your review stops when a deficiency letter is issued and does not restart until you have addressed every item. A second deficiency letter resets the process. For a venture-backed startup with a clinical or regulatory milestone tied to clearance, each iteration costs runway.

Hospital networks are not a safe assumption

Devices that operate within hospital environments carry a specific misconception worth addressing directly: the assumption that hospital networks are inherently secure, and that devices connected to those networks can rely on that security rather than implementing their own is a mistake. All operation environments should be considered to be malicious.

This is one of the fastest paths to a deficiency or a not substantially equivalent (NSE) determination.

Hospital networks are not secure by default. EHR systems, DICOM servers, and PAC servers vary widely in how current their implementations are. Picture archiving and communication system (PACS) servers, for instance, exist in many facilities in versions that have not been updated in years and that implement older, less secure variants of the DICOM standard. Your device must default to the most secure configuration attainable. Configuration options that allow downgrading for older infrastructure are acceptable, but the default state must be maximum security.

The FDA does not accept "the device operates inside a secure hospital environment" as a mitigation control. That language appears in deficiency letters. If you cannot fully mitigate a cybersecurity risk through device-level controls, you can acknowledge residual risk and push mitigations to instructions for use or labeling, but this is the least defensible approach and is getting harder to justify as hospital environments grow more complex.

Cybersecurity belongs inside the quality system, not alongside it

The question of where cybersecurity lives organizationally tends to surface during quality system audits. Should it have its own stand-alone procedure within the QMS? The more defensible approach is to update the existing QMS elements that cybersecurity touches to include cybersecurity requirements, rather than creating a parallel procedure that sits outside the life cycle. The goal is to demonstrate that cybersecurity is embedded in every relevant phase of development, not bolted on at the end.

Work instructions that are cybersecurity-specific, such as how to generate an SBOM or conduct a threat model, make sense as stand-alone documents. But the policy-level elements should sit within the existing quality framework.
This also applies to governance. Cybersecurity does not happen automatically because engineers know it matters. If there are no policies, no procedures, and no accountability structure, the technical work will not happen either. Governance failures upstream produce documentation failures downstream.

AI and machine learning: a different validation problem

Validating AI and machine learning algorithms inside medical devices is increasingly a question teams are asking, and increasingly a place where teams make structural mistakes.

The first and most important distinction is that AI is a software component within a medical device. It is not a medical device by itself. Treating the AI model as a separate validation artifact that sits outside the design verification and validation framework misses the point. The algorithm's validation should be embedded within the verification and validation scheme at the appropriate level, whether unit, integration, or system level.

The second critical element is data segregation. Training data, tuning data, and validation data must be strictly separated. Datasets are never perfect, and any distribution anomalies, spikes or artifacts in the data, typically need to be normalized before validation can proceed. Skipping that step means the validation results are not reliable.

Generative AI in medical devices is an area where the FDA is not yet prepared to offer clearance pathways. If your device incorporates generative AI as part of its intended function, the regulatory strategy for that feature is not yet settled.

The cybersecurity landscape is not static

The FDA updates its premarket cybersecurity guidance periodically. A revised version was published in January 2025. Cybersecurity enforcement has also shifted in part from the FDA to the Department of Justice, which brings a different enforcement posture.

Internationally, the EU's product liability directive now includes software liability provisions, and cybersecurity compliance is directly implicated. Other jurisdictions are moving in similar directions. Australia's Therapeutic Goods Administration recently published guidance on how health AI products that cross into medical device territory should be handled, an early indicator of how international regulators are beginning to address the boundary between digital health and medical device regulation.

Keeping a current view of international regulatory movement is part of operating responsibly in this space. The standard that looks sufficient today may not be sufficient at submission, and the six- to twelve-month development cycles in most medtech companies mean the regulatory landscape changes faster than product cycles allow.

Getting cybersecurity right is not primarily a documentation challenge. It is a design discipline. The manufacturers that consistently clear submissions cleanly are the ones that treat it as such from the beginning.

BONUS RESOURCE: Click here to download your free Cybersecurity Gap Assessment Checklist!

Make cybersecurity a part of your QMS with Greenlight Guru

Greenlight Guru's quality management system (QMS) includes native SBOM generation and cybersecurity-aligned design controls, built for pre-market software and hardware teams. Greenlight Guru comes preloaded with IEC 62304 and ISO 14971 workflows, automated SBOM scanning, and cybersecurity-aligned design controls that connect directly to your risk management and traceability workflows. Unlike building cybersecurity compliance alongside your quality system, Greenlight Guru embeds it from day one so your cybersecurity artifacts are traceable artifacts of your development process, not a documentation sprint before submission.

To see how Greenlight Guru handles SBOM generation and cybersecurity-aligned design controls out of the box, get your free demo today!