UKCA Medical Device Cybersecurity Requirements: Compliance & VAPT Guide

A medical device can pass functional checks and still carry security weaknesses that only appear once it connects to real networks or hospital systems. For manufacturers entering Great Britain, that makes cybersecurity evidence much harder to treat as a final checkbox.

The pressure is growing as attacks on essential services become more serious. In the year ending August 2025, the NCSC handled 429 cyber incidents, including 204 that were considered nationally significant.

For manufacturers, the real question is not whether cybersecurity matters. It is what evidence regulators and healthcare buyers expect to see, and how testing supports that evidence.

Understanding UKCA medical device cybersecurity requirements means looking beyond a scan report or testing certificate. This guide explains where VAPT fits, and what manufacturers need to prepare.

The UK MedTech Regulatory Landscape: CE vs. UKCA

Great Britain regulates medical devices under the UK Medical Devices Regulations 2002, as amended. The MHRA oversees the market, while manufacturers are responsible for meeting the rules that apply to their device and keeping the required technical evidence.

The conformity route depends on device type and classification. A UK Approved Body is needed where third-party assessment applies, but many Class I devices can use self-declaration. Manufacturers outside the UK must appoint a UK Responsible Person.

For software and connected devices, UKCA medical device cybersecurity requirements become relevant where security weaknesses could affect safety, performance, data integrity, or intended operation.

Can CE Marked Medical Devices Still Enter Great Britain?

Yes. In 2026, UKCA is not the only route into Great Britain. Eligible CE-marked medical devices can still be placed on the market under transitional rules, with the deadline depending on the legislation and certification route used. EU MDR and EU IVDR-compliant devices are currently accepted until 30 June 2030, while some devices certified under earlier EU directives have shorter timelines.

MHRA also consulted in 2026 on indefinite recognition of devices meeting EU MDR and EU IVDR requirements. That proposal has not yet replaced the current deadlines in law.

UKCA vs. CE Cybersecurity Requirements

UKCA and CE both require manufacturers to show that a medical device is safe and performs as intended, but the cybersecurity wording is not the same.

For manufacturers, the key point is that an EU cybersecurity file can be useful for UKCA. Still, it should not simply be reused without checking how the evidence supports the applicable UK requirements.

Can Manufacturers Reuse EU MDR Cybersecurity Evidence?

Strong EU MDR cybersecurity evidence can often be reused for a UKCA submission. Useful material may include:

• Cybersecurity risk assessments and threat models
• Architecture and data flow diagrams
• SBOMs and secure development records
• Verification results and vulnerability procedures
• Penetration testing reports

The important part is the regulatory mapping. Existing evidence should be checked against the applicable UK MDR Essential Requirements instead of relying on an EU GSPR checklist alone.

A documented bridging assessment can show what evidence is reusable, where UK requirements are already covered, and whether further verification is needed. This approach also supports MHRA medical device cyber security guidance by keeping the technical file clear and traceable. Exact evidence expectations will still depend on device classification, architecture, and conformity route.

Core Cybersecurity Frameworks: MHRA & NHS DTAC

UKCA conformity and NHS assurance are separate. A device that meets Great Britain regulatory requirements may still need additional NHS DTAC compliance testing before adoption by an NHS organisation.

I. MHRA and Medical Device Cybersecurity

MHRA regulates medical device safety in the UK and oversees incidents once products are in use. Cybersecurity becomes relevant when a weakness could affect:

• Device operation or software behaviour
• Clinical data accuracy or integrity
• Access to functions or settings
• Availability of the device or service
• Patient or user safety

II. Supporting Cybersecurity Standards and Frameworks

These standards and frameworks support different parts of medical device cybersecurity. They should be selected based on the device, software, connectivity, and risk profile.

III. What Is NHS DTAC and How Is It Different From UKCA?

DTAC is the NHS assessment framework used to review software-based digital health technologies before adoption. It examines 5 areas:

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

DTAC does not replace UKCA or another recognised medical device conformity route. UKCA addresses whether a medical device meets the regulatory requirements for the Great Britain market. DTAC looks at whether digital technology meets the NHS baseline for safe and suitable deployment.

The distinction also matters for overseas manufacturers. UK Responsible Person medical device cyber responsibilities relate to regulatory representation, whereas DTAC is assessed separately for NHS use. Its technical security requirements can also require supporting security evidence beyond the medical device conformity file.

IV. NHS Penetration Testing Expectations

NHS security assurance can require current, independent penetration testing before a digital health product is accepted for use or integration. DTAC guidance says the external test should cover relevant OWASP Top 10 vulnerabilities, with moderate and high risk findings resolved. The evidence must be renewed every 12 months.

Requirements can become stricter depending on the NHS service or onboarding route. Some programmes require:

• Testing before go-live
• CHECK or CREST accredited testers
• Annual renewal
• Remediation plans for identified weaknesses
• Fresh testing after significant product changes

For manufacturers, NHS DTAC compliance testing should therefore be planned around the actual NHS deployment route rather than treated as a single universal pentest requirement.

See How Experts Spot and Fix Security Flaws?

Penetration testing is a mandatory step. Check out a real sample to see how security risks are found, written up, and fixed.

Download Sample VAPT Report→

Why Automated Scans Fail Audits

A vulnerability scan can tell you what known weaknesses are present. It does not always show what someone could actually do with them.

NIST separates vulnerability scanning from penetration testing for that reason. One is mainly used to find potential weaknesses. The other is used to validate them and see how far an attacker could go.

Vulnerability Assessment vs. Penetration Testing

A vulnerability assessment is useful for:

• Known CVEs
• Missing patches
• Exposed services
• Common configuration issues

Penetration testing looks deeper. A tester can try to bypass access controls and combine several smaller flaws into one attack path. OWASP notes that business logic weaknesses often depend on application-specific behaviour and usually require manual testing.

Why Scanner Output Alone Can Be Weak Regulatory Evidence

A clean scan does not automatically mean the product has no serious security problem. Automated tools mainly work from known signatures, exposed components, and recognisable configuration issues. 

They are much less reliable when the weakness depends on how the product is designed or used. They may also miss:

• Broken authorisation
• Unsafe workflow changes
• Chained attack paths
• Undocumented interfaces
• Firmware or protocol weaknesses
• Authentication design problems
• Update bypasses

For medical devices, the missing piece can be the most important one: what exploitation could do to the device, its data, or its clinical function. A scanner may report no critical CVEs while a meaningful attack path still exists. IMDRF guidance supports testing based on device design, connectivity, and likely attack vectors rather than relying on one testing method alone.

What Should Medical Device VAPT Actually Cover?

The test scope should follow the full product architecture, not just the physical device. IMDRF guidance specifically points to network ports, interfaces, connectivity, and supporting infrastructure as part of the security picture.

I. Device Interfaces

Relevant interfaces may include:

• Ethernet
• Wi Fi
• Bluetooth Low Energy
• NFC
• cellular connections
• USB and serial ports
• maintenance and service interfaces
• debug ports

Testing should check whether restricted services can be reached, settings can be changed without permission, debug functions expose sensitive data, or credentials and cryptographic material can be extracted. NIST also treats control over local and network interfaces as a core device security capability.

II. Authentication and Authorisation

Review:

• default and hardcoded credentials
• password controls
• session handling
• privilege separation
• account recovery
• access control enforcement
• excessive permissions
• privilege escalation
• MFA where appropriate

III. API Security

For SaMD, companion apps, and cloud-connected devices, test object-level authorisation, authentication, token handling, exposed API keys, privilege escalation, rate limits, replay, input validation, information disclosure, and server-side access checks.

A normal web application test should not be assumed to cover API specific risks.

IV. Mobile Applications

Where a mobile app forms part of the product, review:

• Local data storage
• Keychain or Keystore use
• Hardcoded secrets
• Reverse engineering exposure
• Certificate validation
• Authentication and sessions
• Root or jailbreak behaviour
• Deep links
• API communication

V. Firmware and Embedded Software

Testing should cover firmware extraction, embedded credentials, signing controls, secure boot, cryptographic keys, debug access, exposed libraries, rollback behaviour, and unauthorised modification.

VI. Wireless Security

For Wi Fi, BLE, NFC, or proprietary radio, assess pairing, authentication, replay, eavesdropping, spoofing, unauthorised commands, downgrade behaviour, and session security.

VII. Secure Update Mechanism

Update testing should verify that:

• Packages are signed
• Signatures are actually checked
• Modified packages are rejected
• Unauthorised firmware cannot be installed
• Downgrade and rollback behaviour is controlled
• Interrupted updates do not leave the device unsafe
• Update provenance can be established

NIST identifies authorised, secure software updating as a core capability for connected devices.

VIII. Cloud Infrastructure

Where the medical device relies on backend services, include relevant cloud applications, IAM, storage, databases, containers, Kubernetes, serverless services, secrets, logging, tenant isolation, backups, and recovery controls.

Testing only the hardware can leave some of the most reachable parts of the product outside scope.

Threat Model Driven VAPT

A useful penetration test starts with the product, not the toolset. IMDRF recommends threat modelling as part of medical device security risk assessment because it helps manufacturers understand how the device could be attacked and which controls need verification.

I. Identify Assets

Start with what needs protection, such as:

• Therapy parameters
• Diagnostic results
• Firmware
• Cryptographic keys
• Patient identifiers
• Authentication tokens
• Device configuration
• Cloud credentials

II. Identify Threat Actors

Consider who could realistically attack the product:

• Remote attackers
• Compromised users
• Malicious insiders
• Attackers with temporary physical access
• Compromised clinical systems
• Supply chain attackers

III. Map Attack Surfaces

Then connect those assets and threat actors to the places they could reach, including hardware, firmware, wireless links, APIs, mobile apps, cloud services, web portals, and third-party integrations.

IV. Derive Test Cases

The threat model should turn into specific attack questions rather than a generic checklist. For example, can a patient account reach a clinician-only API function and alter a therapy setting?

That gives the VAPT team clear hypotheses to test and keeps the assessment tied to the device’s actual architecture and risk.

Step-by-Step Security Roadmap to Enter the UK Market

Step 1: Confirm the Device’s UK Regulatory Route

First, establish how the product is regulated in Great Britain. For software, intended purpose is central to deciding whether it qualifies as a medical device or IVD, and classification determines the conformity route that follows.

Record:

• Device or IVD status
• Intended purpose and classification
• Applicable UK MDR provisions
• Whether a UK Approved Body is needed
• Whether a UK Responsible Person is required
• Whether the route uses UKCA, recognised CE marking, or both

This gives you the regulatory basis for UK MDR 2002 software compliance before security evidence is mapped.

Northern Ireland needs a separate route because EU MDR and EU IVDR rules apply there, with CE or CE UKNI marking as applicable.

Step 2: Map the Complete Cybersecurity Attack Surface

Build an architecture inventory for the whole product ecosystem. NCSC guidance recommends looking at the overall system architecture because securing individual components does not guarantee that the complete system is secure.

Map every component that could expose data, accept commands, provide access, or influence device behaviour:

• Physical device
• Embedded software and firmware
• Operating system
• Bluetooth and Wi Fi connections
• Mobile companion app
• APIs and clinician portal
• Cloud infrastructure
• Authentication provider
• Update service
• Third-party integrations
• External libraries and SDKs

IMDRF also treats device design, connectivity, software components, and potential attack vectors as part of medical device cybersecurity assessment.

This inventory becomes the basis for deciding what must be included in the VAPT scope.

Step 3: Perform Threat Modelling and Cybersecurity Risk Analysis

List the assets that matter, who could target them, where trust boundaries sit, and how the product could be misused.

Check whether an attack could:

• Expose or alter sensitive data
• Interrupt availability
• Bypass authentication
• Defeat authorisation controls
• Change device functions or settings

The final step is to connect any meaningful cyber consequence to medical device safety risk. MHRA’s software reform programme explicitly recognises that malicious or accidental interference can cause malfunction, data loss or tampering, device damage, and patient injury.

Step 4: Establish Security Requirements and Risk Controls

Define clear security requirements for the risks that need control. Depending on the product, these may cover authentication, server-side authorisation, least privilege, encryption, key protection, secure boot, signed firmware, protected updates, session controls, logging, network restrictions, secure defaults, tamper resistance, and recovery. 

Each control should be written so it can be tested. For example, an update requirement should state that unauthorised or altered software must be rejected before installation.

Step 5: Manage Third-Party Components and Build an SBOM

Third-party components are the software packages your device depends on, such as open source libraries, SDKs, drivers, operating systems, frameworks, and vendor-supplied modules. NCSC recommends keeping a clear inventory of these dependencies because vulnerabilities can enter through any part of the software supply chain.

An SBOM should tell you which component and version appear in each product release, whether it has a known vulnerability, and whether a fix is available. That makes it much easier to find affected devices when a new issue is disclosed.

Step 6: Build a Layered Security Verification Programme

VAPT should sit inside a broader verification programme. Different checks uncover different classes of weakness, so relying on one method leaves gaps.

• Threat modelling: Defines credible attack scenarios.
• Security design review: Checks whether controls make sense at the architecture level.
• Static testing: Finds weaknesses in source code.
• Software composition analysis: Identifies vulnerable dependencies.
• Secrets scanning: Catches exposed credentials, tokens, and keys.
• SBOM analysis: Links known vulnerabilities to product components.
• Dynamic testing: Checks the running application.
• API testing: Examines authentication, authorisation, tokens, and request handling.
• Firmware analysis: Reviews embedded code and binaries.
• Wireless testing: Checks pairing, communication, and command handling.
• Fuzz testing: Sends malformed input to expose unexpected failures.
• Configuration review: Finds unsafe settings and unnecessary exposure.
• Manual penetration testing: Follows realistic attack paths across the product.
• Remediation: Fixes confirmed weaknesses.
• Retesting: Confirms those fixes work.
• Security regression testing: Checks that later changes have not reopened earlier weaknesses.

Step 7: Conduct Risk-Based VAPT

The depth of VAPT should reflect how exposed the product is and what could happen if its security controls fail. A device with internet access, wireless communication, cloud dependencies, or treatment functions generally needs more intensive testing than isolated hardware with little digital exposure. 

MHRA notes that interference with connected medical devices can lead to malfunction, data tampering, device damage, and patient injury. 

Step 8: Remediate Findings and Perform Retesting

A finding should not be considered closed just because it appears in the VAPT report. For each material issue, document the root cause, exploitability, possible safety impact, corrective action, and any residual risk.

Once the fix is applied, retest the affected attack path and run regression checks where the change could affect nearby functions. 

Unresolved critical findings provide much weaker assurance than evidence showing that the issue was fixed, verified, retested, and formally closed.

Step 9: Build a UKCA Cybersecurity Evidence Pack

By this stage, the security work should be traceable in the technical documentation rather than scattered across engineering tickets, test reports, and supplier records.

Governance Evidence

Keep the documents that show how cybersecurity is managed, including the cybersecurity plan, assigned responsibilities, secure development procedures, vulnerability management process, incident response plan, and coordinated vulnerability disclosure procedure.

Architecture Evidence

Include enough technical detail to understand the product and its exposure. System diagrams, data flows, trust boundaries, interfaces, assets, and the intended deployment environment are especially useful.

Risk Evidence

The file should connect identified threats with controls and safety consequences. Relevant records can include the threat model, cybersecurity risk assessment, security requirements, safety linkage, and risk control matrix.

Software Composition Evidence

Keep the SBOM alongside dependency records, third-party component information, vulnerability findings, and relevant supplier security evidence.

Verification Evidence

Retain the testing that supports your security claims. Depending on the product, this may include SAST, SCA, DAST, API, mobile, firmware, wireless, and penetration testing results. Remediation records and retest evidence should sit with the original findings.

Lifecycle Evidence

Security documentation also needs to remain useful after release. Capture the update and patch process, vulnerability reporting route, incident response arrangements, stated support period, and plans for products reaching end of support.

Step 10: Create Cybersecurity Traceability

Keep each significant cyber risk traceable from the original threat through the vulnerability, safety impact, security requirement, control, verification method, and final evidence. This makes it easier to show how identified risks were addressed and whether the chosen controls were actually tested.

Step 11: Make the Penetration Test Report Regulatory Useful

The report should make the tested setup easy to identify. Record:

• Device and software versions
• APIs, apps, backend, and interfaces tested
• Scope, exclusions, dates, and methodology
• Findings and exploitation evidence
• Remediation and retest results

Step 12: Prepare for NHS Security Assurance Where Applicable

Before NHS deployment, confirm the exact assurance requirements for the product and service being used. Check whether DTAC applies, whether the NHS organisation expects CHECK or CREST accredited testing, what pentest scope it accepts, which findings must be closed, and how often evidence needs refreshing. NHS England also notes that assurance may need review after significant product changes.

Step 13: Establish Post-Market Cybersecurity Monitoring

From 16 June 2025, stronger PMS rules apply to relevant devices entering use in Great Britain, whether they rely on CE or UKCA conformity.

For cybersecurity, that means watching for new vulnerabilities, checking affected components, reviewing incoming reports, judging safety impact, fixing issues, recording decisions, and reporting incidents where the rules require it.

Step 14: Retest After Security-Relevant Changes

Retesting should follow changes that can alter the device’s security or safety profile, such as major firmware updates, new APIs, cloud migrations, wireless features, authentication changes, dependency updates, or significant vulnerability fixes. UKCA itself does not set a fixed annual pentest schedule.

Step 15: Plan for Legacy and End of Support Devices

A medical device can remain in service after an operating system, library, chipset, communications module, or commercial software component stops receiving security support. IMDRF warns that this can limit the manufacturer’s ability to keep the device secure.

When patching is no longer possible, options may include network segmentation, tighter access controls, restricted interfaces, compensating controls, closer monitoring, customer notices, and replacement planning. Support dates and end-of-support arrangements should also be made clear before the device becomes difficult to maintain securely.

How Qualysec Accelerates Your UKCA Compliance & NHS Market Access

For manufacturers preparing connected devices or SaMD for Great Britain, security testing is most useful when it produces evidence that can be carried into remediation, technical documentation, and NHS assurance. Qualysec focuses on that testing role rather than certification itself.

Architecture Aware VAPT Scope

Qualysec can assess web applications, mobile apps, APIs, cloud systems, external networks, IoT devices, and embedded environments. This allows the scope to follow the real attack surface of the product.

Manual and Automated Testing

Its process combines automated discovery with manual exploitation. This helps uncover business logic issues, authentication weaknesses, and attack paths that scanners may not confirm on their own.

Reporting and Retesting

Qualysec reports include technical findings, risk details, remediation guidance, and validation of fixes through retesting. Sample reports are also available for review.

Before You Start, share the product versions, architecture, interfaces, endpoints, test accounts, and any NHS assurance requirements that could affect scope.

If you are preparing a medical device or SaMD for GB or NHS deployment, you can request a scope consultation or VAPT quote from Qualysec.

Conclusion

Cybersecurity evidence becomes more important as a medical device gains software, connectivity, and safety-sensitive functions. UKCA does not require every device to undergo the same third-party pentest, but manufacturers still need credible proof that relevant security risks have been addressed.

The strongest evidence connects identified threats with controls, testing, remediation, safety impact, and ongoing monitoring. NHS deployment may bring a separate set of technical security expectations, so plan for that route independently.

Building this evidence during development is far easier than trying to reconstruct it when an approved body or NHS organisation asks for it.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

FAQs

1. What are the cybersecurity requirements for a medical device to get a UKCA mark?

UKCA does not currently impose one cybersecurity checklist or mandatory pentest for every device. Manufacturers must meet the applicable UK MDR 2002 requirements and support safety and performance claims with suitable technical evidence. Stronger explicit cyber requirements remain part of MHRA’s future framework.

2. Does my medical device need NHS DTAC compliance testing to enter the UK?

No. DTAC is not a condition for entering the Great Britain medical device market. It becomes relevant when digital health products are considered for NHS use, where technical security evidence and current penetration testing may also be requested.

3. Can I use my EU MDR cybersecurity documentation for MHRA registration?

Much of your EU MDR evidence may still be useful, including threat models, SBOMs, risk assessments, and test reports. For UKCA, map that evidence to UK MDR 2002 requirements. MHRA registration itself is a separate legal obligation, not conformity approval.

4. How often does a medical device need penetration testing for UK compliance?

UKCA sets no fixed annual pentest cycle for every medical device. Retest when meaningful software, firmware, API, authentication, wireless, cloud, or security changes alter risk. NHS assurance may separately require external testing to be renewed every 12 months.

5. What happens if an Approved Body rejects my device’s cybersecurity documentation?

An Approved Body may ask for more evidence or identify gaps rather than permanently reject the device. You may need to strengthen risk analysis, traceability, testing scope, remediation records, or component evidence, then submit updated documentation and retest results where relevant.