Labelling and User Information

Medical-device cybersecurity labelling and user information explain the security conditions needed to use the device safely and effectively. They turn risk controls, operating-environment assumptions, update paths and shared responsibilities into information that users and healthcare delivery organisations can act on.

User information as risk control

FDA treats cybersecurity transparency as part of safe and effective use and integration of devices. The information may appear in device labelling, operator manuals, administrator guides, customer security documentation, an MDS2, online portals or other controlled channels, depending on the intended user and information type.

EU MDR and IVDR files use a different legal structure. The manufacturer must state minimum requirements for hardware, IT network characteristics and IT security measures needed to run software as intended. MDCG 2019-16 then explains how that information connects to intended operating environment, secure configuration, patches, administrator information and healthcare-provider responsibilities.

For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.

Regulation (EU) 2017/745, Annex I 17.2

FDA labelling content

FDA's current premarket guidance lists examples of security information that can help users manage cybersecurity risks. The right level of detail depends on the intended audience. A patient-facing instruction should not read like a hospital network hardening guide, and an administrator guide should not hide operational details behind generic safety warnings.

EU user information

The EU file should connect user information to MDR or IVDR Annex I. For software and programmable systems, the important cybersecurity points are state of the art, risk management, information security, verification, validation, mobile-platform factors, minimum IT requirements and protection against unauthorised access.

  • Minimum hardware and workstation requirements for intended use.
  • IT network characteristics, including segmentation, communication paths, compatible services and supported protocols.
  • IT security measures such as access control, anti-malware expectations, firewall rules, patching assumptions, logging and backup.
  • Compatibility restrictions for connected devices, mobile platforms, cloud services, browsers, operating systems and security tools.
  • Risks of operating outside the intended operating environment.

MDCG 2019-16 also recognises that some detailed security information may sit outside the IFU, such as administrator instructions, security operation manuals, MDS2-style disclosure or installation guides. The information still needs to be controlled, current and consistent with the technical file.

Shared responsibility with healthcare organisations

MDCG 2019-16 describes cybersecurity as a joint responsibility across manufacturers, integrators, operators, users, patients and regulators, while the MDR and IVDR legal obligations remain manufacturer-focused. The practical point is that the manufacturer must communicate the external controls on which the device depends, and healthcare delivery organisations must operate the environment they control.

Manufacturer information

The manufacturer explains intended environment assumptions, configuration, update instructions, security events, support status and decommissioning when those points affect secure use.

Healthcare organisation controls

The organisation controls local network segmentation, account management, physical access, backup, monitoring, patching of its infrastructure and user training.

Update and patch communication

Update information needs to be practical before a vulnerability appears. FDA expects user-facing information about manufacturer- authorised software and firmware, how users know an update is available, support and end-of-life information, and how risks are transferred or communicated when support ends. Section 524B cyber devices also require plans for postmarket vulnerabilities, updates and patches.

Validated update path

Communication should match the validated update process, including authenticity checks, deployment steps, rollback limits and recovery expectations.

Operational constraints

User information should explain downtime, compatibility, required infrastructure, user action and compensating controls when patches cannot be applied immediately.

Primary sources

Sources