How to Secure Medical Devices from Cybersecurity Threats

Medical devices no longer operate as isolated clinical equipment. Infusion pumps connect to medication libraries. Patient monitors transmit data to central monitoring stations. Imaging modalities exchange studies with PACS and vendor-neutral archives. Laboratory analyzers send results through middleware and interface engines. Many devices also depend on wireless networks, cloud services, vendor portals, mobile applications, identity systems, and remote support connections.

This connectivity improves clinical efficiency and gives care teams faster access to information. It also expands the number of systems, accounts, network paths, and software components that an attacker could target.

A compromised medical device may expose patient information, provide a path into the hospital network, lose access to supporting services, display unreliable information, or become unavailable during care delivery. The FDA treats medical device cybersecurity as a patient-safety concern because cybersecurity incidents can affect a device’s safety, effectiveness, and availability.

Securing these environments requires more than installing another security product. Hospitals need a coordinated medical device cybersecurity program that combines:

• Clinical engineering
• Information security
• Network and infrastructure management
• Vendor risk management
• Vulnerability management
• Clinical operations
• Privacy and compliance
• Incident response
• Device lifecycle planning

This guide explains how hospitals, IDNs, specialty hospitals, imaging centers, and enterprise health systems can reduce medical device and Internet of Medical Things risk without disrupting patient care.

What Is Medical Device Cybersecurity?

Medical device cybersecurity is the practice of safeguarding medical devices, their software, connected infrastructure, clinical data, and dependent workflows against unauthorised access, manipulation, disruption, misuse, or loss of availability. The security boundary does not stop at the physical device.

A connected device may rely on:

• Embedded software and firmware
• Commercial or open-source software components
• Device-management servers
• Hospital wired and wireless networks
• Clinical workstations
• Cloud-hosted applications
• Vendor update infrastructure
• Remote service portals
• Identity and directory services
• EHR, PACS, LIS, pharmacy, or monitoring-system integrations

A weakness in one supporting component can affect the larger clinical system. 

As a result, FDA guidance addresses device cybersecurity throughout the entire product lifecycle, rather than as a one-time premarket testing exercise.

The Internet of Medical Things, or IoMT, refers to connected medical devices and supporting technologies that collect, process, transmit, or exchange clinical data. Common examples include:

• Infusion pumps
• Bedside and ambulatory monitors
• Ventilators
• Smart beds
• CT, MRI, X-ray, ultrasound, and nuclear medicine systems
• Laboratory and pathology analyzers
• Medication-dispensing systems
• Surgical robots
• Implantable and wearable devices
• Remote patient monitoring equipment
• Device gateways and central monitoring stations

An effective IoMT security program must safeguard confidentiality, integrity, and availability while also ensuring clinical safety and workflow continuity.

Why Medical Device Security Is Different from Traditional IT Security

A network-connected medical device may contain an operating system, user accounts, network services, storage, and third-party software components. Technically, it may resemble a conventional endpoint.

Operationally, it is very different.

Traditional IT environment	Medical device environment
Endpoints can often be rebooted during a standard maintenance window	A reboot may interrupt diagnosis, monitoring, therapy, or patient observation
Endpoint agents can usually be deployed centrally	Unapproved software may affect device performance, validation, or manufacturer support
Patches can often be pushed through enterprise tools	Patches may require manufacturer instructions, clinical validation, or specialized installation
Assets are normally replaced through an IT refresh cycle	Medical devices may remain in service for many years
Vulnerabilities are prioritized mainly by severity and exposure	Prioritization must also consider patient harm, clinical dependency, and multi-patient impact
IT typically controls endpoint configuration	Clinical engineering, clinicians, security teams, vendors, and IT share responsibility
Scanning and testing methods are standardized	Testing must account for device sensitivity, manufacturer guidance, and clinical use

This difference changes how hospitals should manage risk.

A security team cannot automatically isolate, reboot, scan, patch, or install software on a clinical device without first considering whether the action could affect patient care. Conversely, clinical importance cannot justify leaving a vulnerable device exposed indefinitely.

Medical device security necessitates careful decision-making among clinical and technical stakeholders.

What Are the Main Cybersecurity Threats to Medical Devices?

Unpatched software and firmware

Medical devices frequently depend on commercial operating systems, embedded firmware, software libraries, databases, and communication components.

A device may remain vulnerable because:

• The manufacturer has not released a patch.
• The installed model is no longer supported.
• Hospital cannot determine whether the vulnerability applies.
• Update requires specialized installation.
• Device cannot be taken offline during normal operations.
• Hospital has not tested how the patch affects interfaces and workflows.
• Software component is not visible in the asset inventory.

HHS advises regulated organizations to keep asset inventories, monitor manufacturer and vendor alerts, review credible vulnerability sources, and treat patching as an ongoing process.

Its January 2026 guidance specifically mentions the NIST National Vulnerability Database and the CISA Known Exploited Vulnerabilities Catalog as valuable vulnerability-management resources.

Weak or shared credentials

Devices and supporting systems may use:

• Default administrator passwords
• Shared service accounts
• Local credentials
• Hard-coded credentials
• Vendor-maintenance accounts
• Accounts that cannot be centrally rotated
• Credentials that remain active after support work ends

A compromised account can allow an attacker to change configurations, access data, disable controls, install software, or move toward other clinical systems.

A firewall does not make default or shared credentials safe. An attacker may exploit them after compromising another internal asset or vendor account.

Insecure vendor remote access

Remote access is often necessary for diagnostics, updates, calibration, and support. It becomes dangerous when hospitals allow:

• Persistent vendor VPN access
• Direct inbound connectivity
• Shared vendor accounts
• Unmanaged remote desktop tools
• Weak authentication
• Excessive privileges
• Connections without approval
• Sessions that are not logged
• Access that remains active after maintenance

Vendor access should be managed as privileged access to a clinical environment.

Flat or poorly segmented hospital networks

A medical device does not need to be directly internet-facing to be exposed. An attacker may first compromise:

• A user workstation
• A server
• A vendor account
• A wireless endpoint
• An unmanaged IoT device
• A device-management platform

The attacker may then move laterally toward medical devices and their supporting systems.

A single biomedical VLAN may still permit unnecessary communication among devices with unrelated clinical functions, different risk levels, and different support requirements.

Network segmentation should therefore be based on approved communication flows, clinical function, criticality, device class, vendor ecosystem, and lifecycle status.

Ransomware and supporting-system outages

Ransomware does not need to alter a device’s embedded software to disrupt care.

It may disable the services on which the device depends, including:

• Active Directory
• DNS or DHCP
• Device-management servers
• PACS or imaging archives
• Laboratory middleware
• Central monitoring stations
• EHR interfaces
• Vendor cloud services
• Network infrastructure
• Software distribution systems

The device may still power on, but its data, management platform, or downstream workflow are unavailable, rendering it clinically ineffective.

Supply-chain vulnerabilities

A vulnerability in a popular operating system, library, communication stack, or third-party component can affect devices from multiple manufacturers.

A software bill of materials, or SBOM, assists organizations and manufacturers in identifying the commercial, open-source, and off-the-shelf components contained within a product.

Section 524B of the Federal Food, Drug, and Cosmetic Act requires an SBOM for all applicable cyber-device premarket submissions. The requirement applies to the sponsor of the submission—not directly to the hospital operating the device.

Unauthorized functionality and data transmission

The Contec and Epsimed patient-monitoring case exemplifies why hospitals must consider outbound traffic, device firmware, manufacturer communications, and unexpected functionality.

In 2025, the FDA discovered flaws in the Contec CMS8000 and Epsimed MN-120 patient monitors. Unauthorized remote control, hidden backdoor functionality, potential network compromise, and exfiltration of patient data were among the reported issues.

The FDA updated its communication in July 2025, following Contec’s release of a software patch. The patch removes the affected networking functionality and limits the devices to local monitoring. 

The FDA stated that it was not aware of related cybersecurity incidents, injuries, or deaths at the time of the update. This example reinforces the need to monitor what devices communicate with, not only whether they are online.

Data integrity attacks

Medical device security is about more than just maintaining confidentiality. Depending on the device architecture, attacker access, and connected workflow, a compromise may affect:

• Clinical measurements
• Alarm configurations
• Device settings
• Diagnostic images
• Laboratory data
• Drug libraries
• System time
• Data transmitted to another clinical application

An integrity compromise can be difficult to detect when the system continues to function but provides incomplete, altered, delayed, or untrustworthy data.

What Medical Device Cybersecurity Requirements Apply in 2026?

Hospitals must distinguish among:

1. Binding manufacturer requirements
2. HIPAA obligations applicable to regulated entities
3. Nonbinding FDA recommendations
4. Voluntary healthcare cybersecurity frameworks
5. Hospital-defined security and procurement requirements

Confusing these categories can result in inaccurate compliance claims.

FDA Section 524B Requirements for Cyber Devices

Section 524B applies when a sponsor submits a qualifying premarket application or submission for a device that meets the statutory definition of a cyber device.

Applicable submissions include:

• 510(k) submissions, including Special and Abbreviated 510(k)s
• Premarket Approval applications
• Product Development Protocols
• De Novo requests
• Humanitarian Device Exemptions
• Certain PMA and HDE supplements

A cyber device is a device that:

1. Includes software validated, installed, or authorized by the sponsor;
2. Has the ability to connect to the internet; and
3. Contains technological characteristics that could be vulnerable to cybersecurity threats.

For covered submissions, Section 524B requires the sponsor to provide information addressing areas including:

• Postmarket vulnerability monitoring and remediation
• Processes intended to provide reasonable assurance that the device and related systems are cybersecure
• Regular and out-of-cycle updates and patches
• An SBOM for commercial, open-source, and off-the-shelf software components

Section 524B is not a direct hospital compliance requirement, nor is it a blanket retroactive requirement for every legacy medical device already in use. However, healthcare organizations can use its expectations as part of vendor evaluation and lifecycle planning.

In February 2026, the FDA issued updated final guidance on cybersecurity quality-management considerations and premarket submission content. 

The document provides industry recommendations and addresses Section 524B. It superseded the FDA’s June 2025 guidance. FDA guidance is generally nonbinding unless it describes an existing statutory or regulatory requirement.

How HIPAA Applies to Medical Devices

The HIPAA Security Rule requires covered entities and business associates to put in place appropriate administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of electronic protected health information.

When a medical device or its connected systems generate, receive, maintain, or transmit ePHI, the organization must include the device in its HIPAA risk analysis and risk-management processes.

HIPAA does not cover every device-performance or patient-safety cybersecurity risk unrelated to ePHI. A complete hospital program must therefore address both:

• HIPAA-related information-security obligations
• Broader patient-safety and operational risks

HHS Healthcare Cybersecurity Performance Goals

HHS publishes voluntary Healthcare and Public Health Cybersecurity Performance Goals to assist healthcare organizations in prioritizing high-impact security measures.

Relevant goals include:

• Asset inventory
• Vulnerability mitigation
• Strong authentication
• Vendor and supplier security
• Network segmentation
• Centralized log collection
• Incident planning
• Recovery preparedness

These goals are voluntary priorities. They do not replace HIPAA requirements, the organization’s risk analysis, or device-specific clinical safety controls.

A Practical Medical Device Cybersecurity Framework

Hospitals can structure their programs around the six NIST Cybersecurity Framework 2.0 functions:

Govern, identify, protect, detect, respond, and recover.

NIST CSF 2.0 introduced Govern, which emphasizes cybersecurity strategy, accountability, policy, supply-chain oversight, and enterprise risk management. 

1. Establish Shared Governance

Medical device cybersecurity should not be limited to the SOC, IT department, or clinical engineering team. Create a cross-functional governance structure, which includes:

• Information security
• Clinical engineering or healthcare technology management
• Network and infrastructure teams
• Clinical informatics
• Departmental clinical leadership
• Privacy and compliance
• Procurement and supply chain
• Enterprise risk management
• Incident response
• Legal counsel when appropriate

The governance model should define who can:

• Approve a device for network connection
• Accept residual risk
• Approve compensating controls
• Authorize emergency isolation
• Approve or defer a patch
• Contact the manufacturer
• Remove a device from clinical service
• Activate downtime procedures
• Determine whether ePHI is affected
• Approve replacement of an unsupported device

Without clear ownership, known risks may remain unresolved while teams wait for one another to make a decision.

2. Build a Clinically Enriched Asset Inventory

A spreadsheet containing an IP address and manufacturer name is not sufficient for medical device vulnerability management.

The inventory should link technical information with clinical context. Capture:

• Manufacturer, model, serial number, and UDI where available
• Physical and clinical location
• Device owner
• Clinical purpose
• Patient-safety criticality
• Whether the device may be actively connected to a patient
• Operating system and firmware version
• Installed software and relevant components
• IP and MAC addresses
• Wired, wireless, cellular, and cloud connectivity
• Approved ports, protocols, and destinations
• ePHI stored, processed, or transmitted
• Vendor remote-access method
• Device-management or gateway dependencies
• MDS2 and SBOM availability
• Patch status
• Support and end-of-support dates
• Existing segmentation
• Recovery and replacement requirements

Use passive or agentless discovery where appropriate to identify connected devices that are absent from biomedical maintenance databases or configuration-management systems. 

Reconcile network observations with procurement records, maintenance systems, wireless controllers, and physical inventories.

The inventory should answer: Which devices are connected, what do they communicate with, what workflows depend on them, and who owns the risk?

3. Conduct a Clinical Medical Device Risk Assessment

CVSS severity alone does not determine hospital risk.

A device with a critical vulnerability may have limited exposure and strong compensating controls. Another device with a lower technical score may support a critical workflow, be widely deployed, and lack an alternative. Evaluate:

Risk factor	Questions to answer
Applicability	Does the vulnerability affect the installed model, version, firmware, component, and configuration?
Exploitability	Does exploitation require local access, credentials, adjacent network access, or internet exposure?
Known exploitation	Is it listed in CISA’s KEV Catalog or confirmed as actively exploited?
Network exposure	Which users, systems, zones, and external services can reach the device?
Patient impact	Could compromise delay care, affect therapy, suppress alarms, or alter clinical information?
Multi-patient impact	Could one weakness affect a device fleet, shared server, or entire department?
Clinical dependency	Are backup devices or downtime workflows available?
Data risk	Does the system handle ePHI, credentials, or sensitive operational information?
Detectability	Would the hospital recognize unauthorized behavior or configuration changes?
Recoverability	Can the system be restored safely and quickly?
Manufacturer support	Is a patch, mitigation, upgrade, or replacement path available?
Compensating controls	Can segmentation, access restrictions, or monitoring reduce the risk?

Document both the inherent risk and the residual risk after controls are applied.

4. Make Cybersecurity a Procurement Requirement

The most effective time to address a device security limitation is before the contract is signed. Require prospective vendors to provide:

• A current MDS2
• An SBOM where applicable or available
• Security architecture documentation
• Data-flow diagrams
• Required ports, protocols, domains, and external connections
• Authentication and authorization capabilities
• Encryption capabilities
• Logging and log-export options
• Remote support architecture
• Vulnerability-disclosure procedures
• Patch and update processes
• Support and end-of-support dates
• Backup and recovery requirements
• Secure decommissioning instructions
• Cloud hosting and subcontractor information
• Cybersecurity incident-notification terms

The MDS2 is a recognized manufacturer disclosure format intended to help security professionals evaluate medical device security capabilities. 

It is not a universal statutory requirement for every device purchase. Hospitals may nevertheless require it contractually as part of their procurement standard.

Contracts should also define responsibility for:

• Patch deployment
• Downtime coordination
• Validation testing
• Remote-access control
• Unsupported software
• Vulnerability notification
• Remediation timelines
• Replacement when secure operation can no longer be maintained

A questionnaire identifies risk. Contract language determines whether the vendor must help resolve it.

5. Segment Medical Device Networks

Medical devices should communicate only with approved systems and services required for their clinical function. Develop zones based on:

• Device type
• Clinical purpose
• Department
• Patient-safety criticality
• Manufacturer ecosystem
• Required communication flows
• Remote support needs
• Support status
• Risk level

For example, an imaging modality may require access to:

• Modality worklist services
• PACS or a vendor-neutral archive
• DNS
• Time services
• Approved management infrastructure
• Documented vendor destinations

It should not automatically communicate with general office endpoints, unrelated device groups, or unrestricted internet destinations. Test proposed controls before enforcement. Blocking a required flow can interrupt images, alarms, results, monitoring, or device management.

6. Control Identities and Vendor Access

Apply least privilege at the device, management-system, network, and remote-access layers.

Controls should include:

• Unique named accounts where supported
• Strong credential-management procedures
• Removal of unused accounts
• MFA for VPNs, portals, jump servers, and administrative access where technically supported
• Time-limited vendor access
• Approval before remote sessions
• Session logging or recording where appropriate
• Restrictions by source, destination, protocol, and time
• Automatic account expiration
• Prompt removal of access when support relationships end

Do not install an unvalidated identity or endpoint agent directly on a device solely to satisfy a general enterprise policy. When the device cannot support modern controls, enforce them through gateways, jump servers, network access control, or management platforms.

7. Create a Device-Specific Vulnerability Workflow

Use a controlled process: Detect → Validate → Assess → Mitigate → Test → Approve → Deploy → Verify → Document

Monitor:

• Manufacturer advisories
• FDA safety communications
• CISA medical-device advisories
• CISA KEV
• NVD
• Information-sharing communities
• Internal monitoring
• SBOM analysis
• Coordinated vulnerability disclosures

Before remediation, confirm that the vulnerability applies to the installed product and configuration. When a patch is available:

1. Review manufacturer instructions.
2. Assess clinical and technical dependencies.
3. Test on a representative device where possible.
4. Back up configurations.
5. Document rollback procedures.
6. Schedule an appropriate maintenance window.
7. Deploy to a controlled group.
8. Validate device function, interfaces, alarms, and data exchange.
9. Expand deployment.
10. Verify remediation and update the risk record.

When a patch is not available, consider:

• Network isolation
• Blocking vulnerable services
• Restricting outbound communication
• Removing direct internet access
• Disabling unnecessary functionality
• Restricting vendor access
• Increasing monitoring
• Moving the device to a higher-control zone
• Accelerating replacement

Every compensating control should have an owner, evidence of effectiveness, a review date, and an exit plan.

8. Monitor Device Behavior

Monitoring should establish expected communication and identify meaningful deviations. Watch for:

• New external destinations
• Communication between unrelated device groups
• Unauthorized remote-access tools
• New ports or services
• Abnormal communication volume
• Connections to malicious infrastructure
• Repeated authentication failures
• Unapproved protocol use
• Unexpected software downloads
• Configuration changes
• Devices appearing in the wrong segment
• Activity from decommissioned assets

Integrate high-confidence alerts into the SIEM and SOC workflow. An actionable device alert should include:

• Device type
• Location
• Clinical owner
• Patient connection status
• Observed behavior
• Potential clinical consequence
• Safe containment options

9. Prepare a Medical Device Incident Response Plan

A general ransomware playbook does not fully address a medical device incident. Use this sequence:

1. Protect the patient. Determine whether the device is actively supporting care and whether a safe alternative exists.
2. Engage the right teams. Notify security, clinical engineering, clinical leadership, privacy, risk management, IT, and the manufacturer as appropriate.
3. Contain safely. Isolate the device or restrict communication without creating a greater clinical risk.
4. Preserve evidence. Retain logs, traffic, configurations, and account activity when it is safe to do so.
5. Determine scope. Identify affected models, locations, supporting systems, records, and workflows.
6. Activate downtime procedures. Move to approved backup devices or manual processes.
7. Assess reporting obligations. Evaluate HIPAA, FDA user-facility, contractual, insurance, and other obligations with appropriate compliance and legal personnel.
8. Remediate and validate. Confirm both security and clinical function before returning the device to service.
9. Improve the program. Update controls, procurement standards, inventories, and playbooks.

Conduct tabletop exercises involving realistic scenarios such as:

• Compromise of a central monitoring server
• Unauthorized outbound traffic from an imaging system
• A compromised vendor account
• Ransomware affecting a device-management platform
• A critical vulnerability with no patch
• Loss of connectivity to a cloud-dependent device

10. Manage Legacy Devices as an Enterprise Risk

Unsupported devices should not remain in service indefinitely under an open-ended risk exception. Available decisions include:

• Continue operating with reviewed controls
• Add compensating controls
• Upgrade the device
• Remove unnecessary connectivity
• Restrict the device to an isolated zone
• Replace the device
• Decommission it

Prioritize replacement using:

• Patient-safety impact
• Known vulnerabilities
• Patch availability
• Network exposure
• Clinical criticality
• Number of affected devices
• Availability of alternatives
• Manufacturer support status
• Recovery difficulty
• Cost of maintaining compensating controls

IMDRF has published final guidance specifically addressing cybersecurity principles and practices for legacy medical devices, reinforcing the need for shared lifecycle responsibility and planned risk management.

During decommissioning, remove devices from network policies, monitoring systems, vendor portals, identity systems, and inventories. Sanitize stored ePHI and configurations using approved procedures.

Sample 90-Day Medical Device Cybersecurity Improvement Roadmap

This roadmap is an illustrative prioritization model, not a regulatory deadline. Organizations should adjust it according to clinical risk, device population, maturity, resources, and legal obligations.

Days 1–30: Establish visibility

• Form the governance team.
• Assign device and clinical owners.
• Reconcile biomedical and network inventories.
• Identify internet-accessible devices.
• Review remote vendor access.
• Identify unsupported operating systems.
• Review current FDA, CISA, and manufacturer advisories.
• Select the highest-risk department or device class.

Days 31–60: Reduce immediate exposure

• Segment high-risk device groups.
• Change default credentials where supported.
• Implement controlled vendor access.
• Validate critical vulnerability applicability.
• Deploy manufacturer-approved patches.
• Add compensating controls for unpatchable devices.
• Collect MDS2 and SBOM documentation.
• Document clinical downtime procedures.

Days 61–90: Operationalize the program

• Implement continuous device discovery.
• Integrate priority alerts with the SOC.
• Define remediation targets.
• Add cybersecurity terms to procurement.
• Create a legacy-device replacement register.
• Conduct a medical-device incident tabletop.
• Report risk metrics to leadership.
• Expand the program to another clinical area.

How to Measure Medical Device Cybersecurity

Track outcomes rather than tool deployment alone. Useful measures include:

• Percentage of connected devices inventoried
• Percentage with known location, owner, firmware, and support status
• Percentage with MDS2 or SBOM documentation
• Number of internet-accessible medical devices
• Percentage of vendor access using approved controls
• Critical vulnerabilities without a mitigation plan
• Time from advisory receipt to applicability decision
• Time to mitigate applicable critical vulnerabilities
• Percentage of devices in approved network zones
• Unsupported devices without replacement plans
• Percentage of high-risk devices covered by monitoring
• Time required to identify devices affected by a new component vulnerability
• Percentage of clinical departments with tested downtime plans
• Number of overdue compensating-control reviews

A mature program should quickly answer: Which devices are affected, where are they located, what workflows depend on them, what controls already exist, and who will lead the response?

Common Medical Device Cybersecurity Mistakes

Treating every CVE as equally urgent

Technical severity matters, but it must be evaluated alongside exposure, exploitability, clinical impact, and compensating controls.

Waiting for a patch without reducing exposure

Manufacturers may need time to develop and validate an update. Hospitals should evaluate safe interim controls.

Segmenting without understanding workflows

Poorly designed rules can block legitimate clinical traffic. Map communication before enforcing policy.

Assuming FDA authorization removes future risk

Authorization does not prevent new vulnerabilities from emerging after deployment.

Focusing only on the physical device

Assess the gateway, server, cloud platform, vendor account, workstation, interface, network service, and identity dependency.

Collecting an MDS2 without evaluating it

Documentation creates value only when security, clinical engineering, and procurement teams use it to identify gaps and negotiate requirements.

Ignoring downtime preparedness

Security controls cannot prevent every incident. Care teams must be able to continue operating when a connected device or supporting service becomes unavailable.

Strengthen Medical Device and IoMT Security

Medical device cybersecurity is not a one-time audit.

It requires continuous coordination across asset discovery, clinical risk assessment, network segmentation, vendor access, vulnerability management, procurement, monitoring, incident response, and lifecycle planning.

CapMinds’ healthcare security and compliance services can support healthcare organizations with:

• Medical device and IoMT risk assessments
• Connected-asset discovery and inventory planning
• Hospital network security architecture
• Segmentation and access-control design
• Vulnerability-management workflows
• Vendor and remote-access security
• Legacy-system risk-reduction planning
• SIEM and SOC integration
• HIPAA security risk analysis support
• Incident-response and downtime planning
• Healthcare cybersecurity governance
• Remediation roadmaps

Identify Medical Device Risks Before They Affect Patient Care

Assess unmanaged devices, vulnerable clinical workflows, network exposure, vendor-access gaps, and remediation priorities across your connected healthcare environment.

Request a Medical Device Security Assessment