Medical Devices
Premarket and postmarket cybersecurity requirements
Medical device manufacturers face increasing FDA cybersecurity requirements throughout the product lifecycle. Thalorin supports medical device compliance from design controls through postmarket surveillance, addressing premarket submission requirements and ongoing vulnerability management.
Medical device cybersecurity became a statutory premarket requirement rather than a guidance expectation when Section 524B was added to the Federal Food, Drug, and Cosmetic Act. Sponsors of cyber devices must submit a plan to monitor, identify, and address postmarket vulnerabilities and exploits, design and maintain processes providing reasonable assurance the device and related systems are cybersecure, make updates and patches available, and provide a software bill of materials covering commercial, open source, and off-the-shelf components.
FDA gained authority to refuse to accept submissions that do not meet these requirements, which converted cybersecurity from a review comment into a gating item. Submissions have been refused on this basis, and the remedy is a resubmission cycle rather than a conversation.
The SBOM requirement has proven the most operationally demanding, because it obliges manufacturers to know what is in their software — including transitive dependencies in third-party and open source components — and to keep that knowledge current as the product evolves. Many organisations discovered at submission that they could not produce one accurately.
Postmarket obligations continue for the device's life. Thalorin binds the SBOM to the vulnerability feed and to the device version it describes, so a newly disclosed vulnerability resolves to the affected devices rather than to a manual search.
Healthcare faces mounting cybersecurity challenges
Cybersecurity gates the submission
FDA may refuse to accept a premarket submission that does not meet Section 524B requirements. A deficiency here costs a resubmission cycle, not a review round.
SBOM accuracy including transitive dependencies
The bill of materials must cover commercial, open source, and off-the-shelf software components. Producing one that is accurate through transitive dependencies, and keeping it current, is a build-system problem before it is a documentation one.
Postmarket obligations run for the device lifetime
Monitoring, identifying, and addressing vulnerabilities continues long after clearance, across device versions that may be years apart and fielded simultaneously.
Patching constrained by clinical safety
Updates to a fielded device may require validation and cannot always be deployed on a security timetable. The tension between vulnerability response and clinical safety has to be managed explicitly.
How Thalorin helps
Premarket cybersecurity documentation
Maintain the software bill of materials as a build artifact covering commercial, open source, and off-the-shelf components, versioned with the device.
SBOM generation and management
Bind vulnerability intelligence to the SBOM so a disclosure resolves to affected device versions automatically.
Vulnerability disclosure coordination
Evidence the postmarket vulnerability monitoring and response plan Section 524B requires as an operated process.
Postmarket surveillance
Carry premarket submission cybersecurity documentation from the same state that governs postmarket operation.
FDA submission support
Track secure development lifecycle practices against IEC 62304 and related standards.
Design control integration
Manage EU MDR cybersecurity obligations alongside FDA requirements for devices reaching both markets.
Medical Devices: common questions
What does Section 524B require?
For cyber devices, sponsors must submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits; design, develop, and maintain processes and procedures providing reasonable assurance the device and related systems are cybersecure; make available postmarket updates and patches; and provide a software bill of materials including commercial, open source, and off-the-shelf components.
Can FDA reject a submission over cybersecurity?
Yes. FDA has authority to refuse to accept premarket submissions that do not meet the Section 524B requirements, and has exercised it. Because refusal to accept occurs before substantive review, the cost is a full resubmission cycle rather than a response to a deficiency letter.
What counts as a cyber device?
Broadly, a device that includes software validated, installed, or authorised by the sponsor, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. The internet connectivity element does substantial work in the definition, and manufacturers sometimes conclude too quickly that a device falls outside it.
How detailed must the SBOM be?
It must identify commercial, open source, and off-the-shelf software components, and FDA expects sufficient detail to support vulnerability management — component names, versions, and supplier information, in a machine-readable format. The practical bar is whether a newly disclosed vulnerability in a dependency can be resolved to your device, which requires transitive dependency coverage rather than a top-level list.
What if a patch would require revalidation?
That tension is expected and must be managed rather than avoided. The response plan should establish how vulnerability severity, exploitability, and clinical risk are weighed, what compensating controls apply while a patch is pending, and how communication to users and FDA occurs. Silence while a known vulnerability remains unpatched is the outcome the postmarket requirement exists to prevent.
Regulatory state described as of August 2026. Requirements change; verify against the current rule before relying on any date above.
Talk to us about Medical Devices.
See how one evidence artifact satisfies Medical Devices requirements alongside every other framework you carry.