Medical Device Security Standards: A Guide for HDOs

A manufacturer can satisfy the medical device security standards that apply to its product and still ship a device that adds risk to your network. Standards govern how a device is designed, documented, and maintained. They do not govern the VLAN it lands on, the vendor connection it opens, or the 15-year service life it will spend in your hospital. Healthcare delivery organizations (HDOs) inherit that gap the day a device goes live.

Closing it is the daily work of IoMT security. Internet of Medical Things (IoMT) devices share hospital networks with Internet of Things (IoT), operational technology (OT), and IT assets. This guide maps the standards that apply in 2026 and shows who each one binds. It also explains how security and clinical engineering teams can turn vendor compliance into measurable risk reduction. The guide covers FDA requirements, the consensus standards behind them, and the hospital-side frameworks that fall on your team.

What Are Medical Device Security Standards

Medical device security standards are the regulations, guidance documents, and consensus standards that define how connected medical devices must be designed, tested, documented, and maintained. Some carry legal force, such as FDA premarket requirements under Section 524B. Others are voluntary consensus standards, such as ANSI/AAMI SW96 or IEC 81001-5-1, that regulators recognize as evidence of good practice. A third group, including IEC 80001-1, addresses the hospitals that run devices after purchase.

The distinction matters for buyers. A regulation tells you what a manufacturer must submit to reach the market. A consensus standard tells you which process the manufacturer likely followed to get there. Neither tells you how a specific device will behave on your network. Hospitals need both the vendor’s evidence and their own view of the device in production.

Who Each Standard Binds: Manufacturers and Healthcare Delivery Organizations

Most medical device cybersecurity standards bind manufacturers, while a smaller set applies to the hospitals that operate the devices. The table below shows where each obligation falls and what an HDO can reasonably request from it. Use it as a checklist when procurement, security, and clinical engineering review a new device.

Standard or regulation	Issuer	Who it binds	Mandatory or voluntary	What an HDO can request
FD&C Act Section 524B	U.S. Congress, enforced by FDA	Manufacturers of cyber devices	Mandatory for new submissions	SBOM, patch commitments, disclosure policy
FDA premarket cybersecurity guidance (Feb 2026)	FDA	Manufacturers	Guidance that shapes FDA review	Threat model summary, security architecture
ANSI/AAMI SW96:2023	AAMI	Manufacturers	Voluntary consensus standard	Security risk management report
IEC 81001-5-1:2021	IEC	Health software manufacturers	Voluntary consensus standard	Secure development lifecycle evidence
IEEE 2621	IEEE	Manufacturers	Voluntary certification	Certification status
IEC 80001-1:2021	IEC	HDOs (responsible organizations)	Voluntary	Not applicable; this one is yours
HIPAA Security Rule	HHS	HDOs and business associates	Mandatory	Business associate terms
NIS2 Directive	European Union	EU hospitals as essential entities	Mandatory in member states	Supplier security assurances

FDA Requirements for Medical Device Security in 2026

The FDA sets the only legally binding medical device security requirements in the U.S. market, and its guidance changed twice in eight months. The current document is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued in February 2026. It replaces the version finalized on June 27, 2025.

Section 524B and Cyber Devices

Section 524B of the FD&C Act requires manufacturers of cyber devices to submit specific cybersecurity information before a device reaches the market. A cyber device includes software, can connect to the internet, and has characteristics that could be vulnerable to attack. Manufacturers must provide a plan to monitor and address postmarket vulnerabilities, including coordinated vulnerability disclosure. They must also maintain processes to release updates and patches, and they must submit a software bill of materials (SBOM).

The requirement took effect on March 29, 2023, and applies to new premarket submissions. Devices cleared before that date are not retroactively covered. Most hospitals therefore run a mixed fleet: newer devices with 524B documentation beside legacy devices with none. Clinical engineering can tag each record with its documentation status so security teams know where vendor evidence ends. That tag becomes a practical input when deciding which devices need compensating controls first.

What Changed in the February 2026 Guidance

The February 2026 guidance aligns FDA’s cybersecurity expectations with the Quality Management System Regulation, which brought ISO 13485 into the U.S. device quality framework. The retitled document keeps the Section VII recommendations for cyber devices added in 2025. For buyers, the practical effect is continuity. Vendors should now describe cybersecurity controls in quality management system terms, and procurement teams can ask for them in that language. Documentation that predates 2025 may use older terms and should be refreshed at renewal.

What the SBOM Requirement Gives Hospitals

An SBOM lists the commercial, open-source, and off-the-shelf software components inside a device. For a hospital, it turns an opaque device into one you can check against new CVEs as they are published. Asimily correlates component data with FDA recalls and security advisories so teams see which deployed devices a new disclosure affects. The broader case for component visibility is covered in why SBOMs matter for connected device security.

Consensus Standards That Shape Device Design

Consensus standards define the engineering processes manufacturers use to satisfy FDA and international regulators. They are voluntary, but a manufacturer that cannot show conformance to at least one should expect harder questions from a security-conscious buyer. The three below appear most often in vendor documentation.

ANSI/AAMI SW96 and TIR57

ANSI/AAMI SW96:2023 specifies security risk management requirements for device manufacturers across the full product lifecycle. It builds on AAMI TIR57 and aligns with ISO 14971, adding supply chain risk monitoring and assessment of reasonably foreseeable misuse by threat actors. It also expands production and post-production activities, including monitoring the third-party components listed in an SBOM. A vendor following SW96 should be able to produce a security risk management report on request.

IEC 62304 and IEC 81001-5-1

IEC 62304 defines lifecycle processes for medical device software and assigns safety classes based on potential harm. IEC 81001-5-1:2021 adds security activities to that lifecycle for health software, including secure design, security testing, and vulnerability handling. Together they describe how a manufacturer builds and maintains software. Neither describes how that software is deployed on a hospital network.

IEEE 2621 Certification

IEEE 2621 is a certification program that evaluates connected medical products against defined security requirements. The IEEE Medical Device Cybersecurity Certification Program notes that FDA has designated IEEE 2621.2 a Recognized Consensus Standard. The program began with diabetes devices, and IEEE is extending it to other device types.

Medical Device Security Standards for Hospitals and Health Systems

Medical device security standards for hospitals focus on how devices are connected, monitored, and governed after deployment. These frameworks place responsibility on the HDO, which is why security and clinical engineering teams need a shared view of every device. Several also overlap with broader privacy and critical infrastructure rules. Buyer concern is rising as well. A 2025 RunSafe Security report, 2025 Medical Device Cybersecurity Index, found 35% of healthcare organizations named OT systems like medical devices their top cybersecurity concern.

IEC 80001-1:2021

IEC 80001-1:2021 sets out risk management for IT networks that incorporate medical devices. It names the HDO as the responsible organization and asks it to manage safety, effectiveness, and security across connected systems. The standard is voluntary. It is still the clearest statement of what a hospital owns once a device is plugged in.

HIPAA Security Rule and the HHS HPH Cybersecurity Performance Goals

The HIPAA Security Rule requires HDOs to protect electronic protected health information, including data that medical devices store or transmit. In January 2025, HHS proposed updates that would add explicit asset inventory and network segmentation expectations. Asimily tracks the rulemaking in its coverage of the 2026 HIPAA cybersecurity rule. The voluntary HHS Healthcare and Public Health Cybersecurity Performance Goals point in the same direction.

State and International Requirements

State and international rules add obligations that sit beside federal requirements. New York hospitals must meet New York’s hospital cybersecurity regulation, 10 NYCRR 405.46. In the European Union, the NIS2 Directive treats hospitals as essential entities with supply chain security duties. EU MDR and its guidance document MDCG 2019-16 govern manufacturers selling into European markets.

Turning Standards Into Lower Risk on Your Network

Standards produce documentation, and documentation reduces risk only when a team can act on it. Asimily connects vendor evidence to what devices are actually doing on the network, across IoT, OT, IoMT, and IT assets. The four steps below follow the order most programs mature in.

Start With a Complete IoMT Inventory

Every framework above assumes you know which devices you have. Asimily builds a complete, agentless inventory safely and without disrupting clinical operations. Deep packet inspection and AI-driven classification identify each device’s model, firmware, services, and connections. That inventory is the baseline for matching SBOMs, advisories, and recalls to real devices.

Prioritize by Real Exploitability

A hospital fleet can carry thousands of open CVEs, and most will never be exploitable in that specific environment. A 2025 Asimily report, The State of Hospital Cyber Asset Exposure Management in 2025, found only 22% of hospital CISOs prioritize by device usage and criticality. Asimily’s ATT&CK Analysis determines whether a vulnerability is exploitable on a specific device in a specific topology. The result is a short, documented queue for vulnerability prioritization for IoMT.

Contain Exposures With Segmentation Orchestration

Many medical devices cannot be patched quickly, so containment is often the fastest control available. Asimily’s Segmentation Orchestration is the policy orchestration layer that sits on top of existing NAC platforms such as Cisco ISE, Aruba ClearPass, and Arista. It recommends where to start, creates policies in each NAC’s native format, and applies them in the correct order. Policy Simulation previews each policy’s impact against real, observed traffic before anything is deployed. Continuous Segmentation then keeps enforcement current as devices are patched, moved, or replaced.

Screen Devices Before Purchase With ProSecure

The cheapest exposure to fix is the one you never buy. ProSecure uses Asimily’s observed risk data on IoMT devices in the field to flag risky models and configurations before spend is committed. It gives procurement and clinical engineering a view beyond what a manufacturer discloses. Learn more about pre-purchase risk avoidance for IoMT.

How to Evaluate Vendors Against Medical Device Security Standards

Evaluating vendors against medical device security standards starts with asking for the evidence each standard produces. Request Manufacturer Disclosure Statement for Medical Device Security (MDS2) forms, SBOMs, and the manufacturer’s coordinated vulnerability disclosure policy. Ask for patch timelines in writing, including how quickly critical vulnerabilities are addressed out of cycle.

Then write those commitments into contracts. Define who applies patches, how remote access is scoped and reviewed, and what happens when a device reaches end of support. Compare answers against what your inventory shows once the device is live. Gaps between the paperwork and observed behavior are where your next exposure is most likely to appear.

The cost of getting this wrong is well documented. A 2025 IBM report, Cost of a Data Breach Report 2025, found health care remained the costliest industry for breaches at $7.42 million on average. Vendor evaluation is one of the few points where a hospital can reduce that exposure before a device ever connects. Treat the review as a gate, with security, clinical engineering, and procurement signing off together.

Frequently Asked Questions

What Are Medical Device Security Standards?

Medical device security standards are the regulations and consensus standards that govern how connected medical devices are designed, documented, and maintained. In the U.S., FDA requirements under Section 524B carry legal force for new cyber device submissions. Voluntary standards such as ANSI/AAMI SW96, IEC 62304, and IEC 81001-5-1 describe the engineering processes manufacturers follow. Hospitals rely on separate frameworks, including IEC 80001-1 and the HIPAA Security Rule, to manage devices after deployment. Together, these standards set a baseline that HDOs still need to verify on their own networks.

Does FDA Section 524B Apply to Legacy Medical Devices Already in Hospitals?

Section 524B applies to premarket submissions made on or after March 29, 2023, so it does not retroactively cover devices already cleared. A legacy infusion pump or imaging system in service today may have no SBOM and no committed patch timeline. Hospitals should treat those devices as the highest documentation gap in the fleet. Compensating controls such as segmentation, configuration hardening, and monitoring usually carry more weight for legacy devices than vendor updates. Replacement planning should factor in whether new models meet 524B.

What Is the Difference Between IEC 62304 and IEC 81001-5-1?

IEC 62304 defines software lifecycle processes for medical device software, including development, maintenance, risk management, and problem resolution. IEC 81001-5-1 adds security activities to that lifecycle for health software, such as secure design, security testing, and vulnerability handling. Manufacturers often use both, since one covers software safety and the other covers security. For buyers comparing medical device cybersecurity standards, conformance to 81001-5-1 is the stronger signal of a mature security process. Neither standard addresses how the software is configured on a hospital network.

What Is ANSI/AAMI SW96?

ANSI/AAMI SW96:2023 is a consensus standard that sets security risk management requirements for medical device manufacturers. It builds on AAMI TIR57 and aligns with ISO 14971, the core risk management standard for medical devices. SW96 adds supply chain risk monitoring, assessment of foreseeable misuse by attackers, and expanded post-production activities. Manufacturers that follow it should maintain a security risk management file and report. Hospitals can ask for a summary of that report during procurement to understand residual risk.

Which Cybersecurity Standards Apply to Hospitals Rather Than Manufacturers?

Hospitals are bound by the HIPAA Security Rule in the U.S. and, in the European Union, by NIS2 as essential entities. IEC 80001-1:2021 is the main voluntary standard for managing risk on networks that include medical devices. State rules such as New York’s 10 NYCRR 405.46 add further requirements. These medical device security standards for HDOs focus on inventory, risk analysis, access control, and incident response. A 2026 FedTech Magazine report, FDA Tightens Its Medical Device Cybersecurity Guidance, quoted Health-ISAC estimating medical devices at 5% to 11% of hospital endpoints.

What Is an MDS2 Form, and How Should Hospitals Use It?

An MDS2 form is a standardized questionnaire in which manufacturers disclose a device’s security capabilities. It covers topics such as authentication, encryption, audit logging, remote service, and patching support. Hospitals should request an MDS2 form before purchase and compare the answers across competing models. The form is a self-attestation, so its claims should be checked against how the device behaves once connected. Keeping MDS2 forms linked to inventory records helps clinical engineering answer audit questions quickly.

How Do I Use a Medical Device SBOM From a Manufacturer?

A medical device SBOM is most useful when it is matched against your inventory and checked continuously against new vulnerability disclosures. Load the component list into a system that tracks which deployed devices contain each component. When a new CVE is published, the SBOM shows which devices are affected without waiting for a vendor bulletin. Pair that view with exploitability analysis so teams act on reachable risk first. SBOMs age quickly, so request updated versions whenever firmware changes. IoMT security standards increasingly treat the SBOM as a shared artifact between manufacturer and hospital.

Is IEC 80001-1 Required for Hospitals?

IEC 80001-1:2021 is voluntary in the U.S. and most other markets. No federal regulation requires hospitals to certify against it. It remains useful because it defines the hospital as the responsible organization for connected device risk and describes a repeatable risk management process. Many HDOs use it as a structure for their device security programs and for dividing responsibilities between IT, security, and clinical engineering. Auditors and accreditors often recognize its terminology.

What Is the Best Way to Prioritize Medical Device Vulnerabilities?

The most effective way to prioritize medical device vulnerabilities is to rank them by real exploitability and clinical impact in your environment. Medical device security standards expect risk-based remediation but rarely prescribe a ranking method. Generic CVSS scores treat every instance of a CVE the same, regardless of network position or compensating controls. A 2025 Asimily report, The State of Hospital Cyber Asset Exposure Management in 2025, found only 22% of hospital CISOs prioritize by device usage and criticality. Asimily’s ATT&CK Analysis narrows the list to the devices driving the majority of risk. Each ranking carries a documented reason.

How Do Hospitals Secure Medical Devices That Cannot Be Patched?

Hospitals secure unpatchable medical devices mainly by limiting what those devices can reach and what can reach them. Network segmentation restricts traffic to the connections a device needs for clinical use. Configuration hardening removes unused services and default credentials. Continuous monitoring flags unexpected behavior for fast response. Asimily’s Segmentation Orchestration lets you create or auto-generate these policies on existing NAC or firewall infrastructure and simulate their impact against observed traffic before deployment, which protects clinical uptime.

Where Health Systems Should Start

Health systems should start with a complete inventory, because medical device security standards all assume one exists. From there, match vendor evidence to real devices, prioritize by exploitability, and contain what cannot be patched. Compliance mapping across frameworks gives auditors and boards a record of that work. The standards will keep changing, and a current view of every device keeps the program ready for the next revision.

See how Asimily maps medical device security standards to your network.