Medical Device Cybersecurity Design: Principles, Standards, and Best Practices

Designing secure embedded systems for medical devices

There is a persistent assumption in connected medical device development: that medical device cybersecurity design and privacy are checklist items that can be layered on near the end of the design process. First, you conceptualise, prototype, and build the device, validate the core functionality. Then, somewhere between EMC testing and conformity assessment prep, you bolt on encryption, add an authentication screen, and call it compliant.

In the UK specifically, the primary cybersecurity assumption failing UK medical device teams is that medical device security is solely an IT issue rather than a core clinical and patient safety risk. This misconception leads to treating cybersecurity as a post-market compliance check, rather than an integral part of device design, clinical risk management, and patient care. Under the UK’s evolving regulatory framework, this is becoming a genuine liability.

The MHRA’s Future Regulation of Medical Devices (FRMD) programme, now well into its implementation phase, is systematically elevating cybersecurity from a good-practice aspiration to a mandated essential requirement. The programme, representing a comprehensive overhaul of the regulatory framework to improve patient safety, increase transparency, and foster innovation, includes:

• Post-market surveillance (PMS) regulations which came into force in June 2025.
• Dedicated cybersecurity guidance for Software as a Medical Device (SaMD).
• Enhanced regulations for AI as a medical device (AIaMD)
• Pre-market requirements
• Recognised approvals from trusted jurisdictions

The UK government’s formal policy position is explicit: cybersecurity will be an essential requirement for all medical devices under the forthcoming pre-market statutory instrument, expected in 2026. And for any manufacturer with NHS ambitions, the procurement landscape has already moved: Cyber Essentials Plus certification is now mandated for NHS suppliers under Procurement Policy Note 014.

This is the fourth post in our series on wireless and connected medical device design, building on our previous work covering BLE integration, wireless charging in medical wearables, and IEC 60601 wireless compliance. Here, we tackle the upstream design challenge those topics point towards: how do you prioritise medical device cybersecurity design – especially for connected products – and how does the UK regulatory and procurement environment now define what that means?

What ‘Privacy by Design’ means in a medical context

Privacy by Design (PbD) is a framework with seven foundational principles, developed by Ann Cavoukian and now codified in the UK GDPR Article 25 (data protection by design and by default). In consumer tech, it is often reduced to cookie consent flows and data minimisation policies. In medical device engineering, where highly sensitive personal health information will be processed, the consequences of getting it wrong are clinical and a violation of users’ privacy rights, not just reputational.

For a wearable cardiac monitor, a BLE-connected continuous glucose sensor, or a remote patient monitoring hub, the data transmitted is physiological, such as heart rhythms, glucose trajectories, and blood pressure readings. Therefore, unauthorised data exposure or a tampered command injection is more of a patient safety incident than an IT glitch. The MHRA’s June 2025 PMS regulations make this connection explicit, treating cybersecurity incidents that could affect device function as safety violations subject to mandatory reporting timelines.

The seven Privacy by Design principles, applied to medical hardware design, translate to architecture decisions made at component selection and system design stage and not at verification:

1. Proactive, not reactive. Threat modelling must happen before PCB layout is finalised. Identifying the attack surface of a BLE GATT characteristic is straightforward during design review; post-verification, however, it can mean a hardware respin or an unplanned security patch cycle before launch.
2. Privacy as the default. Data collection should be scoped to clinical necessity. If a device only needs to transmit daily summary statistics to a companion app, it should not be logging raw sensor streams to persistent flash by default. Every data field should have a justified clinical reason for existing (i.e., a principle directly aligned with UK GDPR’s data minimisation requirements).
3. Privacy embedded into design. Encryption, authentication, and access control are architecture decisions, not add-on features. AES-128-CCM for BLE connections, certificate-based device authentication, and hardware-backed secure key storage need to be on the component selection checklist at the concept stage.
4. Full functionality, no false trade-offs. The instinct to treat security as a penalty on power budget or processor overhead is usually a sign that it was not planned early enough. Modern Bluetooth SoCs from Nordic, Silicon Labs, and STMicro offload cryptographic operations to dedicated hardware with negligible impact on system performance.
5. End-to-end security across the full lifecycle. A medical device will receive firmware updates, be deployed across multiple NHS trust networks, and be paired and unpaired across its operational lifetime. The security architecture must survive all of those state transitions, not just the nominal use case.
6. Visibility and transparency. Under the MHRA’s PMS framework, device behaviour (i.e., what data is collected, where it is sent, and how long it is retained) must be auditable and reportable. The technical file must support this.
7. Respect for user privacy, keep it user-centric. For devices used in home settings (in the scope of IEC 60601-1-11), the patient is the primary operator. Consent flows, data access controls, and deidentification options must be accessible to non-technical users without degrading security posture

The UK medical device regulatory landscape

The UK regulatory picture for connected medical devices is more nuanced than the ‘post-Brexit equivalent of EU MDR’ framing suggests. It involves three overlapping layers to a new framework that’s stricter, more tailored and proactive: the existing UK Medical Devices Regulations 2002 (as amended), the MHRA’s active reform programme, and an NHS procurement framework that has independently raised its cybersecurity bar.

The existing framework and CE (conformity assessment) mark transitional arrangements. CE-marked devices from EU MDR/IVDR regimes can still be placed on the Great Britain market under transitional provisions running to 2028 for most device classes and 2030 for some. However, this will eventually be phased out entirely and replaced by the UKCA (UK Conformity Assessed) mark as its own regulatory standard. This does not mean cybersecurity expectations are deferred. The existing UK MDR incorporates essential requirements, including safety-related software obligations, and the MHRA enforces them.

MHRA Post-Market Surveillance Regulations (in effect June 2025). The Medical Devices (Post-market Surveillance Requirements) (Amendment) (Great Britain) Regulations 2024 came into force on 16 June 2025. They apply to all devices placed on the market or put into service from that date, regardless of whether they have a CE or UKCA mark. They explicitly extend to Software as a Medical Device. The regulations integrate cybersecurity directly into the PMS framework: manufacturers must proactively monitor for threats and vulnerabilities, track known CVEs in device software and third-party components, and feed post-market cyber risk data back into risk management documentation. Any serious incident arising from a cyber vulnerability must be reported to the MHRA within 15 days. For threats posing a serious public health risk, the window is two days. Security patches for critical cyber issues must be issued as formal Field Safety Corrective Actions (FSCAs), with associated Field Safety Notices reviewed by the MHRA before deployment.

Cybersecurity as an essential requirement (the pre-market SI). The MHRA’s December 2024 roadmap and the UK government’s formal consultation response both confirm that cybersecurity will be included as an essential requirement for SaMD under the forthcoming pre-market statutory instrument (SI), expected to come into force in 2026. The government’s documented policy position is unambiguous: cybersecurity is a condition of market authorisation for connected medical devices, not a design option.

MHRA cybersecurity guidance for SaMD and AIaMD. Dedicated MHRA cybersecurity guidance for AI and Software as a Medical Device was confirmed for publication as part of the 2025 reform roadmap. It is expected to align with the international regulatory consensus being developed through the IMDRF working groups involving the MHRA, FDA, and Health Canada. Teams developing devices now should be designing to IEC 81001-5-1 and ISO 14971 as the practical technical framework, and the MHRA’s guidance is unlikely to deviate significantly from this.

UK GDPR (General Data Protection Regulation). Post-Brexit, the UK retained GDPR as domestic law. Article 25 (data protection by design and by default) applies to any connected medical device processing UK patients’ personal data. The ICO has demonstrated willingness to fine data processors directly for security failures: Advanced (£3.07M) and Capita (£14M) are the relevant precedents. Maximum penalties are £17.5 million or 4% of global turnover.

Northern Ireland. Devices placed on the market in Northern Ireland are subject to EU MDR 2017/745 and EU IVDR 2017/746 PMS requirements and do not fall under Great Britain requirements. Teams targeting the full UK market need to account for this dual framework. In practice, the more demanding requirement from each framework applies.

The NCSC dimension. The MHRA’s reform programme explicitly involves the National Cyber Security Centre, and the NHS Supply Chain cybersecurity requirements reference NCSC guidance directly. For UK medical device manufacturers, NCSC’s Cyber Essentials framework is not just a procurement credential: it’s the recognised baseline for what “adequate cybersecurity controls” means in a UK government and NHS context.

Early-stage architecture decisions that make or break medical device security

The following are the hardware and firmware decisions with the highest security and safety impact, i.e., choices that are expensive or effectively impossible to change after bring-up.

Hardware-backed key storage. Private keys used for device identity and firmware signature verification should be stored in dedicated hardware-backed secure storage. Modern Bluetooth SoCs (Nordic nRF5340, Silicon Labs EFR32) include ARM TrustZone or dedicated cryptographic accelerators. Discrete secure elements (Microchip ATECC608, NXP SE050) provide a higher assurance level appropriate for Class IIb and Class III devices. Software-only key storage in general-purpose flash is difficult to justify in a threat model aligned with IEC 81001-5-1 expectations.

Secure boot chain. Every firmware image loaded at startup should be cryptographically verified against a known-good public key held in write-protected memory. The chain runs: ROM bootloader → signed primary bootloader → signed application image. Any break in this chain should prevent execution, and not silently fall through to unverified code. The MHRA’s FSCA patch obligations make a broken or absent secure boot chain a post-market compliance risk as well as a security one.

BLE pairing model. Unauthenticated BLE pairing (Just Works) is only defensible for devices with no PHI exposure and no ability to receive configuration commands. Any device transmitting patient data or accepting therapeutic parameters must use LE Secure Connections with Numeric Comparison or Passkey Entry, with bonding enabled to prevent unauthorised re-pairing. GATT service permissions should restrict both read and write access to authenticated, bonded centrals.

Minimal on-device data footprint. Every byte of patient data stored on-device is both a UK GDPR exposure and a physical attack surface. Design data retention policies into the firmware architecture from the outset: define a maximum local storage duration, implement automatic purge after a confirmed sync, and ensure that factory reset genuinely zeroes patient data rather than simply clearing filesystem pointers. UK GDPR’s right to erasure has direct, practical implementation consequences for connected medical hardware.

OTA firmware update security. Over-the-air updates are essential for meeting MHRA post-market vulnerability management obligations. However, an unsigned, untested OTA path is itself a critical vulnerability. The updated architecture must enforce image signing (ECDSA or EdDSA), require version validation before acceptance, provide rollback protection against downgrades to known-vulnerable versions, and verify image integrity (SHA-256) before applying an image. The MHRA’s requirement to issue security patches as FSCAs assumes a reliable, controlled, field-proven OTA mechanism exists.

Where teams go wrong: Common UK medical device security anti-patterns

Medical device security in the UK, particularly within the NHS, often suffers from structural, technical, and cultural anti-patterns that prioritise operational convenience or legacy support over patient safety and data security. These anti-patterns are compounded by regulatory pressures, such as the MHRA guidance and the Digital Technology Assessment Criteria (DTAC) and include:

• Architectural & Network Flaws: Risks driven by flattened network topographies and ‘browse-up’ administration, where a lack of segmentation allows lateral movement from general IT systems to life-critical clinical environments.
• Operational & Maintenance Gaps: The persistence of unpatchable legacy systems and poor asset visibility, often exacerbated by a ‘checkbox’ compliance culture that prioritises annual assessments over real-time threat detection.
• Insecure Design & Development: A failure to adopt secure-by-design principles, evidenced by the use of hardcoded default credentials, unencrypted data transmission (e.g., DICOM), and treating security as a post-market add-on.
• Governance & Third-Party Risk: Fragmented accountability between manufacturers and healthcare providers regarding patch management, alongside a critical underestimation of supply chain vulnerabilities and unmonitored vendor access.

Several failure modes appear consistently across connected medical device programmes:

1. Security requirements added at V&V rather than specified as design inputs. The result is either a failed test that forces redesign, or a rationalisation that the observed behaviour is acceptable. Under the MHRA’s framework, security requirements must be traceable design inputs in the technical file, specified before verification testing begins.
2. Companion app scoped out of the regulated device system. The companion app is part of the regulated system. An insecure app that transmits PHI over inadequately protected channels or accepts arbitrary Bluetooth connections undermines a well-designed hardware platform. The MHRA’s PMS obligations and the UK GDPR both cover the full data processing chain, not just hardware in isolation.
3. Development credentials in production builds. Default passwords, hardcoded API keys, and enabled debug interfaces in production firmware are among the most common findings in medical device security assessments. Production build processes must include automated checks for these, embedded in the CI/CD pipeline as a standard gate.
4. No delineation of safety-critical versus non-safety-critical software. IEC 62304 requires software to be classified by safety class. Firmware components implementing therapeutic or diagnostic functions carry different security obligations than configuration or UI code. Uniform security controls across the entire codebase are both wasteful and insufficient: under-resourced for the high-consequence paths, over-engineered for the rest.
5. Ignoring physical attack surfaces in production. In hospital and clinical environments, devices are accessible to a wide range of individuals. Debug interfaces (JTAG, UART), unprotected test points, and exposed connectors are physical attack surfaces. Post-production security hardening (disabling debug interfaces, setting flash read protection, removing test firmware) must be part of the manufacturing process with documented verification.

Design connected medical devices for auditability

A device that is genuinely secure but cannot demonstrate it through documentation will not pass MHRA technical file review. Equally, a device with superficial security controls and comprehensive documentation may clear initial review but will not survive a post-market audit or a real-world incident investigation.

The documentation set that supports a strong UK cybersecurity submission includes: a threat model (STRIDE or equivalent) with identified threats, assessed risks, and mitigating controls traceable to design decisions; a cybersecurity risk assessment integrated with the ISO 14971 risk file; architecture diagrams showing all communication interfaces and trust boundaries; a Software Bill of Materials; a vulnerability management plan; and a post-market monitoring and FSCA patch response procedure. For devices where the MHRA’s pre-market SI applies (from 2026), cybersecurity will also form part of the essential requirements conformity assessment.

Building this documentation alongside the design, and not retrospectively, is the only approach that maintains genuine traceability. When the MHRA asks how a specific attack surface was mitigated, the answer needs to trace from the threat model to the design decision to the verified implementation, not be reconstructed from the device engineer’s memory before a response submission deadline.

Final Thoughts: Privacy by Design is a UK market differentiator

The framing of security and privacy as a compliance overhead misrepresents the actual market dynamic. NHS procurement teams, integrated care board digital leads, and health system CISOs assess device security posture as a standard part of supplier qualification. A connected medical device with a weak security architecture, or a manufacturer that cannot evidence Cyber Essentials Plus and DSPT compliance, will not progress past NHS procurement pre-qualification.

Conversely, devices with documented threat models, hardware-backed key storage, signed firmware, and a credible post-market vulnerability programme are better positioned for NHS procurement, are more straightforward to review through MHRA technical file review, and are more defensible when a post-market security issue arises. The NHS is the largest single healthcare buyer in the UK. For MedTech companies with UK market ambitions, their device security posture is now directly tied to their market viability.

If you are developing a connected medical device and want to discuss what privacy by design looks like for your specific product architecture and UK market pathway, get in touch with an expert on our team.