Compliance Requirements for Medical Device Software (2026)

TL;DR

Compliance requirements for medical device software center on a connected set of international standards and FDA regulations: IEC 62304 for the software lifecycle, ISO 13485 for quality management, ISO 14971 for risk management, and Section 524B for cybersecurity. The FDA’s new QMSR (effective February 2026) aligns U.S. rules with ISO 13485, making global harmonization a reality. This glossary defines every key term, standard, and acronym your team needs to navigate medical device software compliance in 2026 and beyond.

---

Medical device software sits at the intersection of multiple overlapping standards, FDA regulations, and international frameworks. For engineers, regulatory affairs professionals, and startup founders, the challenge isn’t just understanding one standard. It’s understanding how they all connect and which ones apply to your specific product.

This glossary exists because no single reference on the web covers all the compliance requirements for medical device software in one place. Most guides focus on a single standard or a narrow slice of the regulatory picture. The entries below span everything from IEC 62304 safety classes to the brand-new QMSR, from SOUP documentation to SBOM requirements under Section 524B.

Each entry includes a plain-language definition, why it matters, and where to find the authoritative source. If you’re building software that touches patient safety, this is your map.

Explore our full glossary for related terms across software engineering and product development.

---

How the Standards Connect

Before jumping into individual terms, it helps to see the big picture. The compliance requirements for medical device software form a layered system, not a flat checklist.

ISO 13485 is the umbrella. It defines your quality management system (QMS), the organizational processes that prove you can consistently produce safe, effective devices.

IEC 62304 sits inside that umbrella. It specifies the software lifecycle processes (planning, requirements, design, implementation, verification, release, maintenance) that your QMS must govern.

ISO 14971 feeds into both. It provides the risk management process that determines your software’s safety classification under IEC 62304 and drives design decisions throughout the lifecycle.

Section 524B and IEC 81001-5-1 add a cybersecurity layer on top. Section 524B is the FDA’s legal mandate for cyber devices, requiring an SBOM and ongoing vulnerability management. IEC 81001-5-1 supplements IEC 62304 with security-specific activities at each lifecycle phase.

The FDA’s QMSR (effective February 2, 2026) ties the U.S. regulatory framework directly to ISO 13485, replacing decades of divergent rules. This is the single biggest compliance shift in recent memory.

Think of it as concentric rings: ISO 13485 wraps around IEC 62304, which is informed by ISO 14971, and the cybersecurity standards overlay the entire structure.

---

Glossary of Compliance Requirements for Medical Device Software

510(k) Premarket Notification

The most common FDA clearance pathway for Class II medical devices, including many Software as a Medical Device (SaMD) products. A 510(k) submission demonstrates that a new device is substantially equivalent to a legally marketed predicate device.

Why it matters: Most medical device software headed for the U.S. market will go through a 510(k). Since March 29, 2023, 510(k) submissions for cyber devices must include cybersecurity documentation under Section 524B, including an SBOM and a plan for post-market vulnerability management. Other submission types (PMA, De Novo, HDE) carry the same requirement.

Source: FDA premarket submission requirements

---

AAMI TIR45

A technical information report published by the Association for the Advancement of Medical Instrumentation (AAMI) that provides guidance on using agile software development practices within the framework of IEC 62304.

Why it matters: IEC 62304 doesn’t require waterfall development, but you can’t substitute sprint artifacts for the documentation the standard demands. Practitioners on forums and in Jama Software’s analysis consistently point to AAMI TIR45 as the best reference for making agile work within IEC 62304 compliance. Teams that try to wing it without this reference often discover painful gaps during audits.

---

Cyber Device

The FDA’s definition under Section 524B for a medical device that (1) includes software, (2) can connect to the internet directly or indirectly, and (3) possesses characteristics that make it vulnerable to cybersecurity threats.

Why it matters: If your product meets all three criteria, the full weight of Section 524B applies, regardless of where your company is located. Given that a study found 53% of connected medical and IoT devices have at least one unpatched critical vulnerability, the FDA’s definition is deliberately broad. Most modern medical device software qualifies.

---

De Novo Classification

An FDA pathway for novel medical devices that are low-to-moderate risk but have no substantially equivalent predicate device. This creates a new regulatory classification that future devices can reference in 510(k) submissions.

Why it matters: Many innovative SaMD products, especially those using AI/ML, lack predicates and must go through De Novo. The pathway is more involved than a standard 510(k) but less burdensome than a PMA. All compliance requirements for medical device software (including cybersecurity under 524B) still apply.

---

Design Controls

The structured process defined in 21 CFR 820 (now aligned with ISO 13485 Clause 7.3 under the QMSR) for translating user needs into verified, validated device designs. Design controls encompass planning, inputs, outputs, reviews, verification, validation, and transfer.

Why it matters: Design controls are the backbone of any medical device development process. For software teams, they formalize what might otherwise be ad hoc: documenting user needs, deriving requirements, tracing them through architecture and testing, and proving the final product meets its intended use. The Design History File (DHF) is the artifact that captures this entire chain.

If you’re evaluating whether to build compliance processes internally or bring in outside expertise, the scope of design controls is often what tips the decision. See how we approach compliance-sensitive engineering work.

---

DHF (Design History File)

The complete record of a device’s design activities, including all design inputs, outputs, reviews, verification and validation evidence, and change records. The DHF serves as proof that design controls were followed.

Why it matters: During an FDA inspection or notified body audit, the DHF is what gets examined. For software, this means your requirements traceability matrix, test reports, risk analysis, and architecture documents must be complete and internally consistent. Teams that maintain the DHF from sprint one avoid the painful “reconstruct everything after the code is frozen” scenario that practitioners frequently warn about.

---

EU MDR (Medical Device Regulation 2017/745)

The European Union’s regulatory framework for medical devices, which replaced the earlier Medical Device Directives. EU MDR applies to any medical device (including software) sold in the EU market.

Why it matters: If your product targets both the U.S. and EU markets, you face two parallel regulatory systems. The good news: the FDA’s QMSR alignment with ISO 13485 means your QMS can now serve both markets more efficiently. The challenge: EU MDR has its own clinical evidence requirements and conformity assessment procedures that don’t have direct FDA equivalents.

---

FDA QMSR (Quality Management System Regulation)

The regulation that became effective February 2, 2026, replacing the decades-old Quality System Regulation (QSR) under 21 CFR Part 820. The QMSR incorporates ISO 13485:2016 by reference, aligning U.S. medical device regulations with the international standard.

Why it matters: This is one of the most significant changes to U.S. medical device compliance in decades. Before QMSR, manufacturers selling globally maintained separate documentation for FDA (QSR-based) and international (ISO 13485-based) requirements. Now the same QMS can satisfy both. For software teams, this means your ISO 13485-certified processes carry direct regulatory weight in the U.S. If you haven’t updated your QMS documentation to reflect this change, you’re already behind.

---

IEC 62304 (Medical Device Software Lifecycle Processes)

The international standard that defines lifecycle requirements for developing and maintaining medical device software. It covers planning, requirements analysis, architectural design, detailed design, implementation, integration testing, system testing, release, and maintenance.

Why it matters: IEC 62304 is the foundational standard for compliance requirements for medical device software worldwide. The FDA recognizes it as a consensus standard, meaning a declaration of conformity carries significant evidentiary weight in premarket submissions. The standard scales its documentation burden by software safety class (A, B, or C), so a low-risk Class A product requires far less paperwork than a life-sustaining Class C device.

Practitioner insight from TopFlightApps is worth noting: IEC 62304 compliance is a documentation discipline you run alongside the build. Start it in the first sprint, and it adds hours per sprint. Wait until after the code is frozen, and it costs months.

For teams building connected devices, our guide on secure architecture patterns covers practical implementation approaches.

---

IEC 62304 Edition 2 (Expected Late 2026)

A major revision of IEC 62304 currently targeting publication in mid-to-late 2026. The most significant proposed change replaces the three safety classes (A, B, C) with two process rigor levels: Level I (replacing Class A) and Level II (replacing both Class B and Class C).

Why it matters: Under the current edition, teams sometimes exploit the boundaries between classes to reduce documentation burden. Edition 2 addresses this by assigning Level II to any software that implements a risk control measure, regardless of external controls. The revision will also introduce requirements related to AI/ML planning, reflecting the growing role of machine learning in medical devices. Teams should monitor this closely and prepare for a potentially more demanding classification outcome.

---

IEC 62366 (Usability Engineering)

The international standard specifying the process for manufacturers to analyze, specify, develop, and evaluate the usability of medical devices as it relates to safety. It applies to all medical devices, including software.

Why it matters: Usability failures are a common source of adverse events. IEC 62366 requires a formative and summative usability evaluation process that produces evidence your device can be used safely by its intended users. For SaMD products, this often means conducting use-error risk analysis and usability testing with representative clinical workflows.

---

IEC 81001-5-1 (Cybersecurity for Health Software)

A cybersecurity standard tailored specifically for medical devices and health IT software, released in 2021. It adapts IEC 62443-4-1 (originally developed for industrial control systems) to the healthcare domain and supplements IEC 62304 with security activities at each lifecycle phase.

Why it matters: IEC 81001-5-1 is scheduled for formal EU harmonization by May 27, 2028. Once harmonized, it becomes a critical basis for demonstrating conformity under EU MDR. Even before that date, adopting it now positions your product for smoother EU market access and aligns with the FDA’s SPDF recommendations. Think of it as the cybersecurity playbook that sits alongside your IEC 62304 lifecycle.

---

ISO 13485 (Quality Management System for Medical Devices)

The international standard specifying QMS requirements for organizations that design, develop, produce, install, or service medical devices. It defines the processes necessary to demonstrate that a manufacturer can consistently deliver safe, effective devices meeting user needs and applicable regulations.

Why it matters: ISO 13485 certification is the practical norm for market access worldwide, even in jurisdictions where it isn’t literally mandated. With the QMSR now incorporating ISO 13485 by reference, it’s the single QMS standard that matters for both U.S. and international compliance. For software-only companies, though, there’s a known friction point: ISO 13485’s processes were designed with hardware manufacturing in mind. Academic researchers and practitioners note that concepts like “design transfer to manufacturing” feel abstract when your “manufacturing” is a CI/CD pipeline deploying code. Teams need to interpret the standard’s intent rather than its literal hardware-oriented language.

---

ISO 14971 (Risk Management for Medical Devices)

The international standard specifying terminology, principles, and a comprehensive process for risk management of medical devices, including SaMD and in vitro diagnostic devices. It covers hazard identification, risk estimation, risk evaluation, risk control, and monitoring of risk control effectiveness throughout the device lifecycle.

Why it matters: Risk management under ISO 14971 is not a one-time exercise. It’s an ongoing process that applies to every stage of the device lifecycle. Your IEC 62304 software safety classification depends on the risk analysis performed under ISO 14971. Your design controls reference it. Your post-market surveillance feeds back into it. Most experienced teams treat ISO 14971 as the thread that ties every other compliance requirement together.

Classification disputes are a recurring friction point in practice. Deciding whether software is Class A, B, or C involves judgment calls that engineering and regulatory teams may see differently. A documented rationale tied to your ISO 14971 risk analysis avoids stalls later.

---

MDSAP (Medical Device Single Audit Program)

A program that allows a single regulatory audit of a medical device manufacturer’s QMS to satisfy the requirements of up to five regulatory authorities: the United States (FDA), Canada (Health Canada), Brazil (ANVISA), Australia (TGA), and Japan (MHLW/PMDA).

Why it matters: For manufacturers selling into multiple markets, MDSAP reduces the audit burden significantly. Instead of hosting separate inspections for each regulatory authority, one MDSAP audit covers all participating jurisdictions. With the QMSR aligning U.S. requirements to ISO 13485, MDSAP audits become even more streamlined.

---

PCCP (Predetermined Change Control Plan)

An FDA framework that allows manufacturers of AI/ML-based SaMD to describe anticipated modifications to a device’s algorithm and the methodology for implementing those changes, all within the original premarket submission.

Why it matters: Traditional regulatory pathways assume a device doesn’t change after clearance. AI/ML devices, by definition, may learn and adapt. The PCCP lets manufacturers define the boundaries of acceptable change upfront, so iterative algorithm improvements don’t each require a new submission. This is still an evolving area of compliance requirements for medical device software, and teams building adaptive algorithms should engage with FDA guidance early.

---

Post-Market Surveillance (PMS)

The ongoing, systematic process of monitoring medical device performance, safety, and compliance after the device is released to market. PMS includes complaint handling, adverse event reporting, trend analysis, and periodic safety updates.

Why it matters: Compliance doesn’t end at market clearance. Section 524B specifically requires a plan for monitoring and addressing post-market cybersecurity vulnerabilities. ISO 14971 requires ongoing risk monitoring. EU MDR has its own PMS report and periodic safety update requirements. Teams that treat post-market as an afterthought often face the most painful (and expensive) compliance failures.

For healthtech teams thinking about how to build telemetry and monitoring into their products from day one, our resource on privacy-first telemetry collection covers the practical architecture.

---

SaMD (Software as a Medical Device)

Software that performs one or more medical purposes without being part of a hardware medical device. SaMD runs on general-purpose computing platforms (phones, tablets, cloud servers) and is regulated based on its intended use and risk level.

Why it matters: The FDA classifies SaMD into Class I (low risk), Class II (moderate risk), and Class III (high risk). Most SaMD products fall into Class II, requiring a 510(k) or De Novo submission. All the compliance requirements for medical device software apply to SaMD: IEC 62304, ISO 13485, ISO 14971, and (if the product is internet-connected) Section 524B. The SaMD category is growing rapidly as more clinical functions move to software, making it one of the most active areas of FDA regulatory development.

---

SBOM (Software Bill of Materials)

A machine-readable inventory listing all software components in a device, including commercial, open-source, and off-the-shelf components. Each entry should include metadata such as version, supplier, and license type.

Why it matters: Section 524B explicitly requires an SBOM as part of premarket submissions for cyber devices. Beyond the legal requirement, an SBOM is your operational tool for vulnerability management. When a new CVE is published for a library your device uses, the SBOM tells you immediately whether you’re affected. Every component, from the operating system to the smallest utility library, needs to be tracked. This isn’t just about compliance; it’s about knowing what’s inside your product.

---

Section 524B (Ensuring Cybersecurity of Devices)

The provision added to the Federal Food, Drug, and Cosmetic Act (FD&C Act) by Section 3305 of the Consolidated Appropriations Act of 2023. It establishes cybersecurity requirements for cyber devices seeking FDA market authorization.

Why it matters: Section 524B imposes three core obligations: (1) submit a plan to monitor, identify, and address post-market cybersecurity vulnerabilities, including coordinated vulnerability disclosure; (2) design, develop, and maintain processes providing reasonable assurance that the device is cybersecure, with post-market updates and patches; and (3) provide a software bill of materials. These requirements have applied to all new premarket submissions since March 29, 2023. They apply to any cyber device intended for the U.S. market, regardless of manufacturer location.

---

Software Safety Classification (Class A / B / C)

IEC 62304’s risk-based categorization system that determines the rigor of documentation and process requirements for medical device software. Class A means no injury or damage to health is possible. Class B means non-serious injury is possible. Class C means death or serious injury is possible.

Why it matters: Your safety classification directly determines how much documentation you need to produce and maintain. Class A requires the least, Class C the most. Most early-stage digital health products land in Class B, which fits inside an agile workflow without overwhelming the team. The classification must be justified by your ISO 14971 risk analysis. As noted above, IEC 62304 Edition 2 will collapse these three classes into two rigor levels, so teams should prepare for potential reclassification.

---

SOUP (Software of Unknown Provenance)

Any software component that was not developed specifically for your medical device, or for which adequate development records are not available. This includes open-source libraries, third-party modules, commercial off-the-shelf (COTS) software, operating systems, networking stacks, and cloud service APIs.

Why it matters: IEC 62304 requires you to identify, document, and risk-assess every piece of SOUP in your software system. Practitioners consistently report that SOUP management is one of the most labor-intensive aspects of IEC 62304 compliance. The challenge isn’t just listing components; it’s evaluating whether each one is suitable for its intended use in a safety-critical context, tracking updates, and managing the risk of using code you didn’t write and can’t fully verify. Your SBOM and your SOUP list overlap significantly, but they serve different purposes: the SBOM is an inventory for cybersecurity, while SOUP documentation is a risk assessment for safety.

---

SPDF (Secure Product Development Framework)

The FDA’s recommended approach for managing cybersecurity risk throughout the total product lifecycle. An SPDF integrates security considerations into every phase of design, development, release, and maintenance.

Why it matters: The FDA doesn’t prescribe a specific SPDF but expects manufacturers to demonstrate they have one. The primary goal is producing devices that are not only safe and effective but also trustworthy and resilient. Your SPDF should align with the activities described in IEC 81001-5-1 and address the requirements of Section 524B. Think of it as the organizational commitment that makes cybersecurity compliance systematic rather than reactive.

---

V&V (Verification and Validation)

Two distinct processes required throughout medical device development. Verification confirms the product was “built right” (it meets specified requirements). Validation confirms the product is “the right thing” (it meets user needs and intended uses in the actual use environment).

Why it matters: V&V is where compliance requirements for medical device software become tangible. Verification includes code reviews, unit tests, integration tests, and static analysis. Validation includes system-level testing, usability testing, and clinical evaluation. IEC 62304 specifies verification requirements at multiple levels (unit, integration, system), and ISO 13485 requires validation of the finished device. Gaps in V&V traceability are one of the most common audit findings.

Practitioners on specialized forums report that traceability from user needs through software requirements, architecture, implementation, and verification tends to break down when it lives in spreadsheets and disconnected tools. Gaps appear quietly and surface at the worst time: during an FDA submission or notified body audit.

---

Vulnerability Disclosure

The coordinated process for reporting, communicating, and addressing discovered security flaws in a medical device. Section 524B requires manufacturers to have vulnerability disclosure procedures as part of their post-market cybersecurity plan.

Why it matters: Vulnerability disclosure isn’t optional for cyber devices. You need a documented process for receiving vulnerability reports from external researchers, triaging them, developing patches, and communicating with affected users and the FDA. The emphasis on “coordinated” disclosure means working collaboratively with the security research community rather than ignoring or suppressing reports.

---

Which Standards Apply to Your Product?

Not every medical device software product faces the same compliance requirements. Here’s a quick decision framework:

All medical device software (whether standalone or embedded in hardware) needs IEC 62304, ISO 13485, and ISO 14971. These three form the non-negotiable core.

If your software connects to the internet (directly or indirectly), it’s almost certainly a cyber device under Section 524B. Add SBOM requirements, SPDF, vulnerability disclosure, and consider adopting IEC 81001-5-1.

If you’re targeting the U.S. market, the QMSR applies, which now means ISO 13485 compliance satisfies the FDA’s QMS expectations. You’ll also need a premarket submission (510(k), De Novo, or PMA depending on your risk class).

If you’re targeting the EU market, EU MDR applies, and IEC 81001-5-1 will become increasingly important as its 2028 harmonization date approaches.

If your software uses AI/ML, look into the PCCP framework and watch for IEC 62304 Edition 2’s AI planning requirements.

If you’re running agile, get a copy of AAMI TIR45 and structure your sprints around its recommendations from day one.

For teams evaluating whether to build compliance processes in-house or partner with an experienced development team, the scope of overlapping standards often drives the decision.

---

Common Pitfalls in Medical Device Software Compliance

Starting compliance late. The most expensive mistake. Reconstructing documentation after the code is written costs orders of magnitude more than building it alongside the code. Teams that start IEC 62304 documentation in sprint one add hours per sprint. Teams that wait add months.

Treating standards in isolation. ISO 13485, IEC 62304, and ISO 14971 are deeply interconnected. Your risk management file (ISO 14971) determines your software safety class (IEC 62304), which determines your documentation requirements, all within your QMS (ISO 13485). Teams that assign different people to each standard without coordination create contradictions and gaps.

Underestimating SOUP management. Every open-source library, every third-party SDK, every API client needs to be documented and risk-assessed. This is tedious, unglamorous work, and it’s where compliance frequently breaks down.

Ignoring the QMSR transition. If your QMS documentation still references the old QSR language, it needs updating. The QMSR is effective now.

Spreadsheet-based traceability. Jama Software’s practitioner analysis highlights a pattern that experienced teams recognize: traceability across requirements, design, tests, and risk items that lives in disconnected spreadsheets will eventually develop gaps. Those gaps surface during audits.

---

Frequently Asked Questions

What are the main compliance requirements for medical device software in the U.S.?

The core requirements are IEC 62304 (software lifecycle), ISO 13485 (quality management, now incorporated by reference under the QMSR), and ISO 14971 (risk management). If your device connects to the internet, Section 524B adds cybersecurity mandates including SBOM submission and post-market vulnerability management. You’ll also need a premarket submission (typically a 510(k) for Class II devices).

Does IEC 62304 require waterfall development?

No. IEC 62304 is process-agnostic. You can use agile, but you need to produce the documentation artifacts the standard requires. AAMI TIR45 is the recognized reference for mapping agile practices to IEC 62304’s expectations. Sprint demos and Jira tickets alone don’t satisfy the standard.

What changed with the FDA’s QMSR in 2026?

The QMSR replaced the decades-old Quality System Regulation (QSR) under 21 CFR Part 820, effective February 2, 2026. It incorporates ISO 13485:2016 by reference, meaning U.S. FDA requirements are now directly aligned with the international QMS standard. Manufacturers no longer need to maintain separate documentation for FDA and ISO 13485 compliance.

What is the difference between SOUP and SBOM?

SOUP (Software of Unknown Provenance) is an IEC 62304 concept focused on safety: identifying and risk-assessing third-party software components in your device. An SBOM (Software Bill of Materials) is a cybersecurity inventory required under Section 524B, listing all software components with version, supplier, and license metadata. The lists overlap significantly, but they serve different regulatory purposes.

When does IEC 62304 Edition 2 take effect?

Edition 2 is targeting publication in mid-to-late 2026, though regulatory timelines can shift. The key change is replacing three safety classes (A, B, C) with two process rigor levels (Level I and Level II). Teams currently classifying their software as Class A or B should evaluate whether they’d be reclassified under the new scheme.

Do compliance requirements for medical device software apply to AI/ML-based products?

Yes. AI/ML-based SaMD products must meet all the same standards (IEC 62304, ISO 13485, ISO 14971) plus the cybersecurity requirements if internet-connected. The FDA’s Predetermined Change Control Plan (PCCP) framework addresses the unique challenge of algorithms that evolve after clearance. IEC 62304 Edition 2 is also expected to introduce AI-specific planning requirements.

Is ISO 13485 certification legally required?

In many jurisdictions, ISO 13485 certification isn’t technically mandated by law, but it’s the practical norm for market access. With the QMSR now incorporating ISO 13485 by reference for the U.S. market, and EU MDR expecting equivalent QMS evidence, operating without ISO 13485 certification creates unnecessary friction with every regulatory authority you’ll encounter.

How do I handle compliance if I’m a software-only company with no hardware?

The same standards apply, but interpretation matters. ISO 13485’s processes were designed with hardware manufacturing in mind, so concepts like “design transfer to manufacturing” need to be adapted for software deployment workflows. IEC 62304 is more naturally suited to software-only companies. The key is documenting how your CI/CD pipeline, version control, and release processes map to the standard’s requirements.

---

Building medical device software that meets regulatory requirements takes more than good engineering. It takes process discipline from the first line of code. If your team needs a development partner with experience in compliance-sensitive healthtech builds, get in touch with our team to discuss your project.