Health-ISAC’s Medical Device Security Council published a MedTech Security Baselines paper outlining a practical set of cybersecurity capabilities that healthcare delivery organizations commonly expect medical device manufacturers to support. The guidance covers nine survey-selected capability domains intended to inform medical device evaluation, procurement, deployment and exception reviews, while distinguishing between devices running full operating systems and those using embedded, real-time or otherwise constrained platforms.
The paper emphasizes that the baselines are a decision-support resource rather than a certification standard or prescriptive procurement checklist, recognizing that medical devices may not natively support every security control in every deployment. Where device-level controls are limited, Health-ISAC calls for documented compensating controls, governance and oversight tailored to the device’s clinical context, threat model, patient-safety impact and operational burden. It also says controls dependent on healthcare delivery organization infrastructure require explicit agreement between the organization and manufacturer, with final risk acceptance resting with the authorized healthcare organization decision-maker.
Securing medical devices presents unique challenges compared to traditional information technology systems. Many medical devices are designed to remain in service for extended periods, often exceeding the lifecycle of the underlying operating systems, software components, or cybersecurity technologies on which they depend. Legacy platforms, specialized hardware, regulatory requirements, validation constraints, and the need to maintain uninterrupted clinical operations can limit the speed and flexibility with which security controls, patches, and updates are implemented. In many cases, capabilities commonly expected in enterprise IT environments may not be technically feasible on certain medical technologies without significant redesign.
Unlike many traditional technology assets, medical devices often perform functions that directly support patient care. As a result, cybersecurity decisions must be evaluated through both a security and patient safety lens. Actions such as patch deployment, network isolation, software upgrades, system reconfiguration, or service interruptions may have downstream effects on clinical workflows, availability requirements, and patient outcomes. Security controls appropriate in a conventional enterprise environment may require modification or alternative implementation approaches in healthcare settings to avoid unintended impacts on care delivery. These realities underscore the importance of risk-based decision-making and close collaboration between HDOs and MDMs.
The paper identified that effective medical device security is rarely achieved through a single technology control. Instead, security is often the result of layered protections that include device capabilities, secure product design, network architecture, operational processes, monitoring, governance, and compensating controls. Success depends on transparency regarding device capabilities and limitations, clear communication of residual risks, and shared commitment to continuous improvement throughout the product lifecycle.
The Health-ISAC provided a Control Summary Matrix, designed as the quick-use front end of a paper. It summarizes what each control is trying to achieve, the baseline capability, potential controls that may be evaluated when the baseline cannot be implemented natively, and evidence an HDO can reasonably request. Organizations should use this document to strengthen procurement reviews, improve deployment planning, identify compensating controls, and establish shared cybersecurity expectations.
The workgroup selected nine foundational capability domains, including authentication, authorization, encryption, event logging, patches and updates, secure remote vendor access, privacy and data handling, secure cloud connectivity, and boundary protection to guide discussions between HDOs and manufacturers on product design, deployment, and lifecycle management. These domains represent a living framework that should evolve with healthcare threats and regulatory expectations, not a complete or statistically ranked cybersecurity standard.
Authentication establishes confidence in user, service, and device identity. The baseline expectation is unique identities, strong authentication, and support for MFA where feasible. Potential compensating controls include gateway-enforced MFA, PAM, segmentation, supervised service sessions, and physical access controls. Typical evidence includes account model, auth methods, directory integration options, and audit attribution.
The matrix calls for medical devices to support unique identities for users and service personnel, strong authentication for administrative and remote access, including multifactor authentication where technically feasible, and per-user attribution in security and service logs. Devices may retain a break-glass capability for emergency access to limited functionality. For devices running full operating systems, the baseline calls for local or enterprise-integrated accounts, strong passwords and no automatic login for privileged functions. Manufacturers should clearly document domain integration or single sign-on capabilities and define appropriate integration boundaries, while administrative interfaces, service portals and remote support pathways should have stronger authentication than routine clinical workflows.
For embedded and constrained devices, the guidance recognizes that limited or absent user interfaces can make direct MFA or directory integration impractical. Instead, security controls should focus on protecting service ports, maintenance tools and firmware update paths through controlled access to maintenance functions. Where devices cannot enforce MFA or other authentication controls directly, potential compensating measures include MFA through gateways, brokers, privileged access management platforms or remote support portals; network segmentation and tightly controlled service workstations; physical and tamper-evident protections; supervised servicing; managed service accounts where applicable; and disabling unused access methods, ports and protocols.
Authorization limits what authenticated users and processes can do. The baseline expectation is least privilege, role separation, and clear restriction of service actions. Potential compensating controls include workflow approvals, role mapping, and physical/service-mode controls. Typical evidence includes role matrix, privilege documentation, and service-mode controls.
The MedTech paper covers what authenticated users, processes and services are permitted to do, warning that failures can expose protected health information, enable unauthorized device changes and create patient-safety risks. The baseline calls for clinical, administrative and service privileges to be separated where feasible, least privilege to be applied by default, and deliberate elevation for higher-risk actions. Full operating system devices should support role-based access control and privilege separation, with authorization extending beyond local interfaces to APIs, management consoles, update functions and remote-support tools. Manufacturers should document elevated privileges and identify which actions require additional authorization.
For embedded and resource-constrained devices, the guidance recognizes that limited computing resources and safety requirements can restrict granular authorization capabilities. Where devices cannot support detailed role-based controls, healthcare delivery organizations should limit who can perform service actions and under what conditions, treating debug ports, serial interfaces, engineering menus and maintenance workflows as privileged functions.
Compensating measures can include approval or dual-control processes, managed service workstations, restricted maintenance access, physical service keys or supervised servicing, network segmentation, enhanced monitoring and disabling insecure or unused ports and protocols. Health-ISAC says organizations should be able to obtain privilege matrices, details on service and maintenance roles, lists of high-risk actions, explanations of shared privileges and default access methods, while authorization limitations in regulated environments should be documented through risk acceptance, compensating controls and modernization planning.
Secure Remote Vendor Access allows support without exposing the HDO network to unnecessary risk. The baseline expectation is brokered, time-bound, auditable access using named accounts and MFA. Potential compensating controls include jump hosts, ZTNA, PAM, and local approval workflow, session recording, and auditing. Typical evidence includes remote access workflow, identity controls, session logging, termination process, and inactivity timeout.
The MedTech paper enables manufacturers to diagnose issues, deploy updates, and support devices without on-site visits, delivering faster troubleshooting and more efficient maintenance while minimizing clinical disruption. However, this capability requires layered administrative, technical, and operational controls. The baseline approach uses brokered or mediated access with named vendor identities, strong authentication, MFA, and time-bound, auditable sessions with clear approval and termination processes.
For full-OS devices, remote support should be restricted to approved methods, systems, ports, and protocols, with logging and session recording where feasible. Constrained devices may rely on the remote access broker, service platform, or support workstation as the primary control point for identity, logging, and approval when device-native logging is unavailable. Implementation must distinguish between interactive support, software delivery, telemetry, and unattended administration, as these present different risk profiles.
Organizations should evaluate compensating controls including ZTNA, PAM, jump hosts, local HDO approval before session start, source and geographic restrictions, and externally retained logs when device logging is weak. HDOs should request remote access workflow diagrams, identity and MFA models, session approval and termination processes, and residual risk explanations for legacy methods. End-to-end auditing of secure remote connections is a shared responsibility between HDOs and manufacturers, and incident response tabletops validate this capability.
Federal and highly regulated environments should maintain tight control over remote pathways with strong identity and documented exception handling, avoiding shared vendor accounts, persistent unrestricted access, and undocumented maintenance tunnels. PHI disclosure to manufacturers is permitted only when consistent with law and covered by appropriate written agreements and safeguards.
The Health-ISAC paper mentioned that privacy and data handling protects PHI, PII, and other sensitive data across the device lifecycle. The baseline expectation is data minimization, access restriction, retention limits, and controlled disclosure. Potential compensating controls include disabling local storage when possible and de-identification and process controls. Typical evidence includes data flow summary, retention statement, export controls, and third-party data handling.
The MedTech detailed that this includes the way devices and associated workflows collect, access, store, retain, disclose, transmit, and dispose of sensitive data, including PHI and PII, throughout the product lifecycle. The baseline expectation is to collect and retain only the patient and operational data needed for intended clinical and support functions, control access and disclosure based on role and documented workflow, document how the device and connected services handle sensitive data, and manage local data retention to reduce avoidable exposure.
Full-OS devices typically enable stronger privacy controls through discrete user and system accounts, recordable security-relevant events for data access and modification, zero trust principles, and integration with enterprise privacy systems. Full-OS device documentation should specify where data is stored, how it is managed, how retention can be controlled, and when and how vendor personnel can access patient data with clear authority and audit trails.
Embedded and constrained devices face inherent limitations in user accounts and logging capabilities, yet privacy risks persist through caches, exports, telemetry, service tools, and removable media. When devices cannot enforce granular privacy settings, operational processes must constrain data collection, transmission, and access. Portable and point-of-care devices require special attention due to loss, reuse, and local storage risks. Compensating controls include disabling unnecessary local storage, applying data minimization and de-identification where technical controls are limited, restricting exports and removable media through policy or supervised workflows, and documenting third-party access and data-handling limitations.
HDOs should request data flow summaries showing sensitive data collection and transmission, retention and deletion approaches, examples of service logs to verify PHI/PII protection, descriptions of who can access patient data during support, and statements of external recipients and vendor processing locations. Federal and highly regulated environments impose stricter privacy review around cross-boundary data movement, vendor access, and cloud processing, with privacy limitations identified early in the intake cycle rather than after deployment.
Encryption reduces disclosure risk for stored and transmitted data. The baseline expectation is encryption in transit and at rest where feasible, and standards-based key handling. Potential compensating controls include encrypted gateways, storage isolation, physical controls, and documented limitations. Typical evidence includes encryption statements, protocols, certificate handling, and key-storage approach.
Encryption protects sensitive data in transit and at rest, with baseline expectations requiring industry-accepted certificate and key-management practices and explicit documentation of what is encrypted and where trust boundaries sit. Full-OS devices can support Transport Layer Security, encrypted storage, and stronger key protection if properly designed, though claims must be specific about different pathways. Constrained devices may lack full-disk encryption but should ensure authenticated, encrypted communication and controllable local data exposure; firmware signing and secure boot remain important.
Compensating controls include encrypted gateways, segmented paths, reduced data retention, and physical controls for portable devices. HDOs should request encryption statements covering data in transit and at rest, supported protocols, firmware signing, unencrypted pathways, and certificate management details. Federal environments require additional scrutiny of algorithm selection, FIPS compliance with validated cryptographic modules, certificate management integrity, and Post-Quantum Computing readiness in product roadmaps.
The Health-ISAC paper said that event Logging creates accountability and supports detection, forensics, and safety investigation. The baseline expectation is meaningful logs for access, changes, faults, and security-relevant events. Potential compensating controls include SIEM integration and alerting, external logging, gateway logs, service logs, and stronger local retention procedures. Typical evidence includes log samples, retention/export options, time sync approach, and event taxonomy.
It enables misuse detection, incident investigation, and understanding of device behavior by recording security-relevant and operationally relevant activity with clear attribution. The baseline expectation is to record meaningful events for authentication, privilege changes, configuration and software changes, remote support activity, and faults, with consistent timestamps and export capability even if the device cannot host a full enterprise logging stack. Full-OS devices should log successful and failed logins, account changes, policy changes, firewall alerts, and relevant network activity in meaningful, attributable events exportable to SIEM tools.
Constrained devices may require the support environment, gateway, or service tooling to carry the accountability burden through configuration change logging, maintenance session logging, and fault history. Compensating controls include externally retained gateway and remote access logs, segmentation, firewall telemetry, and time-synchronized infrastructure logs to supplement sparse device events.
HDOs should request sample log output, event taxonomy, retention and export options, time synchronization approach, and explanations of how remote support actions are attributed. Claims must be specific about what is logged, retention duration, and record attributability. Federal environments require clear event retention, attribution, and retrieval processes, with exception documentation identifying what the product cannot log and how investigators would reconstruct events.
Regular patches and updates reduce exposure from known vulnerabilities and reliability defects. The baseline expectation is a defined update process, regular cadence, supported software, version visibility, and lifecycle planning. Potential compensating controls include segmentation, maintenance windows, traffic monitoring, and exception tracking. Typical evidence includes patch policy, SBOM or software inventory, technical bulletin documenting patches, support lifecycle, and rollback process.
The MedTech paper helps reduce exposure to known vulnerabilities and reliability defects through documented processes that make device software versions visible, define how routine and urgent updates are handled, and establish clear responsibilities for software components. Full-OS devices require documentation of manufacturer-controlled components, expected update methods, and patch cadence, with interim risk-mitigation guidance when patch timing falls outside the documented schedule. Embedded devices may have irregular update cycles and limited version visibility, making lifecycle planning, inventory discipline, and signed update packages more important than automated patching.
Compensating controls include segmentation, allowlisting, boundary restrictions, and additional monitoring when devices cannot be patched on the preferred cadence, along with planned maintenance windows and disabling unnecessary services when remediation is delayed. HDOs should request patch policies, software inventory or SBOM information, support lifecycle statements, version identification methods, and interim mitigation guidance for delayed updates. Federal and highly regulated environments require clearer exception documentation, stronger visibility into unsupported software, explicit linkage between software state and risk acceptance, and documented mitigation plans with owners, timelines, and residual risk.
The Health-ISAC paper identified that secure cloud connectivity protects device-to-cloud communications and cloud-dependent functions. The baseline expectation is authenticated, encrypted, restricted connections to validated endpoints, certifications, certificates, or attestations supporting commercially reasonable security standards. Potential compensating controls include outbound-only design, private link, gateway mediation, and endpoint allowlisting. Typical evidence includes connection map, endpoint list, token/certificate model, and update-channel integrity.
This protects data exchanged with cloud-based services through authenticated, encrypted communications to approved endpoints, with documented data flows constrained to the minimum necessary endpoints, ports, and protocols. Full-OS devices should support modern TLS, sound certificate validation, and documented endpoint models visible to HDOs, while constrained devices may rely on gateway-mediated paths requiring documentation of the gateway and cloud architecture. Update delivery, telemetry, and analytics should be distinguished as they carry different risk profiles. Compensating controls include outbound-only patterns, private links, endpoint allowlisting, gateway mediation, and vendor disclosure of endpoint changes.
HDOs should request connection maps, data flow summaries, device-to-cloud identity models, and relevant cloud assurance evidence such as SOC 2 Type 2 reports or FedRAMP authorizations. Cloud connectivity should be evaluated as a specific trust pathway determining what data leaves the environment, where it goes, how trust is established, and what happens when the path fails or changes. Federal deployments require FedRAMP scope determination and agency-specific authorization.
Boundary Protection restricts unnecessary exposure at network and interface boundaries. The baseline expectation is a default-deny mindset, limited ports and services, and validated pathways. Potential compensating controls include VLANs, ACLs, NAC, host firewall, service hardening, and physical port controls. Typical evidence includes port/protocol list, network diagram, boundary rule set, and unsupported protocol list.
This restricts interfaces and communication paths between the device and surrounding networks through minimal exposure of only necessary ports, protocols, and services, with documented, validated communication pathways. Full-OS devices should support host firewalling, service hardening, and protocol reduction, with manufacturers disclosing communication requirements operationally rather than forcing reverse engineering. Embedded devices rely more heavily on surrounding network controls and physical protections, with port blockers, sealed interfaces, and segmented deployment reducing exposure.
Compensating controls include VLANs, ACLs, NAC, allowlisting, default-deny firewall rules, disabling unnecessary services, physical controls to service ports, and controlled service enclaves. HDOs should request port and protocol documentation, secure configuration instructions, and network diagrams showing intended communication paths. Boundary protection is often the most practical control for legacy and embedded medical technology and serves as a deliberate, documented compensating control in federal and highly regulated environments requiring stronger segmentation and explicit communication-path documentation.
In conclusion, the Health-ISAC paper provides a practical foundation for conversations between healthcare delivery organizations and medical device manufacturers working toward safe, secure patient care. As healthcare environments become increasingly interconnected, achieving this objective requires greater transparency, consistency, and collaboration across the product lifecycle. Security baselines identify capabilities commonly valued by HDOs during procurement and operations, while recognizing that medical technologies vary significantly in design, function, regulatory constraints, and technical capabilities. These baselines establish clear expectations for how manufacturers document, implement, and compensate for security choices, even when devices cannot implement every control identically.
“Rather than serving as a rigid checklist, these baselines are intended to support informed, risk-based decision-making,” the Health-ISAC paper noted. “The most effective security outcomes often result from a combination of native device capabilities, surrounding technical safeguards, operational processes, and documented compensating controls. Transparency regarding limitations, residual risks, and planned improvements is frequently more valuable than claims of perfect compliance.”
It added, “Ultimately, improving medical device cybersecurity is a shared responsibility. By focusing on practical risk reduction, clear accountability, and open collaboration, HDOs and MDMs can work together to improve resilience, support clinical operations, and help protect patient safety.”
