If a connected medical device is sold in the U.S., FDA cybersecurity review is now part of market clearance. Since March 29, 2023, makers of FDA-defined cyber devices must show three things: a postmarket security plan, secure design and maintenance, and an SBOM. If they miss that, FDA can slow or stop review.
Here’s the short version: I’d treat this rule as a patient safety issue, not just an IT task. The article shows that medical device security risks were reported across 966 products in 2023, up 59% from 2022. It also ties hospital ransomware events to a 34–38% jump in in-hospital mortality during the first attack period. That’s why access control, patching, logging, and remote support rules matter.
If I had to boil the article down, it says you need to focus on:
- Scope first: decide whether the product is an FDA “cyber device”
- Premarket proof: provide threat models, test reports, architecture diagrams, and an SBOM
- Access control: use one account per person, role-based access, MFA for high-risk roles, session timeouts, and deny-by-default permissions
- Device and network checks: use certificates, TLS, network segmentation, 802.1X, and locked-down remote support
- Lifecycle work: keep patch, disclosure, and incident response processes in place through the supported life of the device
- Hospital action: keep an up-to-date inventory, map device owners, track firmware and network location, and set triage steps before an issue hits
A simple way to read the article is this: FDA wants proof that only the right people, systems, and support paths can touch a connected device - and that the maker can find and fix security problems after release.
That’s the frame I’d use for the rest of the piece.
FDA Cybersecurity Rules for IoT Medical Devices: Key Stats & Requirements
A Quick Primer on FDA's Final Guidance for Cybersecurity in Medical Devices
sbb-itb-535baee
How the FDA Defines a Cyber Device and What the Law Requires
Section 524B applies only to FDA-defined cyber devices. So the first job is simple: figure out whether the device fits that label. That decision sets the stage for the whole submission. It also decides whether identity, authorization, and remote access controls need to be documented as part of compliance.
Definition and Scope of a Cyber Device
Section 524B(c) of the FD&C Act defines a cyber device as a medical device that: (1) includes sponsor-authorized software used in or with the device; (2) has the ability to connect to the internet; and (3) has technical characteristics that create cybersecurity risk.[2][8]
FDA guidance takes "includes software" in a broad way. It covers firmware, programmable logic, embedded operating systems, and device software functions. Connectivity can be direct or indirect. That includes Wi‑Fi, Bluetooth, USB, hospital networks, remote service links, and companion apps.[8][6][12] Common examples are Wi‑Fi infusion pumps and networked monitors.[9][12][7]
Once a device falls within scope, the next step is figuring out which controls FDA wants manufacturers to show in their documentation.
The 3 Core Requirements Under Section 524B
Section 524B(b) places three core legal obligations on manufacturers of cyber devices.[16][18]
First, manufacturers need a postmarket cybersecurity monitoring and response plan. This is not a one-time document. It is an active process that runs through the device's supported life to identify, triage, and address vulnerabilities.[2][13]
Second, FDA expects secure design, development, and maintenance. That includes timely patches and updates, plus a defined process to validate and release fixes without hurting safety or clinical performance.[3][4][7]
Third, manufacturers must provide a Software Bill of Materials (SBOM). The SBOM covers software components, is machine-readable, usually in CycloneDX or SPDX format, and should include firmware, libraries, cloud services, and companion apps.[10][11]
Noncompliance is a prohibited act under the FD&C Act.[16]
What FDA Expects in Premarket Cybersecurity Documentation
Those duties need proof behind them. For 510(k), PMA, and De Novo submissions, FDA expects a structured cybersecurity evidence package. In plain terms, the agency wants to see how the device is built, where it could be attacked, what controls are in place, and how the manufacturer plans to deal with issues after clearance or approval.
That package usually includes system and network architecture diagrams that show connections and trust boundaries, threat models that lay out attack surfaces and risk controls, security test results such as penetration testing and static and dynamic analysis, and a vulnerability management plan that explains how issues will be handled after the product is on the market.[3][4][6] The evidence should line up directly with the controls used in deployment.
If the SBOM or postmarket plan is missing or thin, FDA may pause the review or send an information request.[12][14]
| 524B legal requirement | FDA guidance expectation | Manufacturer artifact |
|---|---|---|
| Postmarket cybersecurity monitoring and response | Defined processes for vulnerability intake, triage, disclosure, and remediation | Postmarket cybersecurity plan, PSIRT process, coordinated vulnerability disclosure policy |
| Secure design, development, and maintenance | Evidence of secure-by-design controls, update processes, and risk-based validation | Threat models, secure development records, test reports, patch and update procedures, authentication, authorization, and least privilege controls |
| Software Bill of Materials | Component transparency for commercial, open-source, and off-the-shelf software | SBOM in accepted format, component inventory, dependency records |
These requirements also shape access control. Identity, privilege, and remote access need to match the device's documented security design. The next section turns those legal requirements into specific access control safeguards.
Access Control Requirements for IoT Medical Devices
FDA access control expectations come down to three plain questions: who can sign in, what they’re allowed to do, and how the device checks identity. If access is weak, the result can be unsafe commands or unauthorized setting changes that affect therapy and patient safety.[17][23] That’s why identity, permissions, device trust, and logging need to work as one system.
Authentication, Authorization, and Least Privilege
Every user and every device that touches a connected medical device needs a verified identity. In practice, that means one account per person - no shared clinical logins and no hardcoded passwords. For higher-risk roles like system administrators and service technicians, FDA guidance recommends multi-factor authentication (MFA).[4][17][24]
Authorization answers a different question: what can that identity actually do? A clinician may be allowed to adjust therapy settings within a safe range, but that doesn’t mean they should be able to install firmware updates. A vendor support account may need access to a locked-down diagnostic interface, not the whole system. Use deny-by-default: if access is not clearly allowed, block it. Least privilege should apply to users, services, and device functions.[4][17][23]
Session control matters too. Idle session timeouts, re-authentication before high-risk actions, and separate permissions for local and remote access all help cut the chance that an unattended terminal turns into an easy way in on a busy hospital floor.[1][17]
Device and Network Controls in Healthcare Environments
User identity is only part of the job. Devices also need identities the network can verify. Certificate-based device identity with TLS and mutual authentication lets the network confirm that it’s talking to trusted devices and trusted back-end systems.[1][20][22]
On the network side, IoMT devices should be ready for segmented VLANs and firewall rules that allow only documented, needed inbound and outbound connections. They should support WPA2-Enterprise or WPA3-Enterprise with 802.1X, not shared keys.[1][20][22] Outbound traffic should be limited to known destinations, and manufacturers should give hospital IT teams clear network documentation so firewall setup doesn’t turn into guesswork.
Remote vendor support needs extra care. FDA-aligned guidance points to encrypted, time-limited access paths such as VPNs or mutually authenticated TLS tunnels, along with MFA, clear approval steps, and detailed logs of support activity.[1][20][21]
Mapping FDA Expectations to Technical Safeguards
The table below links specific access control mechanisms to FDA expectations and shows how each one touches patient safety.[1][17][22] These controls map directly to the technical safeguards summarized below.
| Access control mechanism | FDA design expectation | Patient safety impact |
|---|---|---|
| Unique user accounts and role-based access | Limit unauthorized use and support accountability | Reduces risk of unsafe commands or configuration changes |
| Device certificates or strong device identity | Verify trusted device communications | Reduces spoofing and unauthorized network access |
| Audit logging and time-stamped events | Support traceability and incident investigation | Improves response to misuse that could affect care delivery |
| Secure default settings | Reduce exposed services and weak initial access paths | Lowers preventable deployment risk in clinical settings |
| Encrypted remote access and update channels | Protect confidentiality and integrity of management actions | Helps prevent unsafe tampering during support or maintenance |
Audit logging deserves its own callout. Devices should record successful and failed login attempts, configuration changes, firmware updates, privilege escalations, and remote support sessions, all with synchronized, tamper-resistant timestamps and event records.[4][17] Those logs should be exportable to hospital SIEM systems through standard formats like syslog or secure APIs. Access to the logs also needs control, because log data can expose sensitive patient information if left open.[1][17]
Devices should ship with unnecessary services turned off, unique first-use credentials, and conservative network defaults. These measures are part of a broader strategy to simplify vendor risk assessments across the supply chain.
These safeguards also need to show up in design records, test results, and postmarket plans.
Secure Design, Risk Management, and Lifecycle Evidence
FDA expects cybersecurity controls to be designed, tested, and maintained across the device lifecycle.[26][19] It’s not enough for a device to seem secure. The manufacturer also needs to show clear proof.
Secure-by-Design Controls the FDA Expects to See
Access control only holds up when the device is built to enforce it. That means cybersecurity needs to be part of the architecture from day one: secure boot, signed updates, encryption, device hardening, and unnecessary services turned off.
FDA looks at both device-native controls, like secure boot and signed updates, and network controls, like segmentation and firewall rules. Manufacturers should address both in their design documentation.
Those controls also need to connect to believable threat scenarios. A control without a clear threat behind it doesn’t say much.
Risk Management: From Threat Modeling to Postmarket Response
Start with a threat model that identifies assets, trust boundaries, attackers, and attack paths. Then tie each mitigation to a specific threat. For example:
- Network segmentation helps limit lateral movement
- Signed updates help prevent firmware tampering
- Role-based access helps reduce unauthorized use
The tie to patient safety needs to be direct. If an attacker can change therapy settings or shut off monitoring, that creates clinical risk, not just an IT issue.
FDA links cybersecurity risk analysis to software validation under 21 CFR 820.30(g). Manufacturers must assess both the likelihood of exploitation and the effect on device function and patient safety.[15]
Between June 2013 and January 2025, the FDA issued 18 cybersecurity safety communications covering medical device vulnerabilities, with about 94% classified as high-risk.[27] FDA also expects a coordinated vulnerability disclosure process. That includes acknowledging receipt of vulnerability reports, setting remediation timelines, and notifying customers.[25][5]
Patch governance matters too. Before anything goes into production, there should be steps for testing, approval, rollback, and post-update verification.
Documentation That Supports Audits, Procurement, and Deployment
These controls only go so far if the manufacturer can’t document them. The artifacts below support audits, procurement, and deployment.
| Design or evidence artifact | FDA relevance | IoT-specific use in healthcare operations |
|---|---|---|
| Threat model | Shows foreseeable threats and mitigations | Helps HDOs understand likely attack paths in clinical networks |
| SBOM | Supports component transparency and vulnerability tracking | Confirms whether a newly announced CVE affects devices in the fleet |
| Penetration test report | Demonstrates security validation depth | Informs procurement and compensating control decisions |
| Secure deployment labeling | Supports safe implementation and maintenance | Guides segmentation, credential handling, and service configuration |
| Patch and update governance record | Shows maintenance and remediation readiness | Helps clinical engineering plan downtime, testing, and rollout |
Keep SBOMs current and pair them with version information. Penetration test reports should show scope, attack scenarios, findings, and remediation status, including whether testing was repeated after fixes were applied. Secure deployment labeling should cover credential handling, supported network configurations, logging setup, and decommissioning steps.
Healthcare teams use this evidence to evaluate vendors, plan deployment, and track risk over time. Censinet RiskOps™ can help healthcare organizations collect, compare, and track this evidence across vendors and teams.
How Healthcare Organizations Can Act on FDA Rules
Once the FDA requirements are clear, healthcare organizations need a day-to-day way to keep device inventory, risk, and ownership in sync. Manufacturers supply the evidence. Healthcare organizations use that evidence to manage devices already in use.
Build a Working Model for IoT Medical Device Cyber Risk
The first step is simple: know exactly what you have.
An accurate, regularly updated device inventory is the base for risk scoring, segmentation checks, patch planning, and procurement review. Track each device’s model, serial number, firmware version, connectivity, network segment, patient impact, and Section 524B status. That inventory should also link to the device’s authentication method, access scope, and remote support path.
Use passive network discovery to build and maintain the inventory without disrupting clinical equipment. Then use that data to assign owners, confirm required controls, and speed up incident response.
When new vulnerabilities show up, that inventory becomes the starting point for triage, isolation, and remediation.
Set escalation paths before a vulnerability appears. Create a documented triage workflow across security operations, PSIRT, clinical engineering, and clinical leadership based on exploitability, patient impact, and patch availability.[2][16] If a vulnerability may trigger Section 524B obligations, bring in regulatory and compliance teams too.[8][16] For high-risk findings, the workflow should include time-bound actions such as:
- rapid risk assessment
- interim safeguards like network isolation
- communication to affected clinical units
- documented decisions in the risk and incident registers
Use Structured Risk Assessments and Vendor Collaboration
Checking a manufacturer’s cybersecurity maturity during procurement takes more than reading a product brochure.
HDOs should use structured questionnaires tied to FDA premarket guidance and Section 524B requirements. Those reviews should cover secure development practices, SBOM completeness, vulnerability disclosure processes, patch management, and incident response integration.[1][2][18] Ask for sample threat models, penetration test reports, secure-by-design controls, and deployment guidance instead of relying on vendor claims.
Use that evidence to decide whether a device should be allowed onto the network, not just whether it should be bought.
Censinet RiskOps™ can centralize medical device and vendor risk assessments, benchmark cybersecurity posture, and track remediation tasks across procurement and post-deployment workflows.
Those same review criteria should carry through to contracting, deployment approval, and ongoing monitoring.
Conclusion: The Controls and Evidence That Matter Most
Putting FDA cybersecurity rules into daily work starts with clear ownership across the organization. The table below shows the main operating priorities.
| Priority area | Why it matters | Owner in the organization |
|---|---|---|
| Cyber device determination | Establishes whether 524B applies | Regulatory, product, legal |
| Access control | Prevents unauthorized actions that can affect care | Security, IT engineering, clinical engineering |
| Design and lifecycle evidence | Supports premarket review, audits, procurement, and remediation tracking | Product security, engineering, quality, compliance; reviewed by HDO security and procurement |
| Postmarket monitoring and response | Reduces patient safety and disruption risk | PSIRT, security operations, clinical engineering |
Inventory drives risk scoring. Risk scoring drives segmentation. And segmentation relies on documented access control. Keep that model current through standing cross-functional governance.
FAQs
How do I know if a device is an FDA cyber device?
Under Section 524B of the FD&C Act, a medical device is a cyber device if it:
- contains software or firmware validated or authorized by the manufacturer
- can connect, directly or indirectly, to the internet or other networks
- has features that cyber threats could exploit
Connectivity is defined broadly. It includes Wi-Fi, cellular, Bluetooth, Ethernet, USB, serial, and inductive communications.
That scope is broader than many teams first expect. A device doesn't need to be always online to fall under this section. Devices with dormant wireless modules, debug ports, or remote servicing features are generally also in scope.
What happens if a manufacturer submits without an SBOM or postmarket plan?
If a manufacturer submits a device without a cybersecurity management plan that includes an SBOM and postmarket procedures, the device can't receive FDA market authorization.
Leave out those required pieces, and the submission may hit a technical screening hold or get a Refuse to Accept (RTA) decision. That can delay market entry.
And it doesn't stop at launch. If the manufacturer fails to maintain those items after the product goes to market, that may also be a prohibited act under the FD&C Act.
What should hospitals track first to manage IoT device cyber risk?
Start with a full inventory of every clinical device you use. Include the device type, manufacturer, model, serial number, software and firmware versions, operating system, network identifiers, clinical owner, risk classification, and data classification.
Then map how each device connects to EHRs, PACS, hospital networks, and mobile devices. That way, when a new vulnerability shows up, you can quickly spot which devices may be affected.
