Medical-device Cybersecurity

Cybersecurity protects the medical purpose

Medical-device cybersecurity is the protection of device functions, data and connected services from unauthorised access, alteration, disclosure, disruption or misuse. Its purpose is not simply to protect an IT system. It is to preserve safe and effective operation, trustworthy information and appropriate availability throughout the device lifetime.

A vulnerability may affect confidentiality without creating immediate patient harm. Another may manipulate therapy, suppress an alarm or make a diagnostic service unavailable. The organisation must understand both the security consequence and any resulting safety, clinical, privacy, operational or business consequence.

Cybersecurity is a total-product-lifecycle responsibility

Security decisions begin with product definition and continue after the last unit is manufactured. Threats, attacker capability, third-party components and operating environments all change, so a one-time penetration test cannot establish lifetime security.

Management should define accountability, competence, decision authority, escalation paths and resources for the complete lifecycle. Product cybersecurity, enterprise IT security and data protection need clear interfaces, but none can silently assume that another team owns the device risk.

Define the security scope and valuable assets

Begin with the complete product ecosystem rather than the physical device alone. Include applications, cloud services, service tools, manufacturing systems, update infrastructure, external interfaces, third-party platforms and the people who administer or use them.

Document intended users, use environments, network assumptions, physical access, expected lifetime, support model and reasonably foreseeable misuse. MTL-102 — Intended Purpose, Users and Use Environments provides the wider product context for these assumptions.

Translate product needs into security objectives

Not every objective has equal importance for every asset. Availability may dominate for a time-critical alarm; integrity may dominate for a dose command; confidentiality may dominate for identifiable health data. Prioritisation should reflect the medical purpose and credible consequences.

Use threat modelling to challenge the design

Threat modelling identifies how an attacker, malicious insider or compromised dependency could affect assets through the product’s attack surfaces. It should be performed early enough to shape architecture and repeated when the product, environment or threat knowledge changes.

A useful threat model explains what the team learned and how the design changed. A diagram and a list of generic threats without decisions, requirements and evidence provide little protection.

Connect security risk and safety risk without merging them

Security risk considers threats, vulnerabilities, exploitability and consequences. Safety risk considers hazards, sequences of events, hazardous situations and harm. A security event may create or defeat a safety-related condition, so the two analyses need explicit information exchange.

MTL-105 — Medical-device Risk Management explains the device safety-risk process, while MTL-302 — ISO 14971 Risk Management provides the standards perspective. Do not force cybersecurity likelihood directly into a safety probability scale: attacker behaviour and vulnerability knowledge change in ways that random failure estimates do not.

Turn security decisions into verifiable requirements

Security controls become effective only when they are allocated, specified, implemented and verified. Requirements should state the required behaviour, conditions, interfaces, failure response and acceptance intent.

• Derive requirements from assets, threats, risk decisions, intended environments and regulatory obligations.
• Specify identities, roles, privileges, session behaviour and service-access restrictions.
• Define cryptographic purpose, key ownership, certificate handling and failure behaviour—not merely “use encryption”.
• Cover secure startup, software integrity, configuration protection and anti-rollback expectations.
• Define logging, monitoring, time, storage, export and privacy constraints.
• Specify secure update, recovery, compatibility and end-of-support behaviour.
• Trace every control to design outputs, verification, residual risk and user information.

MTL-103 — User Needs and Design Inputs explains the characteristics of clear, measurable inputs. Security requirements should be managed within the same controlled design system as other product requirements.

Design for defence in depth and safe degradation

Defence in depth uses independent or complementary controls so that one failure does not expose the complete product. The architecture should minimise attack surface, privilege and unnecessary connectivity while preserving essential clinical behaviour.

Controls must be evaluated in clinical context. A security mechanism that blocks an authorised emergency action, hides a critical display or makes recovery impractical may introduce unacceptable safety risk.

Build a coherent set of security capabilities

The required capabilities depend on the product and threat model, but connected devices commonly need controls across several domains.

• Authentication and identity management for users, devices and services.
• Authorisation, least privilege and separation of administrative functions.
• Cryptographic protection for stored and transmitted data, with controlled key management.
• Secure boot, code signing, integrity checking and protection against unauthorised software.
• Input validation, secure communications, rate limiting and resistance to malformed data.
• Security logging, time integrity, event export and privacy-aware monitoring.
• Backup, recovery, resilience and continued safe operation during loss of connectivity.
• Secure installation, configuration, updates, rollback and restoration.
• Physical protection for debug, service and manufacturing interfaces.
• Clear security information for deployers, operators, service personnel and users.

Use secure implementation practices

Secure design can be undermined by implementation defects, unsafe defaults or uncontrolled build dependencies. Secure development practices should be integrated with the software lifecycle described in MTL-107 — Software Lifecycle.

• Apply language-specific secure coding rules and defensive programming.
• Review security-critical code, trust-boundary handling and cryptographic use.
• Use static analysis, dependency analysis and secret scanning with controlled disposition of findings.
• Protect source, build, signing and deployment environments from unauthorised change.
• Remove test credentials, debug capability and development services from production configurations.
• Keep credentials and cryptographic material out of source code and shared build artefacts.
• Record justified deviations and unresolved weaknesses as controlled product information.

Layer security verification

No single method demonstrates cybersecurity. Evidence should combine requirements-based verification with testing that challenges assumptions, interfaces and attack paths.

Penetration testing should have a defined scope, representative configuration, suitable competence and controlled treatment of findings. It complements rather than replaces architecture review, requirements verification and component analysis. MTL-106 — Verification and Validation explains how to structure credible evidence and configuration control.

Know the software supply chain

A software bill of materials records the commercial, open-source and off-the-shelf components contained in the product. It supports vulnerability monitoring and impact analysis, but an SBOM is an input to a process—not proof that the device is secure.

• Identify components, suppliers, versions, licences, hashes and relationships at useful granularity.
• Include embedded, application, cloud, container and build-time dependencies where relevant.
• Connect components to products, variants, releases and deployed populations.
• Assess known vulnerabilities for reachability, exploitability, controls and clinical consequence.
• Record affected and unaffected conclusions in a controlled vulnerability status, such as VEX.
• Monitor supplier notices, public vulnerability sources and end-of-support dates.
• Define alternatives for components that cannot be patched or supported for the device lifetime.

Supplier agreements should address vulnerability notification, evidence, update availability, support periods and incident cooperation. The manufacturer retains responsibility for the security of the delivered device and related systems.

Release a hardened and supportable product

The release decision should confirm that the security architecture, controls and evidence apply to the exact delivered configuration. Known vulnerabilities and test findings need documented assessment, not quiet acceptance.

Secure-by-default configuration reduces dependence on every customer making expert choices. Where the operating environment must provide controls, those assumptions should be specific, justified, verified where possible and communicated clearly.

Monitor vulnerabilities and field signals

Post-market cybersecurity needs a defined product-security response capability. The organisation should be able to receive reports, identify affected products, assess exploitability and possible harm, make timely decisions and communicate with appropriate parties.

• Monitor vulnerability databases, supplier notices, threat intelligence and product telemetry where lawful and appropriate.
• Operate a clear vulnerability-disclosure channel and coordinated disclosure process.
• Triage findings consistently and preserve technical and risk evidence.
• Determine affected components, versions, configurations, customers and markets.
• Assess active exploitation, compensating controls, safety impact and urgency.
• Escalate reportability, field-action and customer-communication decisions.
• Track remediation, deployment, effectiveness and lessons learned.

CVSS can help describe technical severity, but it does not determine medical-device risk on its own. Clinical context, exposure, exploit conditions, affected function, existing controls and the consequences of remediation all matter.

Plan secure updates before they are needed

Update capability is a product requirement. A secure update mechanism needs authenticity, integrity, compatibility, reliable installation, failure recovery and an operating model that can reach the supported device population.

An emergency process may shorten normal timelines, but it should not remove configuration control, risk assessment, essential verification or accountable approval.

Prepare to respond and recover

A cybersecurity incident may require simultaneous technical containment, safety assessment, customer support, regulatory evaluation, forensic preservation and public communication. These responsibilities should be practised before a real event.

• Define product-security incident roles, decision authority and contact routes.
• Protect patient safety while containing compromise and preserving essential services.
• Retain logs and evidence suitable for investigation without creating unnecessary privacy exposure.
• Coordinate product, IT, clinical, quality, regulatory, legal, communications and supplier teams.
• Prepare customer mitigations, recovery instructions, patches and field actions.
• Assess reporting obligations and coordinate with relevant authorities and security organisations.
• Review the response and feed lessons into design, risk, monitoring and support processes.

Manage end of support transparently

Security support cannot be assumed to continue indefinitely. Define the expected support period, component dependencies and customer transition strategy during product planning—not when a platform is already obsolete.

Before ending support, assess the installed base, clinical dependence, remaining vulnerabilities, data handling, replacement options and regulatory obligations. Communicate dates and consequences early. Where devices remain in service, provide proportionate compensating controls, migration guidance and a defensible residual-risk decision.

Retirement should also address credential revocation, keys, cloud services, retained data, update infrastructure, returned devices and secure disposal.

Worked example: a connected injection system

A connected injection system includes embedded device software, a patient application, a clinician portal, cloud services and a manufacturer update service. Its assets include dose commands, injection records, patient identity, device configuration, firmware, credentials and signing keys.

If the mobile application is unavailable, the injector’s safe local behaviour remains defined. This is defence in depth: loss or compromise of a connected service should not automatically remove essential product safety.

Common failure patterns

Practical cybersecurity checklist

• Product-security accountability and lifecycle resources are defined.
• The complete device ecosystem, assets, interfaces and trust boundaries are documented.
• Threat modelling is current and connected to requirements and design decisions.
• Security risk and safety risk exchange relevant information without being collapsed into one method.
• Security requirements are specific, allocated, traceable and verifiable.
• Architecture minimises attack surface and uses defence in depth.
• Secure coding, build, signing and configuration practices are controlled.
• Verification combines review, analysis, functional, robustness and penetration testing.
• The SBOM supports product- and version-specific vulnerability analysis.
• Secure configuration and environmental assumptions are communicated to users.
• Vulnerability disclosure, monitoring, triage and escalation processes are operational.
• Update and recovery mechanisms are secure, reliable and testable.
• Incident-response roles and customer communications are prepared.
• Support periods, obsolescence and retirement are planned and transparent.