4 best medical device software resources for 2026

You built a feature that estimates a dosage, flags an anomaly, or triages a symptom. Now someone on the team asks the question that stops the roadmap cold: "Is this a regulated medical device?"

Most product managers hit this wall the same way. The question starts vague. Then it splinters into classification, intended use, validation evidence, cybersecurity, and postmarket update discipline. Each branch pulls in a different standard, a different regulator, and a different stakeholder. The FDA defines software as a medical device (SaMD) as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. That single definition determines whether your release process needs traceability, whether a UI change needs change control, and whether a bug is a defect or a reportable event.

The stakes are real and growing. The software as a medical device market is projected to reach USD 5.24 billion in 2026 and USD 25.87 billion by 2031, a 37.62% CAGR, according to Mordor Intelligence (2026). More products mean more scrutiny, and more teams learning classification the expensive way, after they have shipped.

This is not a tooling problem you solve by buying something. It is a comprehension problem you solve by reading the right sources in the right order. So instead of one more glossary dump, here are the four resources worth your time, ranked by how quickly they answer the question a product manager actually has.

What's inside

This guide curates the most useful official and educational resources for understanding medical device software in 2026, written for product managers and regulatory-adjacent product leaders rather than full-time regulatory staff. We selected each source on four criteria: authority (who publishes it and whether regulators recognize it), depth (how far it goes past the definition), clarity (whether a non-specialist can act on it), and coverage of both regulation and the software lifecycle. The result is a short reading path, not an encyclopedia. Each entry tells you what the source does well, where it stops, and when to open it first.

TL;DR

• Best for the official definition: The FDA is the baseline reference. Start here for the formal SaMD language regulators use and the broader device software taxonomy.
• Best for operational depth: Greenlight Guru is the densest educational guide in this set, covering classification, lifecycle, validation, cybersecurity, SOUP, SBOM, and change control.
• Best for development and compliance workflow: PTC ties software standards, validation, and cybersecurity together for cross-functional engineering and quality teams.
• Best for strategic context: Orthogonal frames how SaMD fits into modern digital health, with examples and a clear "why now" view.
• Read them in order: FDA for the definition, Greenlight Guru for the operational picture, then PTC or Orthogonal for implementation and category context.

What medical device software actually is

Medical device software is software intended for a medical purpose, and that intent is what triggers regulation, not the code, the platform, or the deployment model. If your software diagnoses, treats, prevents, monitors, or predicts, it is likely regulated. If it only supports administration, scheduling, or general wellness, it usually is not.

Two terms anchor the whole field, and product managers confuse them constantly:

• Software as a medical device (SaMD): Standalone software that performs a medical purpose without being part of a hardware device. A phone app that analyzes retinal images is SaMD.
• Software in a medical device (SiMD): Software embedded in and running a hardware device, like the firmware controlling an infusion pump. SaMD vs SiMD is a classification question, and getting it wrong reshapes your entire compliance obligation.

Here is what a product team needs to internalize before touching a roadmap:

• Intended use is the first filter. The IMDRF SaMD framework and FDA both classify based on the medical purpose you claim, not the technology you built.
• Scope depends on market. FDA in the United States, EU MDR in Europe, and IMDRF as the international harmonizing body are not interchangeable, and EU MDR Rule 11 can classify software into higher risk classes than teams expect.
• Lifecycle evidence matters as much as the feature. IEC 62304 governs the software lifecycle, ISO 14971 governs risk management, and ISO 13485 governs the quality system. Regulators want proof you followed a process, not just a working product.
• Cybersecurity is patient safety. A vulnerability in medical device software is not just an IT issue, it is a safety issue, which is why an SBOM and vulnerability response now sit inside the release process.

Ground the term the way regulators do and the rest of the decisions get easier. The FDA and IMDRF language exists precisely so teams across markets can talk about the same product with the same words.

When to use this guide

Different questions need different starting points. Match your situation to the right source before you read.

If you need the official definition

Start with FDA terminology when someone needs the formal language, whether that is a founder writing an investor deck, a PM writing a PRD, or a lawyer reviewing a claim. The FDA's SaMD and digital health pages give you the exact wording regulators use, so your internal documents match the framework you will be assessed against. This is the source you cite, not the source you brainstorm from.

If you need to classify your software

Prioritize classification crosswalks, EU MDR Rule 11, and IMDRF framing when the core question is "what risk class is this, and in which market?" Classification drives everything downstream: the evidence you need, the review pathway, and the timeline. Read the IMDRF risk categorization framework alongside the specific market rules, because a product that is low-risk under one regime can be higher-risk under another.

If you need development and compliance depth

Go deep on lifecycle standards when your team is actually building. IEC 62304 for the software lifecycle, ISO 14971 for risk management, ISO 13485 for the quality system, plus cybersecurity and postmarket change control, are where roadmaps meet reality. This is the moment to read operational guides that show how the standards connect, not just what each one says in isolation.

Comparison table

Ranked by how directly each resource answers a product manager's first question about medical device software.

The 4 best medical device software resources

1. FDA

The FDA is the U.S. federal agency that regulates food, drugs, medical devices, biologics, and related products, and it is the primary source for the formal definition of software as a medical device. When you need to know what regulators mean by a term, you go to the regulator, not to a summary of the regulator. The FDA's digital health and SaMD pages define the taxonomy, explain device software functions, and lay out the pathways a product may follow.

Best for: Product and regulatory teams that need the authoritative definition and official terminology before making any classification or roadmap decision.

Key strengths

• Primary authority: This is the language every other resource quotes, so it removes ambiguity about what a term actually means.
• Taxonomy clarity: Clear framing of SaMD, device software functions, and the boundary with non-device software.
• Guidance library: Access to FDA guidance documents on cybersecurity, clinical evaluation, and premarket submissions.

Why choose the FDA: No secondary source outranks the regulator on definitions. When a classification decision, a claim, or a submission is on the line, you want the exact FDA wording in front of you. The tradeoff is scope: the FDA tells you what the rules are, not how to operationalize them across a sprint cadence or a quality system. It is the reference you bookmark and return to, not the guide that walks you through implementation.

The FDA is a government agency, so there is no product pricing, subscription, or rating to evaluate. Certain regulated submissions carry user fees described on the FDA's industry pages, but access to guidance and definitions is free and public. Keep the SaMD and digital health pages bookmarked for every product team touching a medical purpose.

2. Greenlight Guru

Greenlight Guru is a medtech software platform for quality management, product development, and clinical evidence, and its educational content is the most operationally dense in this set. Where the FDA defines the terms, Greenlight Guru explains how the terms play out across a real product lifecycle. Its SaMD explainer covers classification, IEC 62304 lifecycle activities, software validation, cybersecurity, SOUP, SBOM, and change control in one connected read.

Best for: Product managers and quality leads who need the full compliance picture, not just the definition, and want it in language a non-specialist can act on.

Key strengths

• Lifecycle depth: Connects IEC 62304, ISO 14971, and ISO 13485 into a single, coherent workflow rather than treating each as an island.
• Practical guidance: Explains validation, traceability, SOUP, and SBOM in terms of what a team actually produces and maintains.
• Change control focus: Treats postmarket updates and change control as first-class concerns, which is exactly where software teams get tripped up.

Why choose Greenlight Guru: This is the resource for the product manager who already knows the definition and now needs the operational map. It rated 4.4 out of 5 on G2, and its content reflects a platform built specifically for medical device companies. If your next question after "is this regulated?" is "what do we actually have to do, and in what order?", this is where you go.

Greenlight Guru's public pricing pages show plan names such as Core, Essentials, Plus, and Professional along with feature bundles, but numeric prices are quote-based and require a sales conversation. The educational content itself is freely readable and worth the time even if you never evaluate the platform.

3. PTC

PTC is an industrial software company offering CAD, PLM, IoT, and service management tools, and its medical device software content leans into the development and compliance workflow. The angle here is practical and cross-functional: how software standards, validation, and cybersecurity fit together inside a product development process that engineering and quality both own. For teams that live at the intersection of software, hardware, and lifecycle management, PTC's framing maps neatly onto how the work actually gets divided.

Best for: Product and engineering teams that want a concrete explanation of how development standards, validation, and cybersecurity connect inside a real build process.

Key strengths

• Workflow orientation: Frames compliance as part of product development rather than a separate regulatory chore bolted on at the end.
• Cross-functional lens: Speaks to engineering, quality, and product together, which reflects how medical device software actually ships.
• Lifecycle tooling context: Connects standards and cybersecurity to the product lifecycle management and traceability work teams already do.

Why choose PTC: If your organization treats software as part of a broader connected product, and validation and traceability sit inside a lifecycle management practice, PTC's framing will feel native. It rated 4.4 out of 5 on G2. The content is strongest when you want the "how the pieces fit" view rather than the raw regulatory definition, which makes it a good third read after you have the definition and the compliance map.

PTC's pricing varies by product. Some offerings in the PTC store show public prices, others are sold à la carte or quote-based, and free trials exist for certain products such as Kepware. There is no single company-wide price, so treat pricing as product-specific if you evaluate the platform. The educational content is publicly accessible.

4. Orthogonal

Orthogonal is a medical device software company focused on SaMD and connected devices, and its educational content provides the strategic and category context the other sources leave out. Where the FDA gives you rules and Greenlight Guru gives you process, Orthogonal explains why the regulatory landscape looks the way it does in 2026, and where it is heading. Its content covers the evolution of SaMD, real development examples, and future-facing concepts like predetermined change control plans and AI/ML medical device software.

Best for: Product leaders and founders who want the "why now" view and need to understand how SaMD fits into modern digital health before committing to a direction.

Key strengths

• Category evolution: Explains how SaMD emerged and why lifecycle thinking became central to modern digital health.
• Real examples: Grounds abstract regulatory concepts in how connected devices, mobile apps, and machine learning products actually get built.
• Future-facing coverage: Surfaces AI/ML and predetermined change control plans, which matter for any roadmap that touches adaptive software.

Why choose Orthogonal: This is the companion read for the strategic conversation, not the compliance checklist. When a founder asks "should we even be in this category?" or a PM is scoping an AI/ML feature and wants to understand where regulation is trending, Orthogonal's perspective helps. It comes from a firm that builds these products, so the framing is grounded in delivery rather than theory.

Orthogonal is a services firm, so there is no public product pricing or subscription to evaluate. Its educational content is freely available and pairs well with the more operational guides when you want the broader context around a specific decision.

Considerations before you classify or build

The four resources tell you what to read. These principles tell you how to think while you read them.

Verify intended use before classifying

Intended use is the first filter, and it is a claim, not a guess. Write down, in plain language, the medical purpose your software performs and the population it serves. That statement drives classification under both FDA and EU rules, so document it deliberately and keep it consistent across your PRD, marketing, and regulatory filings. A mismatch between what marketing claims and what the filing says is how teams accidentally expand their own regulatory obligation.

Separate SaMD from SiMD clearly

The SaMD vs SiMD boundary changes the classification question entirely. If your software is embedded in and controls a hardware device, it is SiMD and inherits the device's regulatory context. If it stands alone and performs a medical purpose on its own, it is SaMD and gets assessed on its own terms. Decide this early, because the two paths pull in different standards and different evidence.

Map regulation by market

FDA, EU MDR, and IMDRF are not interchangeable. A product cleared in the United States is not automatically compliant in Europe, and EU MDR Rule 11 in particular can place software into a higher risk class than a team expects. Build a market-specific lens from day one, and use IMDRF framing as the common vocabulary that connects the two regimes rather than assuming one covers the other.

Build validation and traceability early

Regulators want evidence, not just a working product. IEC 62304 expects a documented software lifecycle, ISO 14971 expects documented risk management, and both expect traceability from requirement to test. For a PM, that me[ans treating validation artifacts as part of the definition of done, not paperwork you generate at the end. Retrofitting traceability after the fact is the single most expensive mistake in medical device software development.

Treat cybersecurity as a release discipline

Cybersecurity for medical devices belongs inside the release process, not in a separate security review that happens once a year. An SBOM documenting your software bill of materials](https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom), SOUP management, threat modeling, and a vulnerability response plan should be part of how you ship every version. Because security is patient safety in this domain, change control has to account for security patches the same way it accounts for functional changes.

Conclusion

Four resources, four jobs. Start with the FDA when you need the official definition and the formal SaMD language, because that is the vocabulary you will be assessed against. Move to Greenlight Guru for the operational depth: classification, lifecycle, validation, cybersecurity, and change control in one connected read. Then reach for PTC when you want to see how the standards fit inside a real development workflow, or Orthogonal when you want the strategic, category-level view and a sense of where AI/ML regulation is heading.

The practical next step is the same regardless of which source you open first. Write down your intended use in plain language. Identify the market or markets you will pursue and classify against each one. Then map the evidence each standard requires, from IEC 62304 lifecycle documentation to ISO 14971 risk files, and build that traceability into your process before you write production code. Do that early, and medical device software stops being a wall your roadmap hits and becomes a discipline your team runs on purpose.

FAQs