Medical Device Software Development: A 2026 Guide

Sophie Laurent Legal & Compliance Lead, YuSMP Group · Advising MedTech and digital-health teams on IEC 62304, ISO 13485, FDA and EU MDR pathways and the EU AI Act

TL;DR — key facts at a glance

What is medical device software development?

Medical device software development is the design, engineering and validation of software that either is a medical device or runs inside one, carried out under a regulated quality management system. It covers Software as a Medical Device (SaMD) such as a diagnostic-imaging analyzer, the embedded firmware inside an infusion pump or patient monitor, and the companion apps and cloud services that connect them. What separates it from ordinary product engineering is a single constraint: because the software can influence a clinical decision or a therapy, a defect is a patient-safety event, so safety and regulatory evidence shape every decision from the first sprint.

That constraint is why experienced healthcare software development services teams start with the regulatory framing — intended use, safety classification, applicable standards — before a line of feature code is written. The intended-use statement drives the device class, the class drives how much of IEC 62304 you must satisfy, and that in turn sets the documentation, testing and market pathway. Software development for medical devices done in the reverse order — build first, document later — is the most common and most expensive mistake in the field, because retrofitting design controls and traceability onto finished code effectively means doing the work twice.

Organizations commission custom software development for medical devices for a few clear reasons: no off-the-shelf platform matches their clinical claim, they are building the device itself as a product, or a legacy system can no longer meet current cybersecurity and interoperability rules. The rest of this guide maps what a compliant build actually involves in 2026 — the classes, the standards, the process, the AI rules, security, and what it costs.

SaMD vs embedded device software

The first decision is what kind of medical device software you are building, because it sets everything downstream. Regulators split the field into two families, and a real product often includes both on one connected system.

• Software as a Medical Device (SaMD) — software that performs a medical purpose on its own, without being part of a hardware device: an app that flags a stroke on a CT scan, a clinical dosing calculator, or an algorithm that triages retinal images. Software as a medical device development is classified by the risk of the decision it informs, following the international IMDRF framework the FDA and EU both use.
• Software in a Medical Device (SiMD) — the embedded firmware that controls a physical device such as a ventilator, pump or monitor. It is regulated as part of that device, but its lifecycle still follows IEC 62304.
• Medical Device Data Systems & accessories — software that transfers, stores or displays data without interpreting it can be lower-risk or unregulated, but the boundary is narrow and intended-use wording decides it.

Naming the category early tells you the standards, the regulatory class and the budget that follow. A common trap is a "wellness" or "clinical decision support" claim that quietly crosses into a regulated medical purpose — at which point the whole quality system applies retroactively. When the intended use is ambiguous, treat it as regulated and confirm the classification with your notified body or FDA pre-submission before committing to an architecture.

What regulations apply to medical device software in 2026?

Medical device software has to satisfy a market authorization and a stack of consensus standards, and the two markets — US and EU — overlap heavily but are not identical. The table below is the core set every 2026 build plans around; the exact subset depends on your device class and target markets.

Two points catch teams out. First, IEC 62304 is a software standard, but it sits inside ISO 13485 and ISO 14971 — you cannot satisfy it in isolation, and the FDA recognizes it as a consensus standard, so a Declaration of Conformity can streamline a 510(k). Second, EU MDR reclassified most standalone software upward: a Rule 11 device that informs a clinical decision is usually class IIa or higher, which means a Notified Body, not self-certification. If your product handles protected health information in the US, HIPAA also applies — our HIPAA software development checklist covers that engineering-level detail.

The medical device software development process (IEC 62304)

The medical device software development process is a controlled lifecycle, not a set of gates you bolt on at the end — IEC 62304 defines the activities, and how many you must perform depends on your software safety class. IEC 62304 assigns each software item a class by worst-case harm: Class A (no injury possible), Class B (non-serious injury possible) and Class C (death or serious injury possible). Edition 2 of the standard, targeted for publication in August 2026, streamlines these classes and adds explicit clauses for AI and machine-learning components, aligning the lifecycle with agile delivery for lower-risk updates.

1. Planning & intended use: define the clinical claim, classify the device and the software safety class, and set up the quality system and risk-management file. This step fixes most of the eventual budget.
2. Requirements & risk analysis: derive software requirements from the intended use and from ISO 14971 hazard analysis, with every requirement traceable to a risk control.
3. Architecture & detailed design: for Class B and C, document the architecture and segregate safety-critical items so a failure cannot propagate — this is where design effort concentrates.
4. Implementation & unit verification: build to the design with coding standards, static analysis and unit tests, keeping traceability from code back to requirement.
5. Integration, system & verification testing: verify the software against requirements and validate it against the clinical intended use, with documented, repeatable evidence.
6. Release & regulatory submission: compile the design history file and technical documentation for the FDA 510(k)/De Novo or the EU MDR technical file and Notified Body review.
7. Maintenance & post-market surveillance: monitor field performance, manage software changes under change control, and feed complaints and incidents back into risk management.

The discipline is the same rigor behind any regulated build — our secure software development life cycle guide shows how the verification and traceability mindset generalizes. What is specific to medical devices is that the evidence is the deliverable: an auditor or reviewer judges the documentation trail as much as the running software.

How is AI in medical devices regulated in 2026?

AI-enabled medical device software is regulated as a medical device first and an AI system second, and 2026 is the year the second layer became real in the EU. In the US, the FDA reviews AI/ML devices through its existing pathways and, since finalizing its guidance in December 2024, lets manufacturers pre-authorize model updates with a Predetermined Change Control Plan (PCCP) — you specify in advance which retraining and performance changes you may ship without a new submission, which finally makes iterative machine learning compatible with device regulation. The FDA's Good Machine Learning Practice principles set the expectations for data quality, validation and monitoring.

In the EU, the picture is heavier. AI that is embedded in, or acts as, an MDR class IIa, IIb or III device is automatically classified high-risk under the EU AI Act, which layers data-governance, transparency, record-keeping and human-oversight obligations on top of MDR. The AI Act's medical-device provisions began applying in August 2026, with a longer runway to August 2027 for higher-risk CE-marked devices that go through Notified Body review. In practice, both frameworks apply at once and share one integrated technical file — teams that treated the AI Act as a later problem now risk documentation gaps exactly as Notified Bodies start assessing it. If your product is a SaaS-delivered AI tool as well as a device, our EU AI Act compliance checklist covers the general obligations.

Risk management and cybersecurity

Risk management and cybersecurity are regulatory requirements for medical device software, not optional hardening — and since 2023 the FDA can refuse a submission that lacks them. Every hazard has to be identified, evaluated and controlled under ISO 14971, and each control has to trace back to a requirement and forward to a verification test. Security is now treated as a patient-safety issue: a vulnerability in a connected device is a hazard like any mechanical failure.

• Risk management (ISO 14971): a living risk file that runs the whole lifecycle, linking hazards to controls and to residual-risk acceptability.
• Premarket cybersecurity: under FD&C Act section 524B, US submissions must include a threat model, a Software Bill of Materials (SBOM) for all third-party and open-source components, and a plan to monitor and patch vulnerabilities.
• Secure lifecycle (IEC 81001-5-1): the health-software security process standard that pairs with IEC 62304 for secure design, coding and updates.
• Post-market vigilance: coordinated vulnerability disclosure, field monitoring and a tested update path, because the device must stay secure for its entire service life.

The through-line is that safety, security and quality are one system, not three departments. A connected device that streams data to the cloud inherits the security posture of that whole path, which is why standing up hardened, auditable infrastructure is core Cloud & DevOps work rather than an afterthought.

How much does medical device software development cost in 2026?

In 2026, medical device software development ranges from about $80,000 for a low-risk SaMD to $700,000 or more for Class C device software with a full regulatory submission — driven far more by safety class and regulatory surface than by feature count. The ranges below reflect delivery-complete builds by an experienced, quality-system-compliant team, not a prototype that mocks the regulated parts.

These are blended engagements including risk management, verification, documentation and QA. For how build cost works across software generally, see our custom software development cost guide for 2026.

Where the budget actually goes

• Quality system & documentation (25–40%): design controls, the risk file, verification evidence and the regulatory submission — the largest hidden cost.
• Verification & validation (20–30%): traceable testing at unit, integration and system level, plus human-factors validation.
• Cybersecurity (10–20%): threat modeling, SBOM, penetration testing and a maintained patch path.
• The application itself (25–35%): the clinical or device workflow on top of the compliant foundation.

Budget separately for the post-market phase: ongoing surveillance, security patching and change control typically run 15–20% of the build cost per year after launch.

Best practices for a compliant medical device software build

The teams that ship on time treat compliance as an engineering practice, not a documentation exercise bolted on at the end. Five habits separate a smooth clearance from a stalled one.

1. Fix the intended use and class first. The clinical claim decides the device class, the standards and the budget; confirm it with an FDA pre-submission or a Notified Body before choosing an architecture.
2. Stand up the quality system before feature code. Design controls, risk management and traceability are cheap to build in and expensive to retrofit — an ISO 13485 QMS is the foundation, not the finish.
3. Make traceability automatic. Link requirement → risk control → code → test in tooling, so the design history file is a by-product of the work, not a month of pre-audit archaeology.
4. Design security and updates in. Threat-model early, generate an SBOM, and build a signed, tested update path — the device has to stay secure for its whole service life.
5. Plan AI changes with a PCCP. If the device learns, pre-authorize the model-update envelope so you can iterate without a new submission each time.

General software competence is necessary but not sufficient here; the differentiator is a partner who has cleared regulated device software before. The compliance foundation and the integration work are core backend and cloud engineering — the same discipline behind our wider custom software development practice, extended for regulated medical data. A patient-facing companion app is also a serious mobile app development effort in its own right.

FAQ

What is medical device software development?

Medical device software development is the design, engineering and validation of software that is itself a medical device (Software as a Medical Device) or that runs inside one (embedded device software), built under a regulated quality system. Because the software can affect patient safety, it is developed to IEC 62304 for the lifecycle, ISO 14971 for risk management and ISO 13485 for quality, and it must clear FDA or EU MDR authorization before launch. The regulated lifecycle and documentation, not the feature code, are the hard part.

What is Software as a Medical Device (SaMD)?

Software as a Medical Device (SaMD) is software intended for a medical purpose that performs that purpose without being part of a hardware device — for example an app that analyzes images to detect disease. It contrasts with software in a medical device (SiMD), the embedded firmware inside a pump or monitor. Both are regulated, but SaMD is classified on its own by the risk of the decision it drives, following the IMDRF framework the FDA and EU use.

What regulations apply to medical device software in 2026?

In the US, the FDA regulates it under the FD&C Act, usually via a 510(k) or De Novo pathway, with IEC 62304, ISO 14971 and premarket cybersecurity (including an SBOM under section 524B) as the core standards. In the EU it falls under the Medical Device Regulation (EU MDR 2017/745) and needs a CE mark via a Notified Body for most classes; if it uses AI it is also a high-risk system under the EU AI Act. ISO 13485 quality management underpins both markets.

How does IEC 62304 classify medical device software?

IEC 62304 assigns each software item a safety class by worst-case harm: Class A (no injury possible), Class B (non-serious injury possible) and Class C (death or serious injury possible). The class sets how much of the standard's lifecycle — architecture, detailed design, unit verification and traceability — you must document. Edition 2, targeted for August 2026, streamlines these classes and adds explicit clauses for AI and machine-learning software.

How much does medical device software development cost in 2026?

A low-risk (Class A) SaMD build typically runs $80k–$150k, a Class B diagnostic-support product with integrations $150k–$350k, and a Class C, life-supporting device software program with a full submission $350k–$700k or more. Regulatory documentation and a compliant quality system add $30k–$80k, and each connected-device or EHR integration adds $20k–$50k, so the safety class and regulatory surface drive the budget more than feature count.

How is AI in medical devices regulated in 2026?

In the US, the FDA regulates AI/ML device software under its existing pathways and lets manufacturers pre-authorize model updates through a Predetermined Change Control Plan (PCCP), finalized in December 2024, alongside Good Machine Learning Practice. In the EU, AI in an MDR class IIa/IIb/III device is automatically high-risk under the EU AI Act, adding data-governance, transparency and human-oversight duties on top of MDR; its medical-device provisions began applying in August 2026, with August 2027 for higher-risk CE-marked devices under Notified Body review.

Last updated 18 July 2026. Cost and timeline ranges reflect delivery-complete builds for US and EU MedTech clients and will vary by device class, markets, integrations and regulatory pathway. Regulatory references — including IEC 62304 Edition 2 and the EU AI Act timelines — are general guidance, not legal advice; consult qualified regulatory counsel, your Notified Body and the FDA for current requirements. Request a scoped proposal for your specific device.