Medical Device Cybersecurity

1. Introduction

Medical Device Cybersecurity is the discipline of designing, building, deploying and maintaining networked and software-enabled medical devices so that they preserve safety, effectiveness and data protection across their entire life cycle. Unlike general enterprise IT security, medical device security must reconcile clinical safety (a device must not harm a patient), regulatory compliance (a device must clear market authorisation) and operational resilience (a device must keep working in a hospital that cannot be patched on demand). This guide provides an auditor-grade, implementer-ready deep-dive spanning the two dominant regulatory and standards pillars: the U.S. Food and Drug Administration (FDA) premarket and postmarket cybersecurity expectations, and the IEC 81001-5-1 / IEC/TR 60601-4-5 / AAMI TIR57 / UL 2900-2-1 standards ecosystem, all anchored to a Total Product Life Cycle (TPLC) and Secure Product Development Framework (SPDF) philosophy.

The scope covers Software as a Medical Device (SaMD), Software in a Medical Device (SiMD), connected diagnostic and therapeutic devices, implantables, wearables, hospital gateways and the supporting infrastructure. The guide is written for two audiences at once: the assessor/auditor who must gather objective evidence and render a finding, and the manufacturer/product team who must engineer, document and sustain the controls that produce that evidence.

A defining characteristic of this domain is asymmetry of tempo. Enterprise IT patches on a weekly or monthly cadence; a medical device may be validated for a specific software configuration, deployed for ten to fifteen years, and legally frozen against unvalidated change. This means that security must be engineered in at design time, because the opportunity to retrofit is severely constrained once a device reaches the bedside. It also means that manufacturers and healthcare delivery organisations must share responsibility explicitly: the manufacturer builds intrinsic controls and a safe update path, while the hospital provides compensating network controls, monitoring and physical protection. The documentation that records this shared-responsibility boundary — often expressed through the MDS2 disclosure and the security use instructions — is itself a first-class audit artefact. Assessors who ignore it will misattribute residual risk and reach an unsound conclusion.

The reader should treat this guide as a lattice rather than a linear checklist. Section 4 defines the domains; Section 5 enumerates every control group with a verify/evidence pairing; Sections 6 through 12 wrap those controls in scoping, implementation phasing, maturity grading, audit method, evidence collection, role assignment and measurement. The concluding sections give a readiness checklist, catalogue the failure modes we most frequently observe in the field, and map the scheme to adjacent frameworks so that an organisation already certified to ISO/IEC 27001 or conformant to IEC 62443 can reuse evidence rather than duplicate effort.

2. What is Medical Device Security

Medical Device Security is the application of cybersecurity engineering and governance to devices whose intended use is diagnosis, cure, mitigation, treatment or prevention of disease. It differs materially from IT and OT security because the primary asset under protection is the patient and the clinical outcome, not merely data confidentiality. A ransomware event on a patient-monitoring gateway is a patient-safety event, not only a data-availability event; a firmware flaw in an insulin pump is a potential loss of life. Consequently the field fuses three engineering disciplines: safety risk management (ISO 14971), software life-cycle management (IEC 62304) and security risk management (IEC 81001-5-1 / AAMI TIR57).

The regulatory centre of gravity in the United States is Section 524B of the Federal Food, Drug, and Cosmetic Act (added by the Consolidated Appropriations Act, 2023), which makes cybersecurity a mandatory condition of premarket submission for 'cyber devices'. FDA operationalises this through its premarket cybersecurity guidance (final September 2023), which requires a Secure Product Development Framework, a Software Bill of Materials (SBOM), threat modelling, security architecture views and a plan to monitor, identify and address postmarket vulnerabilities. The international standards centre of gravity is IEC 81001-5-1 (health software and health IT systems safety, effectiveness and security — security activities in the product life cycle), harmonised in the EU under the Medical Device Regulation (MDR 2017/745) and the NIS2 / Radio Equipment Directive (RED) cybersecurity essential requirements.

It is worth naming the specific engineering constructs the scheme expects, because vague conformity claims fail review. The FDA package expects an explicit threat model methodology (STRIDE or attack-tree based), four named architecture views (global system, multi-patient harm, updateability/patchability, and security use case), a machine-readable SBOM in SPDX or CycloneDX format carrying the CISA minimum elements, and a postmarket plan whose remediation clock starts when an uncontrolled risk is identified. IEC 81001-5-1 in turn defines a set of security-activity processes — planning, requirements, design, implementation, verification, release, and problem resolution — that mirror IEC 62304 but add security-specific expectations. Where independent testing or certification is pursued, schemes such as UL 2900-2-1 define structured penetration and known-vulnerability testing, IEC 62443-4-1 (via the ISASecure programme) defines a graded secure-development-lifecycle assurance, and Common Criteria defines Evaluation Assurance Levels (EAL 1 to EAL 7). Cryptographic modules are frequently validated to FIPS 140-3, which itself defines four security levels of increasing physical and logical protection. Assessors should always establish which of these named levels and constructs a manufacturer is claiming, because the level is what makes a claim testable.

3. Who Must Comply

Obligations attach to any organisation that manufactures, integrates, distributes, or operates connected or software-enabled medical devices. The concept of a 'cyber device' under Section 524B is broad: any device that (a) includes software validated, installed, or authorised by the sponsor, (b) has the ability to connect to the internet, and (c) contains technological characteristics that could be vulnerable to cybersecurity threats.

• US: FDA premarket review under 524B applies to 510(k), De Novo, PMA, PDP, HDE and BLA submissions containing device software.
• EU: MDR/IVDR Annex I General Safety and Performance Requirements (GSPR) 17.2 and 17.4 mandate security for programmable devices; MDCG 2019-16 provides guidance.
• UK: MHRA guidance on medical device cybersecurity aligns to the same TPLC principles post-Brexit.
• Global: IMDRF 'Principles and Practices for Medical Device Cybersecurity' provides an internationally harmonised baseline.

4. Structure of Medical Device Security

Medical Device Security is not a single monolithic control set; it is a lattice of overlapping frameworks that together define premarket engineering expectations, testing/certification schemes and postmarket operations. The table below maps the principal domains, the standard or scheme that owns each, and the representative control families within it. These domains form the backbone of the master assessment checklist in Section 5.

5. Master Assessment Checklist

This is the operational heart of the guide. Every control group below is expressed as an h3 with a table whose columns are 'What to verify' (the assessor's test) and 'Typical evidence' (the objective artefact that satisfies it). No domain from Section 4 is omitted. Assessors should sample across the TPLC — do not accept a design document without evidence that its controls were verified in the built device and are sustained in the field.

5.1 Security Risk Management (IEC 81001-5-1 / AAMI TIR57 / ISO 14971)

5.2 Secure Product Development Framework (SPDF) / NIST SSDF SP 800-218

5.3 Software Life-Cycle Processes (IEC 62304)

5.4 Security Architecture and Design Views (FDA premarket guidance)

5.5 SBOM and Software Transparency (FDA 524B / CISA SBOM minimum elements)

5.6 Design Security Capabilities — Authentication and Authorisation (IEC/TR 60601-4-5 / IEC 62443-4-2)

5.7 Design Security Capabilities — Cryptography, Integrity and Confidentiality

5.8 Design Security Capabilities — Audit, Logging and Detection

5.9 Design Security Capabilities — Resiliency, Recovery and Updateability

5.10 Security Verification and Testing (UL 2900-2-1 / AAMI TIR97 / FDA)

5.11 Labelling, Transparency and Security Documentation

5.12 Postmarket Vulnerability and Incident Management (FDA 2016 / ISO/IEC 30111 / 29147)

5.13 Supply Chain and Third-Party / SOUP Security

5.14 Certification and Conformity Assessment (UL 2900-2-1 / ISASecure / Common Criteria)

5.15 Certification and Testing Levels — Named Assurance Scales

Where a manufacturer claims a graded assurance level, the assessor must verify the claim against the scheme's defined scale. The table below consolidates the principal named levels an auditor encounters in medical device security so that the claimed level, the awarding scheme, and its meaning are unambiguous.

5.16 Certification and Testing Lifecycle

Certification and independent testing follow a defined lifecycle that runs in parallel with, and feeds, the regulatory submission. Auditors should confirm each stage produced its expected artefact and that the certificate remains valid and in scope.

6. Scoping

Scoping determines what is assessed and to what depth. For medical device security the boundary is the 'device system' as intended and labelled — including firmware, embedded OS, application software, companion mobile apps, cloud back-ends, gateways, accessories and the interfaces between them. Scoping must be driven by intended use and by where cybersecurity failures could translate into patient harm.

A disciplined scoping exercise begins from the intended use statement and the essential performance defined for the device, then works outward along every path by which data or control can enter or leave the system. Each such path is an entry point and therefore part of the attack surface. The scope boundary should be drawn to include everything the manufacturer controls or can influence, and to explicitly exclude — with written rationale — anything transferred to the operating environment. A common scoping error is to evaluate the physical device while excluding its cloud analytics back-end; because a compromise of a shared back-end can affect every deployed unit simultaneously, that back-end almost always belongs inside the multi-patient harm view and therefore inside scope. Equally, wireless interfaces are frequently under-scoped: Bluetooth Low Energy pairing, Wi-Fi association and cellular management channels each carry their own threat surface and each must be enumerated.

• Include: all software (including SOUP/OTS), all network and physical interfaces, wireless (Bluetooth, Wi-Fi, cellular, NFC), maintenance/service ports, cloud and companion apps, and the update pathway.
• Include the multi-patient / scaled-harm perspective: servers, PACS, gateways and fleets where one compromise scales across many patients.
• Classify by IEC 62304 software safety class (A/B/C) and by security risk to prioritise rigour.
• Exclude, with justification, purely mechanical components and non-connected legacy items — but document the rationale and any data-transfer paths.
• Define the device configuration under evaluation precisely (versions, options, network posture) so that certification scope is unambiguous.
• Distinguish manufacturer-controlled controls from HDO-controlled compensating controls; document the transfer of residual risk to the operator.

7. Implementation Approach

Implementation follows a phased Secure Product Development Framework mapped to the Total Product Life Cycle. Each phase below lists key activities and the deliverables an auditor should expect.

Phase 1 — Governance and Preparation

• Activities: establish a Product Security Incident Response Team (PSIRT), define secure development policy, assign security roles, provision tooling (SAST/SCA/DAST/fuzzing), train engineers, and adopt IEC 81001-5-1 / SSDF as the framework.
• Deliverables: security governance charter, secure development policy, role matrix, training records, tool inventory.

Phase 2 — Security Risk Analysis and Threat Modelling

• Activities: characterise assets and data flows, perform threat modelling (STRIDE/attack trees), enumerate vulnerabilities, and evaluate risks against acceptability criteria linked to patient harm.
• Deliverables: threat model, security risk analysis, data flow and trust boundary diagrams, initial risk register.

Phase 3 — Secure Architecture and Design

• Activities: define security requirements and controls, produce the four FDA architecture views, select cryptographic and authentication mechanisms, design update and recovery paths, and establish SOUP segregation.
• Deliverables: security requirements specification, security architecture views, design specifications, SBOM baseline.

Phase 4 — Secure Implementation and Verification

• Activities: apply secure coding standards, run SAST/SCA on every build, implement controls, and perform integration and system security testing.
• Deliverables: code review records, SAST/SCA reports, control implementation evidence, security test results, traceability matrix.

Phase 5 — Security Validation and Independent Testing

• Activities: fuzz testing, independent penetration testing, vulnerability scanning, and (where pursued) scheme certification testing (UL 2900-2-1 / Common Criteria).
• Deliverables: penetration test report, fuzz/robustness report, residual-risk assessment, certification test report and certificate.

Phase 6 — Regulatory Submission and Labelling

• Activities: assemble the premarket cybersecurity documentation package (524B/MDR), finalise SBOM disclosure, complete MDS2, and produce customer security documentation.
• Deliverables: premarket cybersecurity submission, MDS2, security hardening guide, published CVD policy.

Phase 7 — Postmarket Management and Maintenance

• Activities: operate vulnerability intake and triage, monitor threat intelligence and ISAOs, deploy patches, publish advisories, and feed lessons back into the SPDF.
• Deliverables: postmarket surveillance plan, advisories, patch/deployment records, updated threat models and SBOMs.

8. Maturity / Capability Model

A maturity model helps both manufacturers and auditors calibrate where a product security programme sits and what 'good' looks like. The five-level model below is adapted from common capability-maturity constructs and aligned to IEC 81001-5-1 and SPDF expectations. Regulatory conformity is achievable at Level 3, where the SPDF is defined and consistently applied across the Total Product Life Cycle; Levels 4 and 5 add the quantitative management and continuous-improvement characteristics that distinguish a resilient, defensible programme from a merely compliant one. Auditors should score each control group in Section 5 independently, because a programme is often mature in design but immature in postmarket operation, or vice versa; the overall rating is only as strong as its weakest safety-relevant domain.

9. Assessment and Audit Approach

1. Define scope and objectives: identify the device system, configuration under review, applicable regulations (524B/MDR) and certification schemes.
2. Collect documentation: request the SPDF plan, threat model, security risk analysis, architecture views, SBOM, test reports and postmarket procedures.
3. Assess design adequacy: evaluate whether controls in the architecture views mitigate the modelled threats to acceptable residual risk.
4. Verify implementation: sample evidence that designed controls exist in the built device (configuration review, test result inspection, live demonstration).
5. Conduct or review independent testing: examine penetration test, fuzzing, SAST/SCA and scan results; validate exploitability of open findings.
6. Evaluate postmarket capability: confirm PSIRT operation, CVD policy, patch deployment tracking and regulatory reporting readiness.
7. Assess supply chain: review SBOM currency, SOUP vulnerability handling and supplier security obligations.
8. Rate findings: score each control area against the maturity model and acceptability criteria, linking security gaps to patient-safety risk.
9. Report: document findings, evidence gaps, non-conformities and prioritised remediation with a re-assessment plan.
10. Follow up: verify corrective actions and update the risk register and certification status.

10. Evidence Request List

The following artefacts, grouped by category, constitute a typical evidence pack for a medical device security assessment.

• Governance: secure development policy, PSIRT charter, role matrix, training records, tool inventory.
• Risk: security risk management plan, threat model, security risk analysis, risk register, residual-risk report and sign-off.
• Design: security requirements specification, four FDA architecture views, cryptography and key management design, update/recovery design.
• Software life cycle: IEC 62304 software development plan, safety classification, SOUP list, detailed design.
• SBOM and supply chain: machine-readable SBOM, EOL/EOS matrix, VEX statements, supplier security agreements.
• Testing: SAST, SCA, DAST/fuzz, penetration test and vulnerability scan reports plus triage/traceability.
• Certification: certification plan, accredited lab report, issued certificate, surveillance records.
• Labelling: MDS2, security hardening guide, customer SBOM disclosure, decommissioning/sanitisation instructions.
• Postmarket: CVD policy, vulnerability intake and triage records, advisories, patch deployment tracking, regulatory reporting records.

11. Roles and Responsibilities

12. KPIs to Track

• Percentage of products with a current, complete and machine-readable SBOM.
• Mean time to triage (MTTT) and mean time to remediate (MTTR) reported vulnerabilities.
• Percentage of critical/exploitable vulnerabilities remediated within SLA.
• Threat model coverage: proportion of releases with an updated threat model.
• Security test coverage traced to security requirements and modelled threats.
• Number of SOUP/third-party components past end-of-support in shipping products.
• Patch deployment rate across the deployed fleet (field closure rate).
• Number of published security advisories and coordinated disclosures per period.
• Percentage of products meeting the target maturity level (Level 3+).
• Recurrence rate of previously-remediated vulnerability classes.

13. Readiness Checklist

• Secure development policy and PSIRT are established and staffed.
• Threat model and security risk analysis exist and are integrated with ISO 14971.
• All four FDA security architecture views are complete and current.
• A machine-readable SBOM with minimum elements and EOL data is maintained.
• Authentication, cryptography, integrity, logging and update controls are implemented and tested.
• SAST, SCA, fuzz and independent penetration testing are complete with findings triaged.
• Residual security risk is documented and formally accepted.
• MDS2, hardening guide and customer SBOM disclosure are prepared.
• A published coordinated vulnerability disclosure policy is live.
• Postmarket vulnerability intake, patch deployment and regulatory reporting are operational.
• Premarket cybersecurity documentation package is assembled per 524B / MDR.
• Certification scope (if pursued) matches the marketed configuration.

14. Common Gaps

• Security risk analysis treated separately from ISO 14971 safety risk, so security-derived patient harm is missed.
• SBOM produced once for submission then left stale, with no VEX and no EOL tracking.
• Threat model that stops at the device and ignores the multi-patient / cloud back-end scaled-harm view.
• Hard-coded or default credentials and unauthenticated maintenance/service interfaces.
• Firmware updates that are unsigned or lack anti-rollback protection.
• No coordinated vulnerability disclosure policy or PSIRT contact, so researchers cannot report safely.
• Postmarket process that cannot distinguish routine updates from uncontrolled-risk remediation timelines.
• Testing limited to a vulnerability scan, with no fuzzing or independent penetration testing.
• SOUP components shipped past end-of-support with unpatched known CVEs.
• Residual risk not formally accepted by an authorised role, or acceptance undocumented.
• Logs that cannot be exported to the HDO SIEM, blinding hospital detection.
• Certification certificate scope that does not match the shipping device configuration.

15. Medical Device Security Mapped to Other Frameworks

16. How CyberSigma Helps

Frequently asked questions

Need help with Medical Device Security?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.