Medical Device Software Development: 2026 Guide for Founders
Key Takeaways
- Classification decides everything. SaMD vs. SiMD vs. wellness drives pathway, standards, budget, and timeline. Get it wrong, and you rebuild.
- You comply with the whole stack. IEC 62304 (SDLC), ISO 13485 (QMS), ISO 14971 (risk), Section 524B (cybersecurity), not a menu.
- Cybersecurity is now a submission requirement. Since March 2023, the FDA can refuse submissions missing an SBOM, threat model, or vulnerability plan.
- AI/ML devices can iterate post-market if you designed the PCCP in. Otherwise, every model change triggers a new clearance.
- Realistic cost: $250K (Class A MVP) to $2M+ (Class C with 510(k) and clinical validation). Quotes below the floor are skipping something.
In 2026, developing medical device software without a regulatory plan is no longer a risk you can manage. Instead, it’s a decision that writes off your runway. Section 524B now makes cybersecurity a refuse-to-accept trigger at submission. The PCCP framework for AI devices has been finalized. The QMSR took effect in February 2026, replacing 21 CFR Part 820.
None of this makes building medical device software impossible. It makes building it chaotically impossible.
If you are a founder, product leader, or engineering head scoping a first medical device software build or working on one that’s already in trouble, this guide is for you. It covers what qualifies as a medical device, which FDA pathway applies, what the development lifecycle really looks like under IEC 62304 and ISO 13485, and what the whole thing costs in realistic 2026 dollars.
What Counts as Medical Device Software in 2026?
Before you pick a tech stack or write a line of code, try to answer one question. Is your software regulated by the FDA?
The FDA uses three buckets:
| Category | Definition | Examples | FDA Oversight |
|---|---|---|---|
| SaMD | Performs a medical function on its own, independent of hardware | AI radiology triage, glucose prediction apps, clinical decision support | Regulated |
| SiMD | Firmware/embedded software inside a physical device | Infusion pump control, pacemaker firmware, CT scanner software | Regulated with the device |
| General Wellness | Low-risk, no medical claims, no clinical decisions | Step counters, stress trackers, nutrition loggers | Not regulated, but marketing claims matter |
The trap is marketing a wellness app with medical-device language. An AI nutrition app that “detects Type 2 diabetes risk” is an unapproved SaMD. As per the FDA’s 2024 CDS enforcement policy, if your software drives a clinical decision that the user can’t reasonably override, it is a medical device.
To get a deeper classification logic, our how to build regulatory-compliant healthcare apps guide helps you through each decision point.
The IMDRF SaMD Risk Framework
The IMDRF framework (adopted by the FDA) classifies SaMD by two factors:
- Information significance — inform, drive, or treat/diagnose
- Healthcare situation — non-serious, serious, or critical
The matrix runs from Class I (lowest) to Class IV (highest). An app informing a clinician of a non-serious condition is Class I. An ICU sepsis alert AI driving treatment decisions is Class IV. Your IMDRF class maps to the IEC 62304 safety class (A/B/C), which sets SDLC rigor.
FDA Classification and 510(k) Pathways for Medical Device Software
FDA device classification is separate from SaMD risk classification. Yes, it is confusing, but on purpose.
| FDA Class | Risk | Pathway | Examples |
|---|---|---|---|
| Class I | Low | 510(k) exempt (mostly) | Basic logging apps with medical claims |
| Class II | Moderate | 510(k) or De Novo | Most SaMD, glucose monitors, RPM platforms |
| Class III | High | PMA | Life-sustaining devices, implantable firmware |
- 510(k): Demonstrate “substantial equivalence” to a predicate. 3–9 months review. Submission prep: $50K–$250K. FY2026 user fee ~$24,335 (lower for small business).
- De Novo: For novel low/moderate-risk devices with no predicate. 9–12 months review. Most AI/ML devices take this route.
- PMA: Class III only. Clinical trials, 1–3 years, $1M+ regulatory alone.
Most startups build a target Class II via 510(k) or De Novo. If your guess is PMA, it is out of scope for this guide.
Let's Start Your Project Today
Ready to get your Medical Device Software Development with us? Reach out now – our experts are just one click away.
Medical Device Software Regulatory Stack: IEC 62304, ISO 13485, QMSR, and Section 524B
FDA compliance isn’t one thing, but it’s a stack of interlocking standards:
| Standard / Rule | What It Governs |
|---|---|
| IEC 62304 | Software lifecycle: design, code, verify, maintain |
| ISO 13485 | Organization-level Quality Management System |
| ISO 14971 | Risk management across the product lifecycle |
| 21 CFR Part 820 / QMSR | FDA’s QMS rule (harmonized with ISO 13485 Feb 2026) |
| FDA Section 524B | Cybersecurity at submission: SBOM, threat model, vuln plan |
| IEC 62366 | Human factors, use-error analysis |
| HIPAA Security Rule | PHI protection for US devices handling patient data |
| EU MDR 2017/745 | Required if selling in EU; overlaps IEC 62304/ISO 13485 |
GDPR, SOC 2, and HITRUST stack on top, and they don’t replace this.
Your QMS has to exist as real procedures and audit trails before production code. Founders who skip QMS setup to “save time” lose 6–12 months retrofitting it for submission. The innovation-vs-compliance tradeoff is too sharp at scale.
2026 Medical Device Regulatory Change Timeline
There have been more changes in the past three years than in the entire decade prior. If your plan is based on pre-2023 assumptions, it is outdated.
| Date | Change | What It Means for Your Build |
|---|---|---|
| March 2023 | FDA Section 524B takes effect (Omnibus Appropriations Act) | Cybersecurity documentation is a refuse-to-accept (RTA) trigger. SBOM, threat model, and vulnerability plan required at submission. |
| September 2023 | FDA finalizes premarket cybersecurity guidance | Operationalizes Section 524B, what a compliant submission actually contains. |
| December 2024 | FDA finalizes PCCP guidance for AI/ML devices | You can pre-specify model updates in the original submission and iterate post-market without new clearance. |
| January 2025 | FDA draft guidance: AI-Enabled Device Lifecycle Management | Formal expectations for bias evaluation, training data provenance, and post-market monitoring for AI devices. |
| February 2, 2026 | Quality Management System Regulation (QMSR) takes effect | 21 CFR Part 820 harmonizes with ISO 13485. Existing Part 820 QMS must be updated to QMSR. |
| May 2026 | EU MDR full compliance deadline for most Class IIb/III legacy devices | If you’re selling in the EU, the grace period ends; notified body certification is required. |
| H2 2026 (expected) | DEA permanent telehealth controlled substance rules | Relevant if your device touches e-prescribing for Schedule II–V drugs. |
| December 31, 2026 | DEA telehealth flexibilities are currently scheduled to expire | Plan for stricter in-person evaluation requirements unless extended. |
Earlier, things were a bit more flexible, but since 2023, just saying ‘we’ll document it later’ no longer works. Now, for every major control, whether it’s cybersecurity, AI lifecycle, or QMS, you need to be able to show it’s in place from day one.
The Medical Device Software Development Process (IEC 62304 Lifecycle)
IEC 62304 decides what must happen, not how. You can be agile. Mature teams run a hybrid model, agile sprints inside waterfall milestone gates. Here’s the phase breakdown and what founders typically miss:
1. Planning and Software Development Plan (SDP)
The SDP defines safety classification, lifecycle model, tools, configuration management, and verification strategy. It’s the answer when an auditor asks “how did you build this?”
The common miss is treating the SDP as a one-time doc, not a living artifact.
2. Software Requirements Specification (SRS)
Every function, interface, safety, performance, and regulatory requirement captured with a unique ID is traceable forward to code and verification, backward to the risk analysis.
The common mistake is product feature requirements instead of atomic verifiable ones. “Display glucose readings” isn’t a requirement. “Display the most recent CGM reading within 3 seconds, with a visual alert if above user threshold” is.
3. Software Architecture and Design
Modular decomposition, safety critical code segregation, and SOUP (Software of Unknown Provenance) identification. Every React Native dependency, every AWS service is a SOUP item that requires documented risk assessment.
The common miss is underestimating SOUP documentation. Every dependency, every version, every CVE check.
4. Implementation, Integration, and Testing
Coding standards enforced, code reviews documented, unit and integration tests linked to requirements. Every commit traceable to a requirement or defect. Failed tests produce deviation reports that feed the risk file.
The common miss is treating code reviews and test runs as dev practices rather than compliance artifacts. No documented evidence translates to it didn’t happen.
5. Release and Post-Market Surveillance
Release is a formal, version controlled sign-off and not a deploy. Post market covers complaint handling, vigilance reporting, and change controlled updates. If a defect poses a safety risk, a Medical Device Report (MDR) may be required within 30 days.
The common miss is assuming the post-market is the compliance team’s problem. It’s important to understand that engineering owns the surveillance pipeline.
For how this maps to a real build, building an IEC 62304-compliant mobile medical app walks through each artifact in detail.
Agile Medical Device Software Development: Is It Compatible with IEC 62304?
Yes, it is compatible, although it requires discipline. AAMI TIR45 maps agile to IEC 62304. What changes is that every sprint produces verification artifacts, the Definition of Done (DoD) includes traceability and risk file updates, user stories become verification test cases, and retrospectives feed the CAPA system. That’s how agile works, but pure Scrum “by the book” does not.
Let's Start Your Project Today
Ready to get your Medical Device Software Development with us? Reach out now – our experts are just one click away.
AI and Machine Learning in Medical Device Software Development
The FDA has authorized 1,000-plus AI/ML-enabled medical devices as of late 2025, and the Predetermined Change Control Plan (PCCP) is the centerpiece.
With a PCCP, you pre-specify intended model modifications and their validation protocol. Changes inside the envelope ship without new clearance; outside it, you need to resubmit. A PCCP contains: (1) Description of Modifications, (2) Modification Protocol (V&V for each change type), (3) Impact Assessment (benefit risk across the envelope). Designed in at submission means it’s an iterable product. Bolted on later will take 9 more months of review Beyond PCCP, AI-specific expectations now include:
- Bias evaluation across demographic subgroups is expected, not optional
- Training data provenance like documented source, consent basis, labeling protocol
- Post-deployment model monitoring is part of post-market surveillance
- Transparency where users and clinicians must understand intended use, limitations, and failure modes
For generative AI, our generative AI in healthcare development guide has the architecture and regulatory details.
Medical Device Cybersecurity Requirements Under FDA Section 524B
A “cyber device” under Section 524B is any device with sponsor-validated software that connects to the internet and has characteristics that could be exploited. It is like almost every modern medical device software product. Required in the submission:
| Requirement | What It Means |
|---|---|
| Secure Design Plan | How cybersecurity was considered across the SDLC and not retrofitted |
| Software Bill of Materials (SBOM) | Machine-readable list of every component, library, and dependency |
| Vulnerability Management Plan | How you’ll monitor, disclose, and remediate vulnerabilities post-market |
| Threat Model | STRIDE or equivalent, with mitigations mapped to identified threats |
| Cybersecurity Testing Evidence | Penetration testing, fuzz testing, static analysis results |
| Update and Patch Process | How you’ll deliver patches to fielded devices, including timing commitments |
The FDA’s September 2023 premarket cybersecurity guidance operationalizes these requirements which are now baseline and not premium. If your device also handles PHI, HIPAA Security Rule obligations layer on top, plus the 2024 NPRM proposing annual pen testing and 6-month vulnerability scans.
Medical Device Software Development Cost: Real 2026 Numbers
Quotes range from $80K to $3M for what sounds like the same scope. This is because cost tracks classification and pathway, not features.
| Build Type | IEC 62304 | Pathway | Cost Range | Timeline |
|---|---|---|---|---|
| Wellness app (non-medical positioning) | N/A | None | $80K–$180K | 4–7 mo |
| Class A SaMD MVP | A | 510(k) exempt | $150K–$350K | 7–10 mo |
| Class B SaMD | B | 510(k) | $350K–$750K | 10–14 mo |
| Class C SaMD | C | 510(k) / De Novo | $750K–$1.5M | 14–20 mo |
| SiMD (device firmware) | B/C | 510(k) / De Novo / PMA | $600K–$2M+ | 18–30 mo |
| AI/ML SaMD with PCCP | B/C | De Novo | $900K–$2M+ | 15–24 mo |
Ranges cover software and submission prep. Exclude clinical validation ($150K–$500K+ for Class B/C), FDA user fees, and EU notified body fees.
Cost drivers most quotes skip:
- QMS setup costs around $30K–$80K if starting from zero
- SOUP/dependency risk analysis tends to scale with third-party components
- Cybersecurity evidence such as pen testing, SBOM tooling, threat modeling
- Post-market surveillance infrastructure such as complaint handling, MDR reporting
- EU notified body fees cost around €25K–€150K depending on class
- Audit readiness such as internal audits, management review, CAPA cycles
For non-regulated healthcare builds, the healthcare app development cost breakdown makes the comparison, and the delta is almost entirely regulatory overhead.
Team Structure: Who Actually Builds Medical Device Software
A generic healthcare app team doesn’t deliver medical device software. The overlay roles that matter:
| Role | Owns |
|---|---|
| Regulatory Affairs Lead | Classification, pathway, submission, FDA interactions |
| Quality Manager | QMS operation, internal audits, CAPA |
| Clinical SME / Medical Advisor | Intended use, clinical workflow, risk scenarios |
| Software Architect (MedTech) | Safety classification, SOUP strategy, traceability design |
| Senior Software Engineers | Coding standards, unit tests, reviews |
| QA/Verification Engineer | Test planning, evidence capture, traceability |
| Cybersecurity Engineer | Threat modeling, SBOM, pen testing |
| Human Factors Engineer (IEC 62366) | Use-error analysis, usability studies |
| Technical Writer | SDP, SRS, SAD, risk file, submission docs |
Startups can’t afford all of the nine on day one. What works is having Regulatory Affairs and Quality Manager early, MedTech experienced engineering on the core team, Human Factors, and Cybersecurity contracted at milestone gates. What fails is rushing on a regulatory consultant six months into a non-compliant build.
Let's Start Your Project Today
Ready to get your Medical Device Software Development with us? Reach out now – our experts are just one click away.
Build In-House vs. Hiring a Medical Device Software Development Company
You are not just buying engineering. You are buying a QMS, a regulatory track record, and evidence auditors already recognize.
Build in-house if you have prior FDA clearances, a running QMS, and can staff full regulatory, quality, and engineering teams.
Partner, if it’s your first regulated product, you need submission under 18 months, your core team is clinical, or you want to stay focused on validation and GTM while engineering executes.
Screen partners on specific terms, such as whether they can share redacted sample documentation (SDP, risk file, verification protocol)? Can they name FDA submissions they’ve supported? Do they know your pathway (510(k) / De Novo / PMA)? Have they delivered Section 524B cybersecurity submissions? A vendor who can’t answer concretely is selling app development with extra marketing copy.
The build-vs-buy decision for healthcare startups covers the broader commercial math. For medical device software specifically, focus more on partnering earlier as compliance mistakes compound for the product’s life.
How Tech Exactly Delivers Medical Device Software Development Services
We’ve delivered healthcare software under HIPAA, HITRUST, and IEC 62304 across US and UK markets. What’s specific to our medical device work is the classification-first scoping before providing any quote, parallel QMS and engineering tracks. Additionally, we do documentation version-controlled alongside source, and cybersecurity is designed directly into the architecture and not just added on before submission.
If you’re scoping a build and want a second opinion on the classification path before you commit, we’ll take that conversation. No pitch needed. We just need a summary of what you’re actually building into.
Let's Start Your Project Today
Ready to get your Medical Device Software Development with us? Reach out now – our experts are just one click away.
FAQs
Only if you leave the general wellness boundary. Making medical claims or driving clinical decisions that the user can't override puts you in SaMD territory. See FDA general wellness guidance.
SaMD performs a medical function standalone (diagnostic app). SiMD is firmware in a physical device (infusion pump). Both are regulated, though SaMD is lighter on manufacturing controls.
10–14 months to submission and 3–9 months for FDA review. Class C or AI/ML via De Novo takes 15–24 and 9–12 months. Shorter quotes skip something.
Yes you can. Each becomes a SOUP item under IEC 62304, requiring version control, CVE monitoring, and documented risk assessment. IEC 62304 doesn't ban OSS; it bans undocumented OSS.
No, it doesn't. FDA and EU MDR are separate processes. IEC 62304 and ISO 14971 evidence carries across both, but submission packages and notified bodies differ.
State licensing and CPOM compliance. Federal rules get the headlines, but state medical board requirements determine where you can operate and how your corporate structure must work. A platform that's HIPAA-compliant but operates in California without proper MSO-PC separation is still a compliance violation waiting to happen.
