Medical Device Cybersecurity Compliance: From Threat Modeling to Market Access

The proliferation of connected medical devices has fundamentally altered the cybersecurity threat landscape for manufacturers. Devices that once operated as standalone electromechanical systems now incorporate wireless connectivity, cloud integrations, mobile companion applications, and interoperable data exchanges with hospital information systems. This expanded attack surface introduces risks that did not exist a generation ago: ransomware that can disable infusion pumps across an entire hospital network, vulnerabilities in third-party software components that expose patient data, and firmware exploits that compromise the intended performance of diagnostic algorithms. The healthcare sector has become one of the most targeted industries for cyberattacks, with threat actors ranging from financially motivated ransomware groups to nation-state actors seeking access to sensitive patient data and critical infrastructure. Medical devices present particularly attractive targets because they often operate with long product lifecycles, run on legacy operating systems that may no longer receive security updates, and exist in hospital network environments where segmentation and monitoring are inconsistent. Regulators worldwide have responded with increasingly prescriptive cybersecurity requirements, and manufacturers who treat cybersecurity as an afterthought or a box-ticking exercise face not only patient safety risks but also significant delays in obtaining market clearance. For medical device organisations, cybersecurity compliance is no longer optional and no longer separable from the core product development process. It must be embedded into the software lifecycle from the earliest design stages and maintained throughout the entire product lifetime. The consequences of inadequate cybersecurity extend beyond regulatory rejection: a compromised device can cause direct patient harm, trigger mandatory field safety corrective actions, expose the manufacturer to product liability claims, and inflict lasting reputational damage in a market where trust is the fundamental currency.

The regulatory framework for medical device cybersecurity has matured considerably across both the European Union and the United States, and manufacturers targeting global markets must satisfy requirements from multiple jurisdictions simultaneously. In the EU, the Medical Device Regulation establishes cybersecurity as a fundamental component of device safety through its General Safety and Performance Requirements. Annex I of the MDR requires that devices incorporating electronic programmable systems, software, or connected devices be designed to ensure repeatability, reliability, and performance in line with their intended use, and it explicitly mandates that manufacturers address risks associated with the interaction between software and the IT environment in which it operates. Notified Bodies assess cybersecurity as part of the conformity assessment procedure, and an inadequate cybersecurity strategy is grounds for withholding CE marking. In the United States, the FDA has issued comprehensive premarket cybersecurity guidance that applies to all devices with software functions, connected capabilities, or the ability to receive software updates. The FDA treats cybersecurity as a component of device safety and effectiveness and expects manufacturers to submit a cybersecurity management plan, a threat model, security architecture documentation, and a Software Bill of Materials as part of the premarket submission. Section 524B of the Federal Food, Drug, and Cosmetic Act further codifies these requirements into law, mandating that manufacturers maintain the cybersecurity of their devices throughout the total product lifecycle. Manufacturers who develop a unified cybersecurity strategy that satisfies both EU and FDA expectations from the outset avoid costly rework and duplicative documentation efforts.

IEC 81001-5-1 has emerged as the cornerstone international standard for cybersecurity in medical device software and health IT systems. Developed as a companion to IEC 62304 (the established software lifecycle standard for medical devices), IEC 81001-5-1 provides a structured framework for integrating security activities into every phase of the software development lifecycle. The standard is organised around key process areas: security requirements management, security risk management, secure design and architecture, secure implementation, security verification and validation, security update management, and security guidance documentation. For manufacturers already following IEC 62304, IEC 81001-5-1 represents a natural and deliberate extension rather than a parallel compliance burden. Where IEC 62304 addresses software safety through lifecycle process rigour, IEC 81001-5-1 addresses software security through analogous process disciplines applied to cybersecurity-specific concerns. The standard requires manufacturers to establish a security risk management process that identifies assets worth protecting, enumerates potential threats, assesses vulnerabilities, evaluates the likelihood and impact of exploitation, and defines risk controls. It further requires that security requirements be derived from this risk analysis and traced through the design, implementation, and testing phases, creating a security-specific traceability chain that mirrors the safety traceability chain already required by IEC 62304. For organisations seeking CE marking under the MDR, demonstrating conformity with IEC 81001-5-1 provides a presumption of conformity with the cybersecurity aspects of the General Safety and Performance Requirements, making it the most efficient path to regulatory acceptance in Europe.

Threat modeling is the analytical foundation upon which all downstream cybersecurity activities rest, and medical device manufacturers must adopt a systematic methodology that accounts for the unique characteristics of healthcare environments. The STRIDE framework, originally developed for general software security, can be effectively adapted for medical devices when augmented with healthcare-specific threat categories. STRIDE classifies threats into six categories: Spoofing (impersonation of a legitimate user or device), Tampering (unauthorised modification of data or code), Repudiation (denial of having performed an action), Information Disclosure (exposure of protected data), Denial of Service (disruption of device availability), and Elevation of Privilege (gaining unauthorised access levels). When applying STRIDE to a medical device, the threat model must consider the device within its full operational context, including the clinical environment, the network infrastructure, the cloud services it communicates with, the mobile applications that control or configure it, and the data flows between all of these elements. Medical device threat models must give particular weight to threats that could compromise patient safety, such as tampering with therapy delivery parameters, spoofing device identity to inject malicious commands, or denial-of-service attacks that render a critical care device unavailable during a procedure. The output of the threat modeling exercise should include a comprehensive data flow diagram, an enumeration of all identified threats mapped to specific device components and interfaces, a risk assessment for each threat considering both the likelihood of exploitation and the severity of clinical impact, and a set of security requirements that define the controls necessary to mitigate each identified risk. This threat model is a living document that must be revisited whenever the device architecture changes, new vulnerabilities are disclosed in component technologies, or the threat landscape evolves. Many manufacturers find it useful to conduct threat modeling workshops that bring together software engineers, systems architects, clinical specialists, and cybersecurity experts, as this cross-functional perspective is essential for identifying threats that a purely technical analysis would miss. The clinical engineer may recognise that a particular data flow carries therapy-critical parameters, while the cybersecurity specialist identifies that the same data flow traverses an unencrypted network segment. Together, they can assess the combined safety and security risk in a way that neither discipline could achieve alone. The threat model should also consider the full range of threat actors relevant to the device, including malicious insiders with physical access, opportunistic attackers exploiting known vulnerabilities, sophisticated adversaries targeting specific devices or healthcare organisations, and unintentional threats from misconfigured IT environments or untrained clinical users.

Secure design principles must be embedded into the device architecture from the earliest stages of development, not retrofitted after implementation. The principle of defence in depth requires that multiple independent layers of security controls protect critical assets, so that the compromise of any single control does not lead to a complete security failure. For a connected medical device, this might mean combining network segmentation, transport layer encryption, mutual authentication, input validation, and runtime integrity verification to protect the communication channel between the device and a cloud management platform. The principle of least privilege dictates that every software component, user role, and external interface should operate with the minimum permissions necessary to fulfil its function. Firmware update mechanisms, for example, should not run with root-level privileges if they only need write access to a specific partition. Secure defaults require that the device ship in a secure configuration, with unnecessary services disabled, debug interfaces locked, and default credentials eliminated. Medical device manufacturers must resist the temptation to ship devices in a permissive configuration for ease of deployment, as many healthcare delivery organisations lack the technical resources to harden devices after installation. Input validation and sanitisation must be applied at every boundary where the device receives data from external sources, whether from a network protocol, a USB interface, a Bluetooth connection, or a file import. Cryptographic controls should follow established algorithms and key lengths recommended by recognised authorities, and key management procedures must ensure that cryptographic material is generated, stored, rotated, and retired securely. Fail-safe design is particularly important for medical devices: when a security control detects a potential compromise, the device should transition to a safe state that preserves patient safety, even if this means degrading functionality. For example, a connected insulin pump that detects unauthorised command injection should halt automated delivery and alert the clinician rather than continuing to operate with potentially compromised parameters. Secure boot mechanisms should verify the integrity of the firmware before execution, ensuring that only authenticated and unmodified code runs on the device. Network communication should implement mutual authentication, so that both the device and the server verify each other before exchanging data, preventing man-in-the-middle attacks. All of these design decisions must be documented in the security architecture, with explicit traceability to the threats they mitigate and the security requirements they satisfy.

The Software Bill of Materials has become one of the most consequential compliance artefacts in medical device cybersecurity, required by both the FDA and increasingly expected by EU Notified Bodies. An SBOM is a comprehensive, machine-readable inventory of every software component included in the device, encompassing proprietary code, open-source libraries, third-party commercial components, operating system packages, and firmware modules. For each component, the SBOM must document the supplier or author, the component name, the version, the unique identifier (such as a CPE or PURL), and any known vulnerabilities or anomalies. The FDA expects the SBOM to be provided in a standardised format, with SPDX and CycloneDX being the most widely accepted. The significance of the SBOM extends far beyond regulatory compliance: it provides the foundation for effective vulnerability management throughout the product lifecycle. When a new vulnerability is disclosed in an open-source library, the SBOM enables the manufacturer to immediately determine whether any of their devices are affected, assess the clinical risk, and initiate remediation. Without an accurate and current SBOM, manufacturers are operating blind, unable to respond effectively to security advisories and unable to demonstrate to regulators that they have a handle on their software supply chain. Building and maintaining an SBOM requires integration into the build pipeline, with automated tooling that generates the inventory as part of every release build and flags any newly added components for security review. Manufacturers must also establish processes for monitoring vulnerability databases and security advisories for every component listed in the SBOM, and for evaluating the applicability and impact of disclosed vulnerabilities against the specific configuration and usage context of their device. A common challenge is the sheer volume of vulnerabilities disclosed in widely used open-source components. Not every CVE that affects a library in the SBOM is actually exploitable in the device context; the vulnerable function may not be invoked, the attack vector may not be accessible, or existing architectural controls may prevent exploitation. Manufacturers need a triage process that efficiently separates actionable vulnerabilities from noise, and this process must be documented to demonstrate to regulators that the manufacturer is actively managing its software supply chain risk rather than simply accumulating unaddressed vulnerability reports.

Vulnerability management and coordinated disclosure form the operational backbone of a medical device cybersecurity programme, bridging the gap between pre-market design controls and post-market security maintenance. Manufacturers must establish a vulnerability intake process that monitors multiple sources of vulnerability intelligence, including the National Vulnerability Database, ICS-CERT advisories, vendor security bulletins, and reports from independent security researchers. When a vulnerability is identified that affects a component within the device, the manufacturer must conduct a risk assessment that considers the exploitability of the vulnerability in the specific device context, the potential clinical impact if exploited, the availability of compensating controls, and the feasibility of deploying a patch or mitigation to the installed base. Not every vulnerability requires an immediate patch; some may be mitigated by existing architectural controls, while others may affect a component that is not reachable from an external attack surface. The risk assessment must be documented and the rationale for the chosen response must be defensible to regulators. For vulnerabilities that require remediation, the manufacturer must have a tested and validated update deployment mechanism that can deliver patches to devices in the field without disrupting clinical operations. Coordinated vulnerability disclosure is equally important: manufacturers should publish a vulnerability disclosure policy that provides security researchers with a clear, accessible channel for reporting vulnerabilities, commits to timely acknowledgement and communication, and follows established coordinated disclosure practices. Both the FDA and the European cybersecurity community strongly encourage manufacturers to participate in coordinated disclosure programmes, and failure to do so is increasingly viewed as a marker of organisational immaturity in cybersecurity. The vulnerability management process should also include a communication workflow for notifying affected healthcare delivery organisations, providing them with actionable information about the vulnerability, the assessed risk, recommended compensating controls, and the timeline for a permanent fix. Transparent and timely communication builds trust with the customer base and demonstrates the kind of responsible security culture that regulators expect from medical device manufacturers.

Security testing must be comprehensive, risk-proportionate, and integrated into the development and release process rather than relegated to a one-time pre-submission activity. The testing strategy should encompass multiple complementary approaches: static application security testing (SAST) to identify coding flaws and insecure patterns in the source code, dynamic application security testing (DAST) to probe running interfaces for exploitable vulnerabilities, software composition analysis (SCA) to identify known vulnerabilities in third-party and open-source components, fuzz testing to evaluate the robustness of communication protocols and input parsers against malformed or unexpected data, and penetration testing to simulate real-world attack scenarios against the complete device system. For medical devices, penetration testing must be performed by testers with an understanding of the clinical context, because the success criteria are not purely technical: a finding that would be low severity in a consumer application may be critical in a device that delivers therapy or supports clinical decision-making. The results of security testing must be documented in a manner that demonstrates coverage of the identified threats from the threat model, and any residual vulnerabilities must be assessed and accepted through the security risk management process. Regression testing must be performed after any security-related code change to ensure that patches do not introduce new safety or functionality issues. Automated security testing should be integrated into the continuous integration pipeline so that every build is assessed for known vulnerability signatures and common coding weaknesses, providing rapid feedback to development teams and preventing the accumulation of security debt. It is important to note that security testing for medical devices must account for the full system boundary, including not just the device itself but also companion mobile applications, cloud backend services, firmware update servers, and any APIs exposed to healthcare delivery organisation networks. Each interface represents a potential entry point for an attacker, and testing that focuses only on the device firmware while ignoring the cloud API or mobile application leaves significant gaps in coverage. Additionally, manufacturers should consider engaging independent third-party security testing firms for critical devices, as external testers bring fresh perspectives and are more likely to identify vulnerabilities that internal teams have overlooked due to familiarity bias.

FDA premarket submissions for devices with cybersecurity considerations require a specific set of documentation that demonstrates the manufacturer has implemented a systematic, comprehensive approach to device security. The submission should include a cybersecurity management plan that describes the organisational structure, processes, and resources dedicated to managing cybersecurity throughout the total product lifecycle. The threat model and security risk assessment must be provided, showing the identified threats, the assessed risks, and the controls implemented to mitigate them. The security architecture documentation should describe how security controls are implemented within the device design, including authentication mechanisms, encryption schemes, access control models, audit logging, and update mechanisms. The SBOM must be included in a standardised format, accompanied by evidence that known vulnerabilities in listed components have been assessed and addressed. Security testing reports must demonstrate adequate coverage and document the disposition of all findings. For devices that receive software updates, the submission must describe the update delivery mechanism, the validation process for updates, and the rollback capability in case an update causes operational issues. The FDA also expects evidence that the manufacturer has established a post-market cybersecurity monitoring programme, including vulnerability monitoring, a coordinated disclosure policy, and procedures for communicating security information to users and healthcare delivery organisations. Manufacturers who submit well-organised, comprehensive cybersecurity documentation aligned with FDA guidance experience significantly smoother review cycles, while those with gaps or inconsistencies face additional information requests that can delay clearance by months. A particularly common deficiency in FDA submissions is an incomplete or poorly structured threat model that fails to consider the full range of threat actors, attack vectors, and clinical consequences relevant to the device. Another frequent gap is the absence of a credible plan for post-market vulnerability management, which the FDA views as inseparable from the premarket cybersecurity case. Manufacturers should also be aware that the FDA increasingly expects cybersecurity documentation to be presented in a structured format that facilitates efficient review, with clear cross-references between the threat model, the security requirements, the design controls, and the testing evidence. A well-prepared cybersecurity submission tells a coherent story: here are the threats we identified, here is how we designed against them, here is the evidence that our controls are effective, and here is how we will maintain security after the device reaches the market.

Post-market cybersecurity monitoring and patch management represent an ongoing commitment that extends for the entire marketed lifetime of the device. Unlike consumer software products that can push frequent updates with minimal coordination, medical devices require a disciplined approach to security updates that balances the urgency of vulnerability remediation against the risks of introducing changes to a validated, safety-critical system. Manufacturers must establish a post-market cybersecurity monitoring programme that continuously tracks the threat landscape relevant to their devices, monitors vulnerability databases and vendor advisories for their SBOM components, evaluates field reports and customer complaints for potential security implications, and conducts periodic reassessments of the device security posture against evolving threats. When a security update is necessary, the manufacturer must follow a change management process that includes impact assessment, regression testing, revalidation of affected safety functions, and coordination with healthcare delivery organisations to schedule deployment windows that minimise clinical disruption. The EU MDR post-market surveillance requirements apply to cybersecurity alongside safety and performance, meaning that cybersecurity incidents must be included in periodic safety update reports and, where they meet the reporting criteria, must be reported to competent authorities through the vigilance system. In the United States, the FDA expects manufacturers to communicate cybersecurity updates to the user community through appropriate channels, which may include ISAO (Information Sharing and Analysis Organisation) participation, direct customer notifications, and coordination with ICS-CERT for vulnerabilities that affect multiple manufacturers or device types. A manufacturer that neglects post-market cybersecurity monitoring risks not only regulatory action but also liability exposure if a foreseeable vulnerability is exploited and causes patient harm. Establishing a clear end-of-support policy is also essential: manufacturers must define and communicate the date beyond which security updates will no longer be provided for a given device, and must provide healthcare delivery organisations with sufficient advance notice to plan for device replacement or alternative mitigation strategies. The end-of-support policy should be documented in the device labelling and in the security guidance provided to customers at the time of purchase, setting clear expectations for the duration of cybersecurity support throughout the product lifecycle.

The integration of cybersecurity activities with the IEC 62304 software lifecycle creates a unified compliance framework that is both efficient and auditable. Rather than maintaining separate cybersecurity and software safety processes that operate in parallel, manufacturers should extend their existing IEC 62304 lifecycle to incorporate the security-specific activities defined by IEC 81001-5-1. During the planning phase, the software development plan should be augmented to include cybersecurity activities, roles, tools, and deliverables alongside the existing safety-oriented content. During requirements analysis, security requirements derived from the threat model should be captured in the same requirements management system as functional and safety requirements, with traceability to the security risk assessment. During architectural design, the security architecture should be documented as an integral part of the software architecture, showing how security controls are implemented within the established component structure. During implementation, secure coding standards and code review checklists should address both safety and security concerns. During verification, security testing activities should be coordinated with safety verification to maximise coverage and minimise duplication. During release, the SBOM, security test reports, and residual risk assessment should be finalised alongside the standard release documentation. During maintenance, vulnerability monitoring and security patch management should operate within the same change control and configuration management processes that govern safety-related changes. This integrated approach ensures consistency, reduces the total documentation burden, and presents a coherent compliance story to regulators and Notified Bodies who are increasingly evaluating safety and security holistically rather than as separate concerns. A practical consideration for this integration is tooling alignment. If the organisation uses an application lifecycle management platform for IEC 62304 traceability, the same platform should be extended to manage security requirements and their traceability to the threat model and security test cases. If separate tools are used for safety and security artefacts, there must be a documented process for maintaining consistency between them and for resolving conflicts when a security control could potentially impact a safety function or vice versa. The quality management system should also be updated to include cybersecurity-specific procedures, competency requirements, and audit criteria, ensuring that cybersecurity is treated with the same process discipline as safety throughout the organisation.

Building a practical cybersecurity compliance roadmap requires manufacturers to assess their current maturity, identify gaps, and prioritise investments based on regulatory requirements and product risk. Organisations that are new to medical device cybersecurity should begin with a gap assessment against IEC 81001-5-1, mapping their existing software development and security practices to the requirements of the standard and identifying areas where processes, documentation, or tooling are insufficient. The highest priority items are typically those that are most difficult to retrofit into a product already under development: threat modeling, security architecture decisions, and SBOM generation should be addressed as early as possible. Organisations should invest in training their software development teams on secure coding practices specific to medical device contexts, including input validation, authentication and session management, cryptographic implementation, and secure update mechanisms. Toolchain investments in static analysis, software composition analysis, and automated SBOM generation deliver ongoing returns by catching vulnerabilities early and maintaining compliance artefacts with minimal manual effort. For organisations with multiple products at different lifecycle stages, a phased approach is pragmatic: apply the full cybersecurity process to new products from the outset, and conduct a security risk assessment on legacy products to determine whether retrospective remediation is necessary based on the product risk profile and remaining market lifetime. Engaging regulatory consultants with deep expertise in both IEC 62304 and IEC 81001-5-1 can accelerate the roadmap by providing proven process templates, conducting readiness assessments, and preparing the cybersecurity documentation package for premarket submissions. The investment in a robust cybersecurity programme pays dividends not only in regulatory compliance but also in reduced vulnerability exposure, faster incident response, stronger customer confidence, and a defensible position in an increasingly security-conscious healthcare market.