Cybersecurity for Medical Devices in 2026

MDR/IVDR, secure development, NIS2 and the Cyber Resilience Act

Cybersecurity for medical devices extends beyond software testing. It connects product safety, organisational resilience, data protection and supplier management.

A useful starting point is to distinguish product cybersecurity, organisational cybersecurity and supply-chain cybersecurity. These overlap, but their requirements and responsibilities are not interchangeable.

1. MDR and IVDR provide the product requirements

For devices incorporating software and software that is itself a device, MDR Annex I Sections 17.2 and 17.4 and IVDR Annex I Sections 16.2 and 16.4 address software lifecycle processes, risk management including information security, verification, validation and minimum IT-security requirements. MDR Class I and IVDR Class A do not provide a general exemption from cybersecurity requirements.

MDCG 2019-16 Rev.1 — Guidance on Cybersecurity for Medical Devices explains how these requirements connect to design, documentation, operating environments and post-market surveillance. It is non-binding guidance, not legislation. Its references to the original NIS Directive should be read alongside current NIS2 legislation.

Sources: MDR · IVDR · MDCG 2019-16 Rev.1

2. Standards provide complementary tools

The following standards and technical publications address different parts of the lifecycle. They are not a checklist that automatically applies to every device.

Standard or publication and Main contribution:

IEC 81001-5-1:2021 — Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle. Secure development and maintenance of health software.

IEC 62304:2006+A1:2015 — Medical device software — Software life cycle processes. The medical-device software development and maintenance framework.

ISO 14971:2019 — Medical devices — Application of risk management to medical devices. Device risk management, including security-related safety consequences.

IEC 62443-4-1:2018 — Security for industrial automation and control systems — Part 4-1: Secure product development lifecycle requirements. Secure-development framework adapted for health sw by IEC 81001-5-1.

ISO 81001-1:2021 — Health software and health IT systems safety, effectiveness and security — Part 1: Principles and concepts. Common concepts across the health-software lifecycle.

IEC 80001-1:2021 — Application of risk management for IT-networks incorporating medical devices — Part 1: Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software. Risk management when integrating and operating connected health systems.

IEC TS 81001-2-2:2025 — Health software and health IT systems safety, effectiveness and security — Part 2-2: Coordination — Guidance for the implementation, disclosure and communication of security needs, risks and controls. Security communication between manufacturers, healthcare organisations and other stakeholders.

IEC TR 60601-4-5:2021 — Medical electrical equipment — Part 4-5: Guidance and interpretation — Safety-related technical security specifications. Technical security capabilities; also usable for medical device software, but excludes IVDs.

IEC 82304-1:2016 — Health software — Part 1: General requirements for product safety. Product-level safety and security for health software operating on general computing platforms without dedicated hardware.

Ask for more information: info@karkinen.com

3. Turn the requirements into lifecycle activities

For connected and cloud-based devices, six areas deserve particular attention.

• Architecture and threats. Identify assets, data flows, interfaces, trust boundaries and credible attack scenarios. Connect security risks to safety risk management where harm is possible. CVSS measures vulnerability severity; it is not a direct measure of attack probability or patient risk.

• Access and protection. Define authentication, role-based permissions, encryption, secure configurations and minimum network requirements. Document cloud hosting, data locations and responsibilities rather than assuming the hospital or cloud provider handles everything.

• Components. Maintain a Software Bill of Materials (SBOM) and use it to identify affected products when component vulnerabilities emerge. The SBOM is an inventory, not a substitute for vulnerability assessment.

• Testing. Select security feature tests, code analysis, vulnerability scanning, fuzz testing and penetration testing according to the product and risks. A successful penetration test is not proof of permanent security.

• Monitoring and resilience. Define security logging, incident detection, backup and recovery, and safe behaviour during service disruption.

• Updates and retirement. Establish vulnerability reporting, assessment, remediation, regression testing and secure update deployment. Communicate support limits and plan safe migration or decommissioning.

Useful supporting standards are ISO/IEC 29147:2018 — Information technology — Security techniques — Vulnerability disclosure and ISO/IEC 30111:2019 — Information technology — Security techniques — Vulnerability handling processes. They address receiving and communicating vulnerability information, and processing and remediating reported vulnerabilities.

Sources: MDCG 2019-16 rev. 1 · CVSS User Guide (FIRST) · ISO/IEC 29147 · ISO/IEC 30111

4. NIS2 concerns the organisation

NIS2, Directive (EU) 2022/2555, addresses organisational cybersecurity governance, risk management, incident handling, continuity and supply-chain security. Management oversight, training and clearly assigned responsibilities are central elements.

In Finland, the Cybersecurity Act 124/2025 implements NIS2. FIMEA supervises medical-device and IVD manufacturers within its remit. Applicability generally depends on sector and enterprise size, with additional size-independent criteria. Neither a low device class nor a small workforce alone settles applicability.

ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements provides a useful organisational framework. Certification is not, by itself, a NIS2 compliance guarantee or a universal NIS2 requirement.

Sources: NIS2 · Finnish Cybersecurity Act · FIMEA cybersecurity guidance · ISO/IEC 27001

5. CRA: distinguish the device from its components

The Cyber Resilience Act, Regulation (EU) 2024/2847, excludes products to which MDR or IVDR applies. However, separately marketed software or hardware components may fall within CRA scope, including commercial libraries, operating systems and middleware.

The component manufacturer may have CRA obligations. Incorporating that component does not, by itself, create CRA reporting obligations for the medical-device manufacturer. The latter retains its MDR/IVDR responsibilities. The same company may nevertheless have CRA obligations for separate, in-scope digital products it markets.

CRA Article 14 reporting obligations for actively exploited vulnerabilities and severe security incidents apply from 11 September 2026. Most remaining requirements apply from 11 December 2027.

Sources: Cyber Resilience Act · Commission reporting guidance

6. GDPR, AI Act and EHDS: additional layers

GDPR Article 32 requires controllers and processors to implement security appropriate to personal-data risks, including confidentiality, integrity, availability and recovery.

Source: GDPR

AI Act Article 15 establishes accuracy, robustness and cybersecurity requirements for high-risk AI systems. Assess the system’s classification and applicable implementation dates rather than assuming every AI-enabled medical device has identical obligations.

Source: AI Act — Article 15

EHDS, Regulation (EU) 2025/327, introduces future requirements where manufacturers claim interoperability with the harmonised software components of electronic health record systems. Article 27 links this to requirements for the European interoperability and logging components. Merely exchanging data with an EHR is not the complete applicability test. Relevant product requirements phase in during 2029 and 2031, depending on the health-data categories concerned.

Sources: EHDS Regulation — Articles 27 and 105 · Commission implementation timeline

7. Useful international guidance

Three IMDRF publications complement the European framework:

IMDRF/CYBER WG/N60 — Principles and Practices for Medical Device Cybersecurity covers the general lifecycle.

IMDRF/CYBER WG/N70 — Principles and Practices for the Cybersecurity of Legacy Medical Devices addresses cybersecurity of legacy devices, including support limitations.

IMDRF/CYBER WG/N73 — Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity provides dedicated SBOM guidance.

Sources: IMDRF N60 · IMDRF N70 · IMDRF N73

A short look at FDA

FDA’s February 2026 guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, addresses secure development and submission evidence.

For relevant premarket submissions involving a statutory cyber device, FD&C Act Section 524B requires vulnerability-monitoring and coordinated-disclosure plans, cybersecurity processes, updates and patches, and an SBOM covering commercial, open-source and off-the-shelf components.

FDA cybersecurity requirements deserve a separate blog.

Sources: FDA cybersecurity guidance · FDA Section 524B FAQs

What should manufacturers do?

My recommendation is to maintain a controlled Regulatory Requirements Register distinguishing applicable legislation, standards and guidance, with responsibilities, compliance evidence and justified non-applicability decisions.

For each device or device family, link the assessment to requirements, risk controls, verification, supplier management and post-market activities.

Incident procedures should distinguish MDR/IVDR vigilance, NIS2 reporting and GDPR breach notification. One incident may require several notifications when the respective criteria are met.

Source: FIMEA cybersecurity and reporting guidance

Cybersecurity is not a document completed at release. It is a lifecycle responsibility supported by evidence.

Need support with medical-device cybersecurity, secure-lifecycle gap analysis or regulatory applicability?

Quality and Regulatory Consulting

Expert services in medical device regulation and quality compliance.

contact information

Karkinen Consulting Oy, Helsinki, Finland
Business ID: 3103786-9
info@karkinen.com

© 2026. All rights reserved.