MHRA Cybersecurity Guidelines: Why Medical Device Penetration Testing Is Non-Negotiable

Medical devices now rely on much more than the device itself. Many depend on software, cloud services, mobile apps, APIs, or hospital networks to work as intended.

That creates a simple problem for manufacturers. A security flaw may not stop at data exposure. If someone can interfere with software, communications, or device settings, the effect can reach the device’s clinical function and, in some cases, patient safety.

The MHRA has already acknowledged these risks in networked medical devices, including tampering, malfunction, data loss, equipment damage, and possible injury. As products become more connected, MHRA medical device guidance is placing greater weight on software safety and cybersecurity.

Finding serious weaknesses late can mean more fixes, more validation work, and weaker evidence at the point of regulatory review.

Penetration testing gives manufacturers a way to identify weaknesses before they become harder and more expensive to address.

The UK Medical Devices Regulations 2002

Medical devices placed on the Great Britain market are regulated under the Medical Devices Regulations 2002, as amended. Great Britain covers England, Scotland, and Wales. Northern Ireland follows a different framework that applies EU medical device rules. 7

Under the UK Medical Devices Regulations, manufacturers must meet the applicable safety and performance requirements. Cybersecurity becomes relevant when a weakness could interfere with a device’s intended function or contribute to patient or user harm. 

How Cybersecurity Can Become a Patient Safety Risk

The safety concern starts when a weakness gives someone a way to interfere with the device. From there, the question is whether that interference can change what the device does in a clinically meaningful way and put the patient at risk.

For example, if a connected infusion system has an API that fails to properly authorise treatment changes, an attacker could alter a therapy parameter. If the device accepts that change, treatment delivery may be affected, and the patient could receive inappropriate therapy.

For medical device cybersecurity compliance, the important question is not only how severe a vulnerability appears technically. Manufacturers also need to determine whether exploitation could affect clinical behaviour, confidentiality, or safe operation.

Current Law vs MHRA’s Developing Cybersecurity Framework

Not every cybersecurity expectation associated with MHRA medical devices has the same legal status. Manufacturers should distinguish rules already in force from standards, guidance, NHS requirements, and proposals that may shape future compliance.

Why Post-Market Cybersecurity Matters

Cybersecurity problems can surface long after a device has been released. A library may develop a known vulnerability, an API may be changed, or a firmware update may introduce a new weakness.

Under the post-market surveillance rules in force in Great Britain from 16 June 2025, manufacturers need to keep reviewing new safety information after release. If a cybersecurity issue could affect the device’s safety or performance, it needs to be assessed and handled through the appropriate post-market process.

Adhering to the IEC 81001-5-1 Standard

IEC 81001-5-1 gives health software manufacturers a practical structure for managing cybersecurity throughout development and maintenance. The standard addresses cybersecurity across development and maintenance, beginning with planning and requirements and continuing through verification, vulnerability management, and problem resolution.

Manufacturers can use the standard to organise activities such as:

• Security planning and requirements
• Secure architecture and implementation
• Verification and security testing
• Vulnerability management
• Maintenance and problem resolution

Following this structure helps produce clearer evidence showing how security requirements were defined, implemented, tested, and maintained. 

One distinction matters for Great Britain. IEC 81001-5-1 should not be described as automatically giving every UKCA medical device presumption of conformity. Great Britain publishes its own designated standards under the UK MDR, and the current medical device list was updated on 17 January 2026. Formal designation claims should therefore be based on the applicable GB list and conformity route.

For manufacturers, IEC 81001-5-1 software security is most useful as a state-of-the-art framework for building consistent cybersecurity activities and evidence across the product lifecycle.

Connecting IEC 81001-5-1 With ISO 14971 Risk Management

Cybersecurity findings should feed into the medical device risk management process. IEC 81001-5-1 supports secure software lifecycle activities, while ISO 14971 helps manufacturers assess how a security issue could translate into patient or user harm.

For a connected device, the analysis should trace:

• The threat
• The weakness that makes exploitation possible
• The action an attacker could take
• The resulting change in device behaviour
• The hazardous situation that may follow
• The potential harm to a patient or user

Penetration testing can test whether that attack path is actually exploitable. The results then provide practical evidence to support the assumptions made during threat modelling and safety risk assessment.

The Critical Reality of the NHS DTAC Hurdles

Meeting medical device regulatory requirements does not automatically make a product ready for NHS adoption. A device may be legally placed on the Great Britain market and registered with the MHRA, yet an NHS organisation can still ask for additional technical, clinical, and security evidence before buying or deploying it.

DTAC is the NHS baseline assessment framework for digital health technologies. It looks at five areas:

• Clinical safety
• Data protection
• Technical security
• Interoperability
• Usability and accessibility

For suppliers of connected healthcare products, the technical security part deserves particular attention. NHS assurance material asks for evidence that security controls have been assessed, not simply a statement that the product is secure.

Why Penetration Testing Evidence Matters

NHS guidance associated with DTAC includes penetration testing among the evidence used to assess technical security. Current NHS regulatory support guidance states that an external penetration test covering relevant OWASP risks should be renewed every 12 months, with moderate and high risk issues addressed.

The 12-month point should not be treated as a universal legal rule for every NHS contract. Individual NHS organisations can set additional assurance requirements, and specific onboarding routes may impose their own testing conditions. Suppliers therefore need to check the requirements of the NHS buyer and assessment route they are entering.

A report can also become weak evidence before 12 months have passed if the product has changed substantially. A new API, redesigned authentication, cloud migration, firmware release, or major mobile application update may mean the tested version no longer represents the product being submitted.

Vulnerability Scan Is Not a Penetration Test: Vulnerability scanning identifies known or suspected weaknesses, often through automated checks. Penetration testers then investigate whether those weaknesses are exploitable and what access or impact they could produce.

A scanner may report no critical CVEs, yet manual testing can still uncover several smaller weaknesses. A tester may find that weak registration controls expose valid accounts, which then opens the door to privilege escalation and access to an undocumented API. If that API allows clinical settings to be changed without proper authorisation, a series of smaller weaknesses can turn into a serious product risk.

These attack chains matter for connected medical device vulnerabilities because authentication flaws, access control failures, and business logic weaknesses do not always map neatly to a known CVE.

Evidence to Prepare for NHS Technical Assurance

A supplier preparing for DTAC or an NHS procurement review should have current evidence covering:

• Penetration test scope and tested release
• Findings, remediation status, and retest results
• Cyber Essentials evidence where applicable
• Authentication and MFA controls
• Logging and security monitoring
• Vulnerability management
• Incident handling procedures

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

The Process Outline of a Compliant Medical Device Pentest

A medical device pentest should reflect the real product architecture. Testing only the physical device can miss weaknesses in the software and services that support its operation.

1. Scope the Entire Medical Device Ecosystem

Depending on the product, the scope may include:

Hardware and firmware

• Secure boot and firmware integrity
• Debug interfaces such as UART and JTAG
• Stored credentials and secrets
• Downgrade and firmware extraction attempts

Wireless interfaces

• Wi Fi, Bluetooth, BLE, NFC, or proprietary protocols
• Pairing and impersonation risks
• Replay attacks
• Encryption and key handling

APIs and mobile applications

• Authentication and authorisation
• Privilege escalation
• Session handling
• Undocumented endpoints
• Sensitive local storage
• Tampering and reverse engineering

Cloud and backend systems

• Identity and access management
• Tenant isolation
• Administrator privileges
• Exposed services and secrets
• Cloud configuration and logging

Update infrastructure

• Update authenticity and integrity
• Code signing
• Rollback and downgrade behaviour
• Update authorisation

The final scope should come from the architecture and threat model. For connected products, the goal is to test every component that could expose sensitive data, allow unauthorised access, or affect device behaviour.

2. Build the Pentest From the Threat Model

The threat model should tell the tester where to focus. It shows which parts of the product are exposed, which functions could affect clinical behaviour, and which attack paths deserve deeper testing.

Before testing begins, the manufacturer and tester should understand:

• Which assets and functions need the strongest protection?
• Which interfaces an attacker can reach remotely or through physical access?
• Where trust changes between the device, applications, cloud services, and users?
• Which commands or data changes could influence clinical behaviour?
• Whether a compromised component could affect other devices or services?
• What happens if measurements are altered, communications are delayed, or a service becomes unavailable?

3. Test Clinical Abuse Cases, Not Only Technical Exploits

Shell access or an authentication bypass confirms a security control failure. The tester should then trace what that access makes possible across the device and clinical functions.

Where relevant to the product, testers should check whether a compromise could:

• Suppress or alter alarms
• Change treatment settings or dosage
• Falsify measurements or diagnostic information
• Modify device configuration
• Delay clinically important data
• Interrupt operation or communications
• Prevent legitimate clinicians from accessing the system
• Install unauthorised firmware

MHRA medical device guidance already recognises cyber incidents that can affect dosing, device functions, alarms, patient information, and clinical decisions.

Each successful attack path should therefore be tied back to the possible clinical consequence and the risk controls intended to prevent it. That gives the penetration test more value than a list of technical findings alone.

4. Use Multiple Security Verification Methods

Different security methods find different kinds of problems, so relying on one test alone can leave gaps.

For medical device cybersecurity compliance, these methods work best together. Penetration testing adds the attacker’s view, but it does not replace code analysis, component analysis, fuzzing, or threat modelling. Each method covers a different part of the security picture.

5. Test in a Safe, Controlled Environment

Medical device security testing can affect device behaviour, communications, or availability. For that reason, active exploitation should not be carried out on equipment that is supporting patient care.

Where possible, testing should use an authorised environment that closely represents the intended setup. Before work begins, the manufacturer and tester should agree on:

• Permitted interfaces and testing techniques
• Actions that are not allowed
• Testing windows and clinical safety limits
• Emergency stop conditions
• Backup configuration and recovery steps
• Responsible contacts on both sides

6. Translate Findings Into Medical Device Risk

A confirmed vulnerability still needs to be assessed in the context of the actual device.

For each material finding, document:

• Affected component and required access
• Exploitability and attacker capability
• Clinical function affected
• Impact on confidentiality, integrity, or availability
• Resulting device behaviour
• Possible patient or user harm
• Existing controls
• Corrective action and residual risk

CVSS is useful for describing technical severity, but it is not a substitute for medical risk assessment. FIRST itself separates technical severity from environmental and safety considerations.

A moderate technical flaw may still have serious consequences if it alters treatment, alarms, or clinical information. MHRA medical device guidance recognises that cyber-related failures affecting these functions can lead to serious incidents.

7. Produce Audit-Ready Evidence

The report should make it clear exactly what was tested, which product version was assessed, what was found, and what happened after remediation.

At minimum, record:

• Device and product version
• Hardware, firmware, mobile app, API, and backend versions where relevant
• Included and excluded components
• Test dates and environment
• Methodology and tester independence
• Threat scenarios tested
• Vulnerabilities and exploit evidence
• Severity and affected controls
• Possible safety relevance
• Remediation recommendations
• Unresolved issues and accepted residual risk
• Retest outcome

MHRA medical device guidance for software-related submissions expects manufacturers to maintain clear software development, risk management, verification, configuration management, and problem resolution evidence.

A pentest report should fit into the rest of the product documentation. If the tested release cannot be matched to the version under review, the report becomes much harder to rely on during regulatory or procurement assessment.

8. Remediate and Retest

After remediation, the corrected build should undergo retesting before the finding is formally closed. The corrected version needs to be tested again.

Retesting should confirm that:

• The original exploit no longer works
• The underlying weakness has been removed
• The change has not opened another attack path
• Clinical functionality still behaves as intended

The result should be documented against the exact product version that was retested. IEC 81001 5 1 includes problem resolution and maintenance within the secure software lifecycle, which supports this approach.

9. Know When Another Pentest Is Needed

MHRA guidance does not set a blanket annual penetration testing rule for every medical device. The need for another assessment should depend on what has changed and whether that change affects the attack surface or risk profile.

Another pentest may be appropriate after:

• A major firmware or application release
• New APIs or connectivity features
• Changes to authentication or cryptography
• Cloud or architecture changes
• Important third-party component updates
• Remediation of significant vulnerabilities
• Newly discovered attack techniques relevant to the product

10. Use SBOMs and Pentesting for Different Questions

An SBOM helps manufacturers track the software components used in a device. It is useful for:

• Dependency inventories
• CVE monitoring
• Component updates
• Vulnerability response

It will not expose every weakness in the finished product. Access control flaws, hard-coded secrets, insecure trust relationships, custom code issues, and unsafe configurations may sit outside the component inventory.

Penetration testing covers that gap by testing how the complete product can actually be attacked.

Qualysec: Your Strategic Partner for MHRA and NHS Approvals

Qualysec provides penetration testing for connected medical devices and digital health products that combine firmware, APIs, cloud platforms, mobile applications, wireless interfaces, and external integrations.

Testing can be tailored through black box, grey box, or white box assessments, depending on the architecture, available access, and level of assurance required. The assessment can cover firmware security, hardware interfaces, authentication, access controls, communication protocols, encryption, update mechanisms, cloud interfaces, and third party connections.

Evidence Your Team Can Use

The engagement is designed to leave manufacturers with clear security evidence, including:

• Defined test scope and affected assets
• Reproducible findings with supporting proof
• Severity and remediation guidance
• Developer-focused reproduction details
• Retest results after remediation

This gives engineering and compliance teams material they can map into their own risk management and technical documentation.

Qualysec does not issue MHRA, UKCA, CE, or NHS approvals. It helps manufacturers prepare audit-ready MedTech VAPT evidence that can support wider UK regulatory and NHS technical assurance activities.

If you are preparing a connected device, SaMD product, or medical IoT system for the UK market, you can request a healthcare device penetration testing consultation or review Qualysec’s sample report before beginning the assessment.

Want a Sample Penetration Testing Report?

See how our experts document vulnerabilities, risk severity, and clear remediation steps.

Download Sample Report→

Conclusion

Cybersecurity for medical devices is not a one-time checkpoint. Products change after release, new vulnerabilities appear, and connected features can alter the risk profile over time. MHRA medical device guidance does not impose one identical penetration testing model on every device, but manufacturers still need evidence that security weaknesses affecting safety or performance have been properly assessed.

For companies targeting NHS adoption, that evidence also needs to be current enough for technical assurance and procurement review. As the GB framework continues to evolve, keeping cybersecurity work aligned with product changes is far stronger than trying to rebuild the evidence only when a submission or buyer asks for it.

FAQs

1. What are the specific MHRA medical device guidance rules regarding cybersecurity?

Great Britain still regulates medical devices under the UK MDR 2002, as amended. MHRA medical device guidance treats cybersecurity as relevant when compromise could affect safety or performance. Stricter post-market rules already apply, while further cybersecurity provisions remain under development.

2. What is IEC 81001 5 1, and why is it required for UKCA and CE marks?

IEC 81001-5-1 structures cybersecurity activities across health software development and maintenance, but it is not universally mandatory for UKCA or CE marking. Its regulatory role depends on the jurisdiction, conformity route, device, and applicable standards framework.

3. What happens if a connected medical device fails an NHS DTAC assessment?

DTAC is separate from MHRA market regulation. If an NHS organisation identifies security or assurance gaps, adoption may be delayed until the supplier provides stronger evidence, fixes weaknesses, updates documentation, or completes further testing required by that buyer.