Medical Device Cybersecurity
Medical device cybersecurity covers the design controls, premarket documentation, and post-market vigilance manufacturers apply to protect connected and software-enabled devices from cyber threats that could compromise safety, effectiveness, or data. FDA’s 2025 premarket cybersecurity guidance and international standards such as IEC 81001-5-1 formalise expectations that were, for years, applied more loosely under general design-controls and risk-management requirements.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 21 LINKSFor a connected device, security became a safety property: an exploitable vulnerability is a hazard, which puts it inside risk management rather than beside it, and puts patching inside the quality system.
06 · QUALITY MATURITY — MEDICAL DEVICE CYBERSECURITY, REACTIVE TO ADAPTIVE
Security is addressed at submission and then owned by nobody. There is no inventory of what the device is built from.
A threat model and a software bill of materials exist, both produced for the submission and neither maintained since.
The bill of materials is kept current, disclosed vulnerabilities are triaged against actual exploitability in this device, and patching runs through change control.
Monitoring is continuous and the response time is a controlled parameter; the coordinated disclosure route is published and has been used.
Security is a design property — architecture limits blast radius, updates are deliverable safely in the field — so a new vulnerability is an operational event rather than a crisis.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 3
Derived from the 3 standards SPEQ maps to this subject, across 3 regulatory bodies: EC, IEC, FDA.
RECORDS & OBJECTIVE EVIDENCE
- The software bill of materials, with its currency date and update mechanism
- The threat model, and the security risk assessment linking findings to patient harm
- Vulnerability triage records showing exploitability assessed in this device’s context
- The patch and update pathway, including how updates reach deployed devices
- The coordinated vulnerability disclosure process, and its use
COMMON INSPECTION FINDINGS
- A bill of materials produced for submission and never updated
- Vulnerabilities triaged on severity score alone with no assessment of exploitability in the device
- No route to update deployed devices, so a known vulnerability cannot be remediated in the field
- Security findings held outside the risk-management file, so they never reach harm assessment
- Third-party and open-source components with no supplier or provenance controls
Why Cybersecurity Became a Distinct Device-Safety Domain
As devices increasingly connect to networks, hospital systems, or the internet — for remote monitoring, software updates, or interoperability — the attack surface for compromising device safety or patient data grew beyond what traditional hazard analysis, focused on mechanical and electrical failure modes, was built to address. A cybersecurity vulnerability can produce patient harm through a mechanism (unauthorised control, data manipulation, denial of service) that has no analogue in classical device failure-mode analysis.
Regulators responded by making cybersecurity an explicit, named element of premarket submissions and quality-system design controls for devices with cyber risk, rather than leaving it to be inferred from general safety-and-effectiveness requirements.
Premarket Expectations
FDA’s premarket cybersecurity guidance directs manufacturers of devices meeting the statutory definition of a “cyber device” to submit a cybersecurity plan covering the device’s security architecture, a software bill of materials, a vulnerability and risk-management process, and evidence of security testing (such as penetration testing) appropriate to the device’s risk. The expectation is that cybersecurity risk management is integrated into, not appended after, the device’s overall design-controls process.
IEC 81001-5-1 provides a process standard specifically for health-software and health-IT-system security in the product lifecycle, complementing (rather than replacing) general device design-controls and risk-management requirements.
Post-Market Lifecycle Obligations
Cybersecurity does not end at clearance or approval: manufacturers are expected to maintain a vulnerability-monitoring and disclosure process, apply coordinated vulnerability disclosure practices, and issue security patches or updates as new threats emerge — treating a fielded device’s security posture as something that must be actively maintained across its commercial life, not fixed permanently at launch.
Where a security update or vulnerability affects device safety or effectiveness, existing complaint-handling, corrections-and-removals, and vigilance-reporting obligations may be triggered exactly as they would for a non-cyber quality issue.
SPEQ Interpretation — Where This Intersects Traditional QMS
Cybersecurity risk management does not replace ISO 14971 risk management; the two are meant to run in parallel, with cybersecurity risks assessed and mitigated within the same overall risk-management framework a device already maintains for safety hazards, while drawing on security-specific methods (threat modelling, penetration testing) that classical hazard analysis does not itself provide.
FREQUENTLY ASKED
Does every medical device need a cybersecurity submission?
FDA’s premarket cybersecurity expectations apply to devices meeting the statutory “cyber device” definition — broadly, devices with software, the ability to connect to the internet, and technological characteristics that could be vulnerable to cybersecurity threats. A fully mechanical, non-connected device would not typically trigger these specific requirements.
What is a software bill of materials (SBOM) and why does it matter for cybersecurity?
An SBOM is an inventory of the software components — including third-party and open-source components — that make up a device’s software. It matters because a newly disclosed vulnerability in a widely used component can only be assessed for relevance quickly if the manufacturer knows exactly where that component is used across its device portfolio.
How does device cybersecurity relate to a hospital’s own IT security?
They are related but distinct: the manufacturer is responsible for the device’s inherent security design and its own vulnerability management, while the healthcare delivery organisation is responsible for the network and IT environment the device operates within — effective device security typically depends on both being addressed, which is why manufacturers publish security documentation to support hospital IT risk assessments.