Medical Device Cybersecurity: EU vs. US Standards

If I had to sum it up in one line: the U.S. is more explicit, and the EU ties cybersecurity more closely to product safety.

If you buy, review, or sell connected medical devices, that difference changes what you need to ask for. In the U.S., FDA rules for cyber devices make items like SBOMs, testing records, and lifecycle details part of the review path. In the EU, the same cybersecurity work sits inside MDR/IVDR safety and risk documentation, with more focus on whether a cyber issue could become a patient safety issue.

Here’s the short version:

• U.S.:
  • FDA Section 524B sets direct cybersecurity submission rules
  • SBOMs are required
  • FDA may ask for VEX
  • Postmarket work includes monitoring new flaws and keeping records current
  • Missing cybersecurity files can block review
• EU:
  • Cybersecurity comes from MDR, IVDR, and MDCG 2019-16 Rev. 1
  • The main test is whether the device meets the state of the art for IT security
  • SBOMs are not named as a hard-format rule, but they often help show software inventory and tracking
  • Postmarket work ties cyber flaws to vigilance and Field Safety Corrective Action (FSCA) when patient safety is at risk
• What this means for you:
  • If you’re an HDO, ask for an SBOM, support dates, update guidance, and the vendor’s vulnerability process
  • If you’re a vendor, keep one evidence set that supports both markets
  • This matters in buying decisions: 56% of healthcare buyers rejected a device over security concerns, and 35% won’t consider one without an SBOM

Module 2 Regulatory Framework FDA 524B and EU MDR

sbb-itb-535baee

Quick Comparison

The main point is simple: if you prepare for the U.S. standard, you’ll usually cover much of what EU reviewers and healthcare buyers want too.

EU Standards: MDR, IVDR, and MDCG Cybersecurity Disclosure Requirements

Where EU Disclosure Duties Come From

The EU doesn't have a stand-alone law just for medical device cybersecurity. Instead, cybersecurity sits inside the device safety framework.

The main hook is MDR Annex I, Section 17.2. It says devices must ensure IT security "in accordance with the state of the art", including protection against unauthorized access. That puts cybersecurity right inside the General Safety and Performance Requirements (GSPR). So if a device has weak cybersecurity controls, it can fail on safety grounds alone.

That point matters. In the EU, disclosure duties flow from safety rules, not from a separate cybersecurity statute.

The IVDR (Regulation 2017/746) follows the same model for in vitro diagnostic devices, so the same logic applies across both device types. MDCG 2019-16 Rev. 1 then gives manufacturers the day-to-day guidance they use to turn MDR and IVDR duties into documents, processes, and lifecycle controls.

In plain English: EU cybersecurity disclosure is now part of the device's safety baseline.

What Manufacturers Must Provide to Users and Operators

Under MDCG 2019-16 Rev. 1, manufacturers are expected to give healthcare organizations enough information to use a device securely. That includes documenting the intended IT environment, so hospitals and other operators can see the conditions the device was designed and tested for.

MDCG 2019-16 Rev. 1 does not flatly require an SBOM. But it does require continuous vulnerability monitoring. And because medical device software often depends on external components —which often require automated security questionnaires to manage— ^[1], a machine-readable inventory is often the most practical way to keep track of those dependencies and monitor them over time.

How Postmarket Monitoring Fits the EU Model

In the EU, cybersecurity duties don't stop once the device is on the market. Manufacturers have to treat newly found vulnerabilities as possible safety risks. If a vulnerability could affect clinical safety, it may trigger a Field Safety Corrective Action (FSCA) and may need to be reported through the vigilance system.

That means the postmarket surveillance plan needs to cover:

• active vulnerability monitoring
• a documented triage and remediation process
• clear criteria for when a cybersecurity issue becomes a safety issue

The link between cybersecurity and vigilance is direct. If a software flaw could cause a device to malfunction or let it be compromised, EU rules don't treat that as just an IT headache. They treat it as a patient safety issue.

The US takes a different path, with more explicit FDA disclosure duties across premarket, labeling, and postmarket requirements.

US Standards: FDA Cybersecurity Guidance and Cyber Device Requirements

FDA Premarket Cybersecurity Documentation

The FDA’s medical device cybersecurity framework now centers on Section 524B of the FD&C Act, which took effect on March 29, 2023. Section 524B applies to cyber devices - devices with software or firmware that connect to a network, directly or indirectly, and may face critical medical device security risks^[1].

In the US, these disclosures aren’t just label content. They’re part of the submission package and part of postmarket duties too. That’s a key difference from the EU’s more safety-focused path: the FDA spells out these items as direct submission requirements.

Under the FDA’s June 2025 guidance, premarket submissions for cyber devices must include^[1]:

• threat modeling
• a cybersecurity risk assessment
• security control documentation
• evidence that security testing was performed

The FDA also requires traceability across the full set of records. In plain English, the threat model, cybersecurity risk assessment, SBOM, and testing records need to line up with each other^[1]. If one file says a risk exists, another file should show how it was tested and handled.

Labeling, SBOM, and Support Lifecycle Disclosures

Premarket disclosure is only the first step. For cyber devices, an SBOM is a legal requirement under Section 524B. Submissions must include both a machine-readable SBOM in eSTAR format and a human-readable summary^[1].

The SBOM should follow the NTIA Minimum Elements, including^[1]:

• supplier name
• component name
• version
• unique identifiers such as Package URL or CPE
• dependency relationships

The FDA may also ask for VEX files to show whether listed vulnerabilities are exploitable in the device’s setup^[1]. That matters because a vulnerability on paper doesn’t always mean the device is exposed in practice.

User-facing disclosures matter too. What must be disclosed to users includes secure configuration instructions, defined user roles, and EOS/EOL dates^[1]. And there’s no wiggle room here: a missing SBOM can trigger a Refuse to Accept (RTA) decision and stop the review before it even begins^[1].

FDA Postmarket Vulnerability and Reporting Expectations

Once a device is cleared, the disclosure work doesn’t stop. The FDA expects manufacturers to continuously monitor for new vulnerabilities, including checking against the CISA Known Exploited Vulnerabilities (KEV) Catalog^[1]. It also expects documented procedures for triage, assessment, and remediation.

The SBOM must stay current after clearance. It has to be updated through the quality management system’s change control process whenever a patch or software update is released^[1]. On top of that, every vulnerability listed in the SBOM must be reviewed for possible patient safety impact, with a direct link to the ISO 14971 risk file^[1].

That setup ties cybersecurity disclosure to day-to-day quality control, not a one-and-done filing. Under QMSR, FDA investigators can inspect management review and quality audit records^[3].

EU vs. US: Side-by-Side Comparison of Disclosure Requirements

Regulatory Scope and Premarket Documentation

The biggest gap between these two systems comes down to how the duty is created.

In the US, the rule comes straight from law: FD&C Act Section 524B. In the EU, the duty comes from the "state of the art" language in MDR Annex I, Section 17.2, read through MDCG 2019-16 Rev. 1 guidance.

Scope is different too. The FDA focuses on a named device category: "cyber devices." That includes devices with software that can connect to a network, even if that connection is not active right now. The EU takes a broader path. Its expectations apply across software-enabled devices, including SaMD.

Here’s where that split shows up most clearly:

That means a manufacturer selling into both markets may be dealing with the same core security work, but packaging it in different ways. In the US, the submission path is more explicit. In the EU, the burden sits inside technical documentation and conformity assessment.

Labeling, SBOM, and User-Facing Security Information

Both systems expect manufacturers to give users enough information to use devices securely. But they don't ask for it in quite the same way.

The FDA makes an SBOM a legal requirement for cyber devices. The EU does not name an SBOM format as a hard rule, but treats it as part of the "state of the art" expectation. Same direction, different level of force.

The EU is also less specific on lifecycle metadata. The FDA directly expects end-of-support and end-of-life dates as part of SBOM lifecycle information. The EU points toward similar information, but without the same level of detail.

And then there's VEX. As of March 2026, the FDA has been actively requesting VEX files in premarket submissions ^[1]. The EU framework does not expressly require VEX.

For buyers and vendors, this matters fast. A hospital or health system may ask for an SBOM in both regions, but a US-facing vendor usually needs to be ready with more explicit lifecycle detail and, in some cases, VEX material too.

Postmarket Vulnerability Disclosure and Risk Management

Both regimes expect manufacturers to keep watching for vulnerabilities after launch. The difference is in the operating model.

The FDA expects manufacturers to monitor the CISA Known Exploited Vulnerabilities (KEV) Catalog, keep a living SBOM through change control, and tie vulnerability handling back to quality management and enterprise risk management ^[1]. The EU model, under MDCG 2019-16 Rev. 1, also expects active postmarket surveillance and vulnerability monitoring, but frames that work more directly around patient safety.

Put simply, the US model tends to spell out the mechanics in more detail. The EU model still expects active monitoring and follow-through, but leaves more room in how that gets documented and shown.

That split affects what HDOs ask for in security reviews and what vendors need to have ready when questions start coming in.

What Healthcare Organizations and Vendors Should Do Next

What HDOs Should Request During Device Evaluation

Once you compare the rules, the next move is simple: standardize what buyers ask for and what vendors hand over. HDOs should ask for a full evidence package during procurement.

That package should include a machine-readable SBOM in CycloneDX or SPDX, a VEX file, and support dates for each software component ^[1]. The VEX file shows whether known CVEs in those components are actually exploitable in the device’s specific setup ^[1].

HDOs should also ask for the manufacturer’s coordinated vulnerability disclosure process in writing, including contact channels, response timelines, and customer-notification windows ^[2]. A vague postmarket plan doesn’t help anyone. This package becomes the baseline for both EU and US reviews.

How Vendors Can Prepare for Cross-Jurisdiction Reviews

For vendors selling in both markets, a lot of the security work lines up. The FDA’s Quality Management System Regulation (QMSR), which takes effect on February 2, 2026, aligns US requirements with ISO 13485:2016, which helps support one quality system for both US and EU MDR expectations ^[2]. In plain English, one evidence set can often support two regulatory tracks.

Vendors should build SBOM generation into the CI/CD pipeline so the inventory stays current with every build, not only at submission time ^[2]. They should also keep a traceability matrix that links the threat model, cybersecurity risk assessment, SBOM, and testing evidence ^[2]. It also helps to run a vulnerability-response drill before a live incident hits, so teams can check that the QMS change-control workflow and customer notification process work from start to finish ^[1].

Using Censinet RiskOps to Manage Medical Device Cyber Risk Reviews

Keeping all of that evidence in one place is what helps cross-border reviews keep moving. Censinet RiskOps™ gives healthcare organizations a central platform to collect, organize, and act on manufacturer disclosures as part of structured third-party and medical device risk assessments. Censinet RiskOps™ centralizes SBOMs, VEX files, and postmarket evidence for HDO and vendor reviews.

Conclusion: Key Differences Between EU and US Medical Device Cybersecurity Standards

The bottom line is pretty simple: the biggest gap is structural. In the EU, cybersecurity sits inside device safety rules. In the U.S., the FDA makes SBOMs and related disclosures a clear part of the submission process for cyber devices.

That gap is getting smaller. The EU is tightening its approach through the CRA, which adds clearer SBOM and reporting duties.

For HDOs and vendors, the answer is practical: build one evidence package that works in both markets. A machine-readable SBOM in CycloneDX or SPDX, a VEX file, and documented postmarket monitoring procedures line up with the core expectations on both sides of the Atlantic.

Censinet RiskOps™ helps HDOs collect and track SBOMs, VEX files, and postmarket evidence in one review workflow.

FAQs

Does FDA 524B apply to my device?

Section 524B of the FD&C Act applies if your device is a cyber device.

In plain English, that means the device:

• includes sponsor-validated, installed, or authorized software or firmware
• can connect, directly or indirectly, to the internet or another network
• has features that make it open to cybersecurity threats

If your device fits that definition, you must meet the related cybersecurity documentation and postmarket surveillance requirements.

Why is an SBOM required in the U.S. but not in the EU?

In the United States, an SBOM is a legal requirement for devices that count as cyber devices under Section 524B of the FD&C Act. The FDA expects it as part of a premarket submission, and it can reject that submission if the SBOM is missing.

In the European Union, the MDR does not set a separate SBOM rule. Instead, it handles cybersecurity through the GSPR. In that setup, an SBOM is seen as state-of-the-art documentation that helps show a device meets broader safety requirements.

How should we build one package for both markets?

Build one package around a single global cybersecurity plan, using standards like ISO 14971, IEC 62304, and IEC 81001-5-1 as the base.

Start with a core process for vulnerability intake, risk assessment, validation, and monitoring. Then layer in country- or region-specific needs, such as FDA reporting in the United States or EU MDR/CRA documentation in Europe.

It helps to think of it like a main blueprint with local add-ons. The main blueprint stays the same. The add-ons handle what each market wants.

Use machine-readable SBOMs and VEX artifacts to support transparency, automated tracking, and traceability.

Related Blog Posts

• FDA Cybersecurity Guidance: Key Updates for 2025
• FDA Cybersecurity Design Controls: Key Requirements
• Minimum Cybersecurity Standards for Medical Device Suppliers
• SBOMs in Medical Device Lifecycle Management