Cybersecurity Expectations for Connected Medical Software

Medical software connected to networks or the internet introduces new cybersecurity risks that must be addressed through clear expectations and controls. These systems must meet both general software safety requirements and specific cybersecurity standards to ensure patient safety and data protection. The MHRA and EU regulatory frameworks place strong emphasis on the security of software as a medical device (SaMD), particularly when such software is connected or cloud-based. The expectations for cybersecurity must be embedded into the design, development, and post-market surveillance of these systems.

Design and Development Controls

During the design phase, developers must apply risk-based thinking to identify potential cybersecurity threats. This includes considering how data is stored, transmitted, and accessed. For example, a connected glucose monitoring app must ensure encrypted data transmission and secure authentication to prevent unauthorised access. The software must also be resilient against common threats such as malware, unauthorised access, or data breaches. The ISO/IEC 27001 standard provides guidance on information security management, which aligns with these expectations. The software must undergo threat modelling and security testing, including penetration testing, to validate its resistance to cyber threats. Design controls must also ensure that software updates are secure and cannot be tampered with. Regular security assessments must be performed during development to identify vulnerabilities early.

Post-Market Surveillance and Incident Management

Once software is placed on the market, ongoing surveillance is required to monitor for cybersecurity incidents. This includes tracking any unauthorised access, data breaches, or software failures that may have security implications. For example, if a connected heart rate monitor experiences a data leak, the manufacturer must notify the relevant authorities and take corrective actions. The MHRA expects manufacturers to have a defined process for reporting such incidents, including clinical data or clinical evaluation updates if needed. The EU AI Act requires that AI systems, including those embedded in medical devices, must be monitored for compliance with transparency and safety obligations. The Digital Omnibus on AI, which came into force in July 2026, introduces further obligations for post-market surveillance, including machine-readable marking for generative AI systems placed on the market before August 2026.

• Incident reporting must be timely and thorough, including root cause analysis
• Post-market surveillance must include monitoring of software updates and patches
• Manufacturers must maintain records of any identified or reported cybersecurity issues

Compliance with AI Regulations

Medical software incorporating AI must comply with the EU AI Act, which applies to high-risk AI systems. The Act’s Article 5 prohibits certain practices such as social scoring or real-time biometric identification, which may apply to some clinical AI tools. The AI Act’s Article 4 requires AI literacy for personnel, and national supervision is expected to begin from August 2026. The Digital Omnibus on AI defers high-risk AI obligations to December 2027, but manufacturers must begin preparing now. The AI management system standard, ISO/IEC 42001:2023, provides a framework for implementing these controls. The standard is supported by certification bodies such as BSI, which became the first UKAS-accredited body in January 2026. The software must also meet the requirements of Regulation (EU) 2026/1744, which introduces new obligations for AI systems, including embedded products. These obligations must be reviewed against the software’s intended use and clinical context.

Organisations must ensure that their software development lifecycle includes cybersecurity as a core component. This involves training staff, conducting risk assessments, and maintaining audit trails. The software must be reviewed against the AI Act, EU regulations, and national guidance from the MHRA. Regular updates to software must be tested and validated to ensure they do not introduce new vulnerabilities. The goal is to maintain a secure environment for clinical data and patient safety, aligning with the evolving regulatory expectations for connected medical software.