Key takeaway
Connected medical devices sold in the US must meet section 524B, and FDA updated its cybersecurity guidance in February 2026. What a 510(k) needs, how the EU compares, and lessons from Ypsomed's Mark Phillip Loria.
Short answer: If a device runs software and can connect to the internet, the FDA treats it as a "cyber device" under section 524B of the FD&C Act. Its 510(k), De Novo or PMA must include a plan to monitor and fix vulnerabilities after launch, processes that keep the device and related systems cybersecure, and a software bill of materials (SBOM). FDA's guidance, updated in February 2026, also expects threat modeling, a security risk assessment, architecture views and penetration testing. Submissions without this information are put on hold before review starts.
Under section 524B, a cyber device is one that includes software validated, installed or authorised by the manufacturer, can connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. That covers a growing share of products: connected injectors, insulin pumps, wearables, apps that control devices and software as a medical device.
The law applies to 510(k), De Novo, PMA, PDP and HDE submissions, including Special and Abbreviated 510(k)s and PMA supplements.
Section 524B sets four requirements. Manufacturers must:
FDA's guidance explains what evidence it expects in the submission:
The SBOM is a common sticking point. One cybersecurity consultancy reviewed more than 30 FDA deficiency letters its own clients received up to August 2026 and found the SBOM raised in 90% of them, with security controls, labeling and testing each raised in 70% (Blue Goat Cyber, October 2026). FDA does not publish its own figures.
On 2 February 2026, FDA's Quality Management System Regulation (QMSR) replaced the old Quality System Regulation and incorporated ISO 13485:2016. The next day, FDA issued an updated version of its cybersecurity guidance, renamed "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions". It maps security risk management to ISO 13485 clauses instead of the old Part 820 subsections. It replaces the June 2025 version, which had added a section on cyber devices and section 524B.
Failing to maintain the cybersecurity processes required by section 524B(b)(2) is a prohibited act under the FD&C Act, and missing cybersecurity information in labeling can make a device misbranded.
At the 5th Digital Health Conference in Madrid in October 2025, Mark Phillip Loria, Digital Health Technology Manager at Ypsomed, described how his team handled FDA cybersecurity questions during a 510(k) review and reached a successful outcome under time pressure. He framed it as an Apollo 13 mission, with three challenges.
The question behind the question. FDA's questions can be read through regulatory, technical and other lenses, and teams can misjudge what the reviewer actually expects. His advice: put the right task force on it at the right moment, use external reviews for calibration, and accept that "There's no shortcut — this is where preparation delivers its return".
One mission, many lenses. Many stakeholders bring different priorities, and decisions must be fast but grounded in evidence. Loria's team communicated a master plan early, worked in person in sprints, and set up a dedicated "situation room". He also stressed that "Being sharp on intended purpose is key", especially for platforms and ecosystems.
Timing the burn. Teams struggle between technical perfectionism and pragmatic delivery, and cybersecurity maturity cannot be built overnight. His tips included a single source of truth across tools and mock reviews before submission. His most practical line:
"Write for your future reviewer – assume regulatory readers know nothing and have no time"
Mark Phillip Loria, Ypsomed, 5th Digital Health Conference, October 2025
His strategic advice looked beyond one submission: "Expect the bar to rise — future readiness depends on today's culture", and "Build pressure-tested systems — not pressure-intolerant heroes".
In the EU, cybersecurity for medical devices sits in the MDR and IVDR. Annex I requires software to be developed according to the state of the art, including information security, and requires manufacturers to set minimum IT security measures, including protection against unauthorised access. Guidance MDCG 2019-16 (revised July 2020) explains how to meet these requirements.
The EU Cyber Resilience Act, which applies to most connected products from 11 December 2027, explicitly excludes devices covered by the MDR and IVDR. That may change in part: the Commission's December 2025 proposal to revise the MDR and IVDR would write cybersecurity explicitly into Annex I and require manufacturers to report actively exploited vulnerabilities to national cybersecurity authorities and ENISA. It is still a proposal.
For other EU rules affecting connected devices, see When Does the EU AI Act Apply to Medical Devices?.
Header photo: Irwan on Unsplash.
A device that includes software validated, installed or authorised by the manufacturer, can connect to the internet, and has characteristics that could be vulnerable to cybersecurity threats, as defined in section 524B of the FD&C Act.
Yes, for cyber devices. Section 524B requires a software bill of materials that includes commercial, open-source and off-the-shelf software components.
Since October 2023, an eSTAR submission without accurate responses and attachments in the cybersecurity section is put on a technical screening hold.
"Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions", dated 3 February 2026, which replaced the June 2025 version.
No. Devices covered by the MDR and IVDR are excluded; their cybersecurity requirements come from those regulations and MDCG 2019-16.
The Digital Health Conference, organised by UBIQ Events, brings together pharma, MedTech and digital health leaders to discuss digital therapeutics, connected devices, AI and regulation.
