Medical-device cybersecurity regulation

Sytance · Updated September 15, 2026

Medical-device cybersecurity addresses attacks that could affect a device’s safe and effective use. Its regulatory requirements concern the product’s design and the way the manufacturer maintains protection after release. The applicable rules depend on the market in which the device is supplied.

Safety and lifecycle regulation

A security weakness may allow an attacker to alter a clinical measurement or interrupt a device function. The analysis needs to explain the effect on the device’s intended use, then assess whether the design controls that risk. New vulnerabilities and software changes can require the assessment to be updated.

Regulatory layers

US submissions use FDA requirements and guidance; EU technical documentation addresses MDR or IVDR. The same test result may support both when it applies to the submitted device configuration. Each file still needs to explain which regulatory requirement that result supports.

FDA premarket

Explain the device’s security design and testing. Qualifying cyber-device submissions also need the information required by section 524B.

FDA postmarket

Assess new vulnerabilities, provide appropriate fixes and determine whether a field action needs to be reported.

EU MDR and MDCG

Explain how software security supports the device’s safety and performance, and provide the information needed for its intended IT environment.

Standards and records

IEC 81001-5-1 describes secure health-software development and maintenance. Product records show how the activities were applied to a device.

Cybersecurity records

The records explain different parts of the analysis. For example, an SBOM identifies a component used in the device, while a threat model explains how an attacker could exploit a weakness in it. A test result then helps determine whether the chosen protection works.

Security architecture explains the device boundary, data flows, trust boundaries, update path, and connected systems.
Threat modelling explains how misuse, attack paths, and control failures can affect safety or performance.
SBOM records software components so vulnerability monitoring and update decisions can be traced.
Labelling and user information explain secure use, minimum IT environment requirements, update handling and shared responsibilities.