Medical Device Cybersecurity: Standards, Requirements and Security-by-Design in Practice

In a 2022 study by Cynerio and the Ponemon Institute, 53% of connected medical devices in hospitals had at least one known critical vulnerability. For manufacturers, that figure now carries regulatory weight. Under EU MDR and the FDA's 2023 cybersecurity final guidance, medical device cybersecurity is a mandatory element.

Moreover, it applies to both pre-market submissions and ongoing post-market surveillance. So the question teams face is how to build it into a regulatory programme that is already full.

This raises a practical question:
How do you build cybersecurity into a medical device development programme in a way that satisfies both EU and US regulatory requirements without treating it as a separate workstream that doubles the team's effort?

This article covers the medical device cybersecurity standards map. It then walks through how EU MDR and FDA requirements map to specific development activities. Next, it explains what a Software Bill of Materials requires in practice. Finally, it covers the post-market obligations that teams most often underestimate.

In practice, medical device cybersecurity runs as a set of activities from architecture through to end of life, rather than a checklist at the end of development.

Table of Content

The Regulatory Requirement for Medical Device Cybersecurity

What MDR Annex I Requires

Medical device cybersecurity has moved from guidance to legal obligation on both sides of the Atlantic. Indeed, the shift happened within the last three years. Under EU MDR Annex I General Safety and Performance Requirements 17.2–17.4, manufacturers must protect connected devices against unauthorised access.

They must also identify all known software in the device. Furthermore, their products must receive security updates throughout the intended lifetime. These are conformity requirements, therefore they must be documented in the technical file.

What the FDA 2023 Guidance Adds

In the US, the FDA's September 2023 final guidance made premarket submission requirements explicit for the first time. New submissions must include four artefacts:

a cybersecurity management plan
a Software Bill of Materials
a threat modelling documentation
a pen testing evidence

Meanwhile, products cleared before October 2023 are subject to post-market obligations under section 524B of the FD&C Act. As a result, both frameworks are now live and enforced.

Why This Hits Embedded Teams

The shift matters most for embedded software and firmware teams building connected devices. Think infusion pumps, monitoring equipment, implantables with wireless components and anything on a hospital network. Historically, these teams treated security as an infrastructure concern managed by hospital IT.

However, under current regulations, security responsibility starts with the device manufacturer. It continues for the full product lifetime.

-> In short: Medical device cybersecurity is now a mandatory conformity requirement under EU MDR and a premarket submission requirement under FDA. Addressing it post-development is too late to avoid rework.

What To Do:

Identify every network interface, communication protocol and data store in your device and record them as part of the security architecture description, this is the foundation for every other cybersecurity activity.
Confirm which regulatory frameworks apply to your target markets (EU MDR, FDA, or both) before selecting standards, the documentation requirements differ and some overlap, which allows shared artefacts.
Add a cybersecurity section to your design input specification at the start of the project, not as a review task near the end of verification.

The Medical Device Cybersecurity Standards Map

Four documents define the practical standards map for medical device cybersecurity teams. Understanding how they relate to each other is more useful than treating them as a list of options.

IEC 81001-5-1: The Primary Standard

IEC 81001-5-1:2021 is the dedicated standard for medical device software and health IT network security. It covers safety, effectiveness and security. The standard defines security activities across the full product lifecycle.

That spans requirements through design, implementation, test and post-market. Both MDCG 2019-16 and FDA's 2023 guidance reference it.

As a result, it applies to the widest range of teams regardless of target market. Start here.

MDCG 2019-16: The EU Guidance

MDCG 2019-16 is the Medical Device Coordination Group's guidance document. It translates MDR Annex I cybersecurity requirements into a practical security lifecycle framework. Mostly, it is a guidance document rather than a standard.

Still, it defines what regulators and Notified Bodies expect to see in a technical file. Teams targeting the EU should read MDCG 2019-16 alongside IEC 81001-5-1. Verify your security programme covers all the activities the guidance describes.

FDA 2023 Guidance and IEC 62443

The FDA's 2023 final guidance applies to US premarket submissions. It sets explicit requirements for SBOM, threat modelling and pen testing documentation. IEC 62443 is the broader industrial automation security standard.

In fact, IEC 81001-5-1 draws its lifecycle framework from it. For manufacturers of complex connected or OT-adjacent devices, IEC 62443 is relevant. Still, it does not replace the dedicated health software standard.

-> In short: IEC 81001-5-1 is the right starting standard for most teams. MDCG 2019-16 and FDA 2023 guidance then define what the certification reviewer expects to see in your documentation.

What To Do:

Build your security programme around IEC 81001-5-1 as the primary standard, then map it against MDCG 2019-16 for EU documentation and FDA 2023 guidance for US submissions.
Create a standards-mapping document that records which IEC 81001-5-1 clause is addressed by which work product in your technical file, Notified Bodies and FDA reviewers find this helpful and it reduces Q&A time.
If you are targeting both EU and US markets, build shared artefacts where possible: the SBOM, threat model and pen test report satisfy both frameworks and do not need to be produced twice.

Security-by-Design in the Medical Device SDLC

Security-by-design means cybersecurity activities are planned and executed at each phase, instead of being reviewed as a block at the end. IEC 81001-5-1 clauses 5–9 define what those activities are phase by phase.

The practical question is how they slot into an existing development process. That process is already running risk management, design controls and V&V in parallel.

Design Phase: Threat Modelling

Threat modelling happens at architecture, before implementation begins. The goal is to enumerate the attack surfaces and identify the threats for each. Surfaces include network interfaces, data stores, external APIs and physical ports.

STRIDE is the most widely used framework for medical devices. The acronym stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege. For example, STRIDE maps well to both ISO 14971 risk categories and FDA documentation.

The output is a threat model and an initial risk register. Both feed directly into the ISO 14971 risk management process.

Development Phase: Secure Coding and SBOM

During development, the focus is on two parallel activities. First, secure coding practices include static analysis (SAST), dependency scanning and linting rules. These catch common vulnerability classes before code is reviewed.

They can be integrated into CI/CD pipelines at low overhead. Alongside this, the Software Bill of Materials is generated as a build artefact. It is a structured record of every component, library, version and licence in the product.

The SBOM is a living document. It must be updated with every release.

Verification and Release: Pen Testing and CVD

Pen testing and dynamic analysis (DAST/fuzzing) happen during verification. The product must be in a representative test environment. For medical devices, pen testing must cover the same attack surfaces identified in the threat model.

The test report is a technical file deliverable. Then, before release, a Coordinated Vulnerability Disclosure (CVD) policy must be published.

It defines a channel for researchers to report vulnerabilities. It also defines a timeline for the manufacturer to acknowledge and respond.

-> In short: Threat modelling at design, SBOM and SAST during build, pen test during verification, CVD policy before launch. Each phase produces a document that lands in the technical file.

What To Do:

Schedule threat modelling as a design review gate, it should happen at the same session where the system architecture is baselined, not after it is frozen.
Automate SBOM generation as part of the build pipeline using CycloneDX or SPDX format, both are accepted by FDA and are the formats expected in the NVD/CISA vulnerability tracking tools your post-market process will need to use.
Engage an independent pen testing firm for the verification stage rather than relying on internal testing, regulators and Notified Bodies treat third-party pen test reports as significantly more credible than self-assessments.

The Software Bill of Materials Requirement

An SBOM is a structured, machine-readable inventory of every software component in a medical device. That covers open-source libraries, third-party SDKs, OS packages and firmware dependencies. The FDA's 2023 guidance requires one for all new submissions.

EU MDR does not use the term SBOM. Still, the technical file requirement to document all safety-relevant software components mandates equivalent traceability. That obligation sits under IEC 62304 and IEC 81001-5-1.

What the SBOM Must Contain

Each SBOM entry records the component name, supplier, version, unique identifier (CPE or PURL) and any known licences. FDA guidance specifies the NTIA minimum elements as the baseline. For medical devices, the SBOM also needs a mapping to the IEC 62304 software of unknown provenance (SOUP) list.

In practice, the two documents cover overlapping ground. Therefore, maintain them in alignment to avoid inconsistencies in the technical file.

How the SBOM Connects to Post-Market Surveillance

The real value of an SBOM is in post-market monitoring. Once a new CVE is published against a listed component version, you have a direct line to assess impact. The check moves from the public vulnerability database straight to your fielded device.

However, without a maintained SBOM, that monitoring is manual, slow and frequently incomplete. Tools like Dependency Track or Grype ingest an SBOM in CycloneDX format.

And they flag new vulnerabilities automatically. That is how a post-market security process scales beyond what a small team can do manually.

-> In short: The SBOM is the linchpin between pre-market development documentation and post-market vulnerability monitoring. Generate it at build time and maintain it with every release.

What To Do:

Generate the SBOM as a build artefact using a tool such as Syft, CycloneDX Maven Plugin or equivalent, do not create it manually, as manual SBOMs go stale within weeks of the first dependency update.
Align the SBOM component list with the IEC 62304 SOUP list in your software development file, they should reference the same components and version numbers, with any discrepancies documented as a risk management finding.
Connect your SBOM to a CVE feed at launch using a dependency tracking tool so the first new vulnerability against one of your components triggers an automatic alert to your post-market surveillance team rather than arriving via a field report.

Post-Market Medical Device Cybersecurity Obligations

Post-market cybersecurity is where many medical device teams have the largest gap. Security continues past CE mark or FDA clearance. In fact, it becomes a continuing obligation that forms part of the post-market surveillance system required under EU MDR and the FD&C Act.

Vulnerability Monitoring and Patching

When a new vulnerability hits a component your device uses, the response process has defined stages:

First, assess whether the vulnerability affects your specific device configuration.
Second, determine the risk to patients in the context of the device's intended use.
Third, either accept the residual risk with justification or issue a patch.

Furthermore, under EU MDR, serious vulnerabilities with patient safety risks must be reported to the National Competent Authority through the vigilance system. FDA requires reporting under 21 CFR Part 806 for recalls and corrections that include security patches.

Coordinated Vulnerability Disclosure

The CVD policy published before launch is the foundation for post-market security response. It defines how external parties can report potential vulnerabilities. Parties include researchers, health system IT teams and other stakeholders.

Similarly, it defines how the manufacturer will acknowledge, investigate and respond. MDCG 2019-16 recommends following ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling).

For smaller teams, a clearly written policy page on the manufacturer's website is a practical starting point. Pair it with a security email address and a defined SLA for acknowledgement.

-> In short: Post-market medical device cybersecurity means monitoring for new vulnerabilities, patching with documented justification and notifying authorities when patient safety is affected.

What To Do:

Write post-market security obligations into your PMS Plan at the time it is created, define who owns CVE monitoring, how often vulnerability assessments are run and what the escalation path is when a patient-safety risk is identified.
Assign a named owner for the CVD inbox before launch, unmanned disclosure channels lead to delayed response times that regulators and researchers notice and document.
Include a security section in your Periodic Safety Update Report (PSUR) that covers vulnerabilities identified, assessed, patched and any residual risks accepted during the reporting period.

Common Medical Device Security Gaps in Practice

Three patterns account for the majority of medical device cybersecurity gaps identified during regulatory reviews and post-market incidents.

Treating Security as an End-of-Project Activity

The most common gap is sequencing. Security review is scheduled after verification rather than running in parallel. That means the threat model arrives after the architecture is frozen.

Vulnerabilities discovered in pen testing require code changes that trigger V&V re-work. The SBOM is produced manually from a list of dependencies rather than generated automatically by the build system.

All of these are recoverable but still, each one adds weeks to the conformity timeline and increases the cost.

Legacy Components Without Vulnerability Tracking

Many embedded medical devices include open-source components or commercial libraries integrated years ago. These components have not been re-evaluated since. Once the SBOM process surfaces them, teams often discover several carrying known CVEs.

The manufacturer has never assessed those CVEs and under IEC 81001-5-1 and EU MDR, lack of awareness is not a defence.

The manufacturer is responsible for all software components regardless of origin. A first-time SBOM audit frequently reveals three to ten components requiring immediate vulnerability assessment.

No Security Section in the PSUR

The Periodic Safety Update Report is the primary post-market surveillance document reviewed by Notified Bodies under EU MDR. A dedicated security section demonstrates that the medical device security programme is active and governed. The section should cover CVEs assessed, patches issued, residual risks accepted and any CVD submissions received.

Teams that omit the security section see it raised as a finding on the next audit. So do teams that include only a single line stating "no security incidents".

-> In short: Most medical device security gaps are process gaps rather than technical ones. The three biggest are late sequencing, undocumented legacy components and absent post-market security reporting.

What To Do:

Run a legacy component audit before starting any MDR conformity work, generate an SBOM for your current product, check each component against NVD and document your risk assessment for any findings before the Notified Body asks for it.
Add a security section template to your PSUR document structure now, even if the content is currently "no new vulnerabilities identified", having the section present and completed signals an active programme.
If your product is under MDD and moving to MDR, treat the MDR transition as the trigger for a full security programme review, requirements have changed substantially and a compliance gap assessment is faster than discovering gaps at technical file review.

Building Your Medical Device Security Programme

For a small team building a connected medical device for the first time, standing up a full IEC 81001-5-1-aligned security programme from scratch looks daunting. In practice, the programme can be built incrementally and most of the work integrates with activities already in the project plan.

The Three Starting Artefacts

Start with the three artefacts every regulatory reviewer will look for first. These are the threat model, the SBOM and the CVD policy. If well produced, they demonstrate a credible security posture.

That holds even before the pen test report or the PSUR security section are complete.

A threat model takes a half-day workshop for a single-product device

An SBOM is a build pipeline configuration.
A CVD policy is a one-page document with a dedicated security email address.

None of these require specialist security headcount if the development team understands the underlying concepts.

When to Outsource and When to Keep Internal

For embedded software and firmware teams where security expertise is thin, a split model works well. Outsource the threat modelling workshop and the pen test to specialists. Keep day-to-day security practices internal.

That includes SAST, SBOM maintenance and CVE monitoring. In practice, the split works well for devices targeting CE mark at Class IIa.

Specialist outputs go into the technical file. The internal team owns the ongoing programme.

The SaMD Case

The same applies for SaMD products. Software-only products classified under Rule 11 carry the same cybersecurity obligations as hardware devices. The lack of a physical interface does not reduce the attack surface.

Indeed, networked clinical software connects to EHR systems, cloud APIs and mobile clients. That often gives a larger security footprint than a standalone embedded device.

-> In short: Threat model, SBOM and CVD policy are the three artefacts to build first. Everything else follows from them.

What To Do:

Budget for a threat modelling workshop and an independent pen test in your project plan from the start, these are not optional extras and last-minute sourcing is both slower and more expensive.
Use your IEC 62304 SOUP list as the starting point for your SBOM if you already have one, add the CPE/PURL identifiers and licence information to convert the SOUP list into a regulatory-grade SBOM.
Review your software development process against IEC 81001-5-1 clause 5 before your next architecture review and identify which activities are missing or undocumented.

Closing Thoughts

Medical device cybersecurity is no longer a parallel track. Instead, it is part of the main regulatory programme. The activities in IEC 81001-5-1, MDCG 2019-16 and the FDA's 2023 guidance are conformity requirements.

They land in the technical file alongside risk management, clinical evaluation and software lifecycle documentation. Teams that build them in from architecture onwards find the compliance effort manageable and the documentation flows naturally from the development process.

By contrast, teams that address it at the end find it expensive and slow. If your product is approaching a technical file review, our MDR Assessment identifies security gaps alongside the full regulatory picture. You can then address everything in one focused remediation plan.

FAQs: Medical Device Cybersecurity Questions

Q1: What are the Main Medical Device Cybersecurity Standards?

A1: The primary harmonised standard is IEC 81001-5-1:2021. It covers security activities across the full product lifecycle. That spans design through post-market. For the EU, MDCG 2019-16 is the guidance document. It explains how MDR Annex I cybersecurity requirements apply in practice.

For the US, the FDA's September 2023 final guidance sets out the specific documentation requirements for premarket submissions. Those requirements include the SBOM and threat modelling documentation. IEC 62443 is a broader industrial security framework. It provides the parent methodology for IEC 81001-5-1 and is relevant for complex connected device architectures.

Q2: Is Medical Device Cybersecurity Required Under EU MDR?

A2: Yes. EU MDR Annex I General Safety and Performance Requirements 17.2–17.4 set explicit obligations. Manufacturers of network-connected devices must protect against unauthorised access. They must identify software used in the device. They must enable security updates throughout the intended lifetime.

These are conformity requirements rather than recommendations. Non-compliance prevents CE marking the same way a gap in risk management or clinical evidence does. Notified Bodies assess cybersecurity as part of the Annex I review for connected devices at Class IIa and above.

Q3: What is an SBOM and Why Do Medical Devices Need One?

A3: A Software Bill of Materials is a structured, machine-readable inventory of all software components in a device. That covers open-source libraries, third-party SDKs, OS packages and firmware dependencies. FDA's 2023 guidance requires one for all new submissions.

Under EU MDR, the software lifecycle documentation requirements in IEC 62304 and IEC 81001-5-1 require equivalent component traceability. The SBOM's primary post-market value is in automated vulnerability monitoring. When a new CVE is published, the SBOM identifies whether any of your device's components are affected. You skip manually reviewing every dependency.

Q4: What Does Threat Modelling Involve for a Medical Device?

A4: Threat modelling for a medical device has four steps.

First, identify attack surfaces. Those include network interfaces, communication protocols, data stores and physical ports.
Second, enumerate the threats for each surface using a structured framework such as STRIDE.
Third, assess the likelihood and severity of each threat in the context of clinical use.
Fourth, record the mitigations applied.

STRIDE maps well to both ISO 14971 risk categories and FDA documentation expectations. The output is a threat model document and an updated risk register. The register feeds into the ISO 14971 risk management file. For most single-product devices, a half-day workshop with the architecture and security team produces the initial threat model.

Q5: How Does Medical Device Security Apply to Software-Only Products?

A5: Software-only medical devices carry the same cybersecurity obligations as hardware-based devices. That covers apps, clinical decision support tools and diagnostic software. EU MDR Annex I and IEC 81001-5-1 apply to any device qualified as a medical device. Physical components are not a factor.

Software-only products connect to EHR systems, mobile clients and cloud APIs. They often have larger attack surfaces than standalone embedded devices. So they need the same threat modelling, SBOM and post-market security monitoring programme. The Rule 11 classification does not affect which cybersecurity standards apply. It only determines the conformity assessment route.