FDA Cybersecurity Rules for Medical Devices

If a connected medical device can be hacked, FDA can treat that as a safety problem. Since March 29, 2023, manufacturers of many connected devices have had to show FDA how they will secure the device before sale and how they will deal with cyber flaws after launch.

Here’s the short version: if a product meets FDA’s “cyber device” definition, the submission must include a security lifecycle plan, a public vulnerability reporting process, and an SBOM. And the work does not stop at clearance or approval. Manufacturers still need to watch for flaws, issue fixes, and tell hospitals what to do when risk shows up.

A few numbers show why this matters:

• 89% of organizations in one IoMT review had medical systems exposed to exploited flaws and insecure internet connections
• 44.4% of ransomware attacks on U.S. hospitals disrupted care delivery
• 23% of medical devices had at least one known exploited vulnerability
• 14% ran on unsupported or end-of-life operating systems

If I were boiling the article down for a busy reader, I’d put it like this:

• FDA now treats cybersecurity as part of safety and effectiveness
• Section 524B sets the legal rule for covered devices
• 510(k), PMA, De Novo, PDP, HDE, and some supplements can be affected
• Premarket files need risk analysis, architecture details, testing records, update plans, and an SBOM
• Postmarket work includes monitoring, disclosure, patching, and end-of-support planning
• Hospitals need device inventory, segmentation, logging, patch tracking, and joint work with vendors

So the bottom line is simple: FDA device cybersecurity is no longer just guidance for many connected products. It is a filing issue, a field issue, and a patient care issue at the same time.

Case Study: Why FDA Cybersecurity Expectations Are Really QMS Expectations

sbb-itb-535baee

FDA Authority and Core Statutory Requirements

FDA regulates medical device cybersecurity under the FD&C Act. Section 524B, added by the Consolidated Appropriations Act, 2023 and effective March 29, 2023, turned cybersecurity from a guidance issue into a required premarket issue for covered devices.^[4][15][3] That line matters. It decides which devices must show cybersecurity evidence at the start and which submissions carry that burden.

Section 524B and the Definition of a Cyber Device

A cyber device is a device that includes sponsor-authorized software, can connect to the internet either directly or indirectly, and contains sponsor-authorized technology that could be open to cyber threats.^[21]

FDA reads these criteria broadly. The software piece does not stop at standard applications. It also includes firmware and programmable logic.^[7][1] And indirect connectivity counts too. So a device can still qualify even if it has no built-in Wi-Fi, as long as it connects through a hospital network or gateway system.^[1][18] Common examples include connected infusion pumps, imaging systems, remote monitoring devices, and implant programmers.^[4][14][16]

If a device fits that definition, the premarket submission must include:

• a plan to monitor, identify, and address postmarket vulnerabilities and exploits
• processes and procedures that provide reasonable assurance of cybersecurity across the device lifecycle
• a Software Bill of Materials (SBOM)^[21][22]

The SBOM should include enough detail to be useful and may be submitted in formats such as SPDX, CycloneDX, or SWID.^[17]

Which FDA Submissions Are Affected

Once a device qualifies as a cyber device, the next step is figuring out which FDA pathway needs cybersecurity support. Section 524B applies across the main FDA premarket routes when the product meets the cyber device definition. That includes 510(k) submissions, including special and abbreviated 510(k)s; Premarket Approval (PMA); De Novo; Product Development Protocol (PDP); and Humanitarian Device Exemption (HDE) applications, along with PMA and HDE supplements.^[21]

In plain terms, cybersecurity documentation is not a side note. It sits inside the submission package and can affect clearance, approval, or classification.^[2][16]

For devices outside Section 524B, FDA guidance still sets the baseline in practice. A simple way to think about it: Section 524B is the hard rule for cyber devices, while FDA guidance shapes what FDA expects for other software-enabled devices.^[5][11] Those rules set up the kind of premarket evidence FDA looks for next.

Premarket Requirements: Building Cybersecurity into Device Design

FDA’s 2023 guidance says cybersecurity has to be part of device design from day one.^[21][12] The Secure Product Development Framework (SPDF) is the lifecycle model FDA points to for managing device cybersecurity. Section 524B sets the legal baseline, and the guidance spells out what evidence manufacturers need to show in a submission.^[7][11]

SPDF, Threat Modeling, and Secure Architecture

The SPDF has three main parts: security risk management, security architecture, and cybersecurity testing.^[5][24] In plain terms, risk management is about finding and controlling confidentiality, integrity, and availability risks using vendor risk assessment solutions using an ISO 14971-aligned process. Security architecture is the set of design choices around authentication, authorization, encryption, logging, and secure software updates. Cybersecurity testing is how you check the work, including vulnerability scanning, fuzzing, and penetration testing.^[5][24]

Threat modeling is the starting point. FDA expects manufacturers to identify key assets, likely actors, and possible entry points, then map trust boundaries, such as where data moves from a hospital network into the device or from the device to a cloud service. From there, the team needs to decide which controls belong at each boundary. That means walking through attack scenarios too. For example, what happens if someone tries to push a malicious firmware update or change alarm thresholds? The design should show that controls would stop it or flag it. Those threat modeling outputs should connect straight to architecture choices, specific mitigations, and the test cases used to check them.^[11][5][24]

Cybersecurity controls also need their own documentation, separate from safety controls. The reason is simple: they deal with different kinds of risk, different records, and different test methods. That analysis then feeds into the submission materials FDA reviews.

What to Include in the Premarket Submission

For a cyber device, the premarket submission should make it easy to see how cybersecurity risks were found and handled. At a minimum, that includes:

• A cybersecurity risk analysis with a clear method, such as STRIDE, that ties threats to specific mitigations and shows residual risk is acceptable in the clinical setting
• Architecture diagrams showing data flows, trust boundaries, and where controls sit^[11][5][23]

Manufacturers should also include vulnerability testing results, plus verification and validation records showing that controls work in normal conditions and under attack or failure scenarios.^[5][24] The submission should also explain how the device handles software updates and patches in a secure way. Manufacturers can streamline this documentation process using automated security questionnaire tools.

For Section 524B devices, the SBOM needs to cover commercial, open-source, and off-the-shelf components. It should include version information and be machine-readable in formats such as CycloneDX or SPDX.^[25][26] Even when a device does not fall under 524B, an SBOM still helps show a mature security process.

These premarket materials also set up the monitoring and patching work that continues after the device is on the market.

Postmarket and Total Product Lifecycle Obligations

FDA clearance or approval does not end cybersecurity duties. Section 524B requires a postmarket plan to monitor, identify, and address vulnerabilities. Those duties start at deployment and continue through end of support. Recent hospital inventories show KEVs are still common across deployed devices. Once a device ships, the focus moves from design evidence to active field surveillance.

Monitoring, Coordinated Vulnerability Disclosure, and Patching

Manufacturers need to monitor threats on a continuous basis, run a public CVD process, and patch vulnerabilities on a risk-based timeline. In plain terms, that means watching threat intelligence feeds, software supplier alerts, and vulnerability databases, while also keeping a clear reporting channel open so security researchers and healthcare organizations can flag issues safely. Many manufacturers rely on a PSIRT to handle intake and triage.

The next step is triage: do current controls bring risk down enough, or is a patch needed? FDA’s postmarket guidance says manufacturers should communicate with healthcare organizations quickly after finding a vulnerability, including any interim compensating controls and a remediation plan.^[34][30][31] If an issue creates uncontrolled patient risk, out-of-cycle emergency patches should go out as soon as possible. Lower-severity issues can move through the normal maintenance release cycle.^[5][11] FDA may allow security fixes through existing change-control processes, as long as those fixes do not change intended use or add new risks.^[10][9]

Section 524B also requires a formal coordinated vulnerability disclosure (CVD) policy.^[2][5][27] That policy should be public, explain how to report a vulnerability, set response timelines, and spell out how the manufacturer will work with reporters on disclosure. The day-to-day tasks may shift over time, but the manufacturer’s duty stays in place.

Lifecycle Stages from Deployment to End of Support

Cybersecurity duties change as a device gets older, but they do not go away. The table below shows the main activities FDA expects or recommends at each stage of the total product lifecycle.

Older devices need their own risk posture because patching alone often stops being enough. Many still depend on hard-coded credentials, which helps explain why they show up so often in high-severity vulnerability and ransomware lists.^[29][13] When a device can no longer be secured, FDA and IMDRF recommend targeted compensating controls, clear communication about residual risk, and a concrete retirement plan.^[32][33][34] For HDOs, network isolation and decommissioning timelines are active risk management choices, not back-office tasks. HDOs need matching controls to carry out these duties in practice.

FDA-Aligned Risk Controls and How Healthcare Organizations Can Put Them into Practice

FDA rules only help when HDOs turn them into day-to-day controls. That’s the hard part, and it’s where a lot of risk shows up. For most teams, the issue isn’t knowing the rule. It’s turning that rule into device inventory, access control, logging, segmentation, and patching steps that people can follow every day.

Risk Assessment Methods and Control Categories

FDA guidance points to critical medical device security risks: authentication, authorization, cryptography, code/data/execution integrity, confidentiality, event detection and logging, resiliency and recovery, and updatability and patchability. Each one helps cut clinical risk when the HDO puts it into practice.^[38]

In plain terms, that means using unique, role-based accounts for clinical users, encrypting data in transit between devices and clinical systems, and limiting configuration changes to approved administrators with audit trails.^[35][36] If a device can be changed, someone should know who changed it, when, and why. In a hospital, that kind of recordkeeping isn’t just an IT issue. It can affect patient care.

Logging and update processes need the same level of discipline. HDOs should centralize device logs in a SIEM, require secure remote update support, and ask vendors to spell out patch processes and rollback options during procurement and risk review.^[5][8] That last part matters more than it may seem. A patch that can’t be reversed can turn a security fix into a clinical headache.

Network segmentation is another core control. Using dedicated VLANs, firewalls, and network access control helps isolate medical and IoT devices from general IT infrastructure.^[19][6] Think of it like watertight doors on a ship: if one area has a problem, you don’t want the whole vessel taking on water.

Risk scoring also has to reflect both cyber risk and patient harm. HDOs should combine exploitability with the severity of patient impact when setting remediation priorities.^[42][2][39] CVSS-style scoring, paired with patient-impact scoring, helps keep those priorities tied to both technical severity and clinical safety.^{[20][41][42][39]} A flaw that looks moderate on a security scale may still deserve urgent attention if it touches a device used in time-sensitive care.

Managing Device Risk with Censinet RiskOps™

For HDOs trying to manage all of this in one place, spreadsheets and email chains hit a wall fast. A 2022 GAO report found that critical vulnerabilities were common across hospital-connected devices, with an average of 6.2 vulnerabilities per medical device.^[40]

Censinet RiskOps™ gives HDOs one workflow for device risk work. It supports medical device inventory management, standardized assessments through questionnaires such as the MDS2 (Manufacturer Disclosure Statement for Medical Device Security), SBOM documentation, and remediation tracking. It also lets vendors work inside the same platform.^[37][7][28]

Censinet AI™ can speed questionnaire intake by summarizing vendor responses and evidence. That helps teams keep assessments, remediation work, and supporting evidence lined up as devices move from deployment through end of support.

Conclusion: A Clear Path to FDA Cybersecurity Compliance

FDA cybersecurity rules are not some separate box to tick. They sit inside the core standard for device safety and effectiveness. In plain terms, FDA treats cybersecurity as part of device safety across the full product lifecycle, not as a one-time filing task. Since March 29, 2023, Section 524B has set clear statutory duties for cyber device manufacturers, and failing to meet them can lead to prohibited-act enforcement under the FD&C Act.^[33]

Compliance takes more than paperwork. It calls for secure design, lifecycle monitoring, and timely fixes. Manufacturers need to show secure design, testing, patching, and end-of-support planning across the lifecycle. And that job does not stop once a device gets cleared. HDOs have to put those requirements into day-to-day practice.

The numbers make that plain. 23% of medical devices have at least one known exploited vulnerability, and 14% run on an unsupported or end-of-life operating system.^[43] So HDOs cannot lean on manufacturers alone. They need current device inventories, cybersecurity requirements built into procurement, network segmentation for high-risk devices, and joint risk assessments with manufacturers - plus proof that the work happened.

For HDOs, that comes down to a repeatable workflow for inventory, assessment, and remediation. Censinet RiskOps™ supports third-party and enterprise risk assessments, cybersecurity benchmarking, and shared risk management across medical device and vendor workflows. That kind of day-in, day-out discipline is what keeps compliance real after deployment.

FDA cybersecurity compliance starts with the first design choice and continues through the last day a device stays in service. Organizations that manage it with evidence and shared accountability protect patients while meeting FDA expectations.

FAQs

How do I know if a device is a cyber device?

Under Section 524B of the FD&C Act, a device counts as a cyber device if it:

• includes manufacturer-authorized software
• connects, directly or indirectly, to the internet or another network
• has features that cybersecurity threats could exploit

The FDA reads connectivity broadly. That means it’s not limited to internet access in the usual sense. It can include Wi-Fi, Bluetooth, cellular, USB, serial connections, and debug ports.

That broad view also reaches devices with dormant modules, remote servicing features, or embedded firmware. So even if a device doesn’t look “online” at first glance, it may still fall within this category.

What must manufacturers include in an FDA submission?

Under FD&C Act Section 524B, premarket submissions must include three core elements:

• a postmarket cybersecurity plan
• evidence of lifecycle security processes
• a machine-readable SBOM

Those items are backed by about 12 eSTAR documents, including risk management reports, security architecture diagrams, testing results, and cybersecurity labeling.

Miss one of these pieces, or fail to show enough cybersecurity assurance, and the FDA may reject the submission.

What should hospitals do after a device is deployed?

After deployment, hospitals should make the device part of enterprise risk management. In plain terms, that means treating it like any other connected system that could affect patient care, uptime, and security.

That work usually includes:

• Keeping asset inventories up to date
• Using network segmentation
• Coordinating patching with manufacturers
• Requesting an SBOM to track vulnerabilities

Hospitals should also follow the manufacturer’s cybersecurity labeling. That includes secure configuration baselines, reporting suspected issues through the manufacturer’s CVD process, and using tools like Censinet RiskOps™ to streamline vendor evaluations, risk mapping, and threat monitoring.

Related Blog Posts

• 5 Key Premarket Cybersecurity Requirements for Devices
• FDA Cybersecurity Design Controls: Key Requirements
• Minimum Cybersecurity Standards for Medical Device Suppliers
• How FDA Guidance Adopts NIST Cybersecurity Standards