Software as a Medical Device (SaMD) development is the engineering of software intended to perform medical purposes — diagnosis, treatment, monitoring, prediction — without being part of a hardware medical device.
SaMD development is governed by three core international standards: IEC 62304 (software lifecycle processes), ISO 13485 (quality management system), and ISO 14971 (risk management). In the United States, SaMD also follows FDA design controls under 21 CFR Part 820 and one of three premarket pathways: 510(k), De Novo, or Premarket Approval.
This guide covers the development methodologies that work best for SaMD, the standards that govern it, the FDA pathway, and how Sequenex applies them in practice.
If you’re still working out whether your product qualifies as SaMD in the first place, start with our guide to SaMD, which covers the IMDRF definition, examples across diabetes care and other areas, and the four SaMD risk classes.
How SaMD Development Differs from Hardware Development
SaMD development requires a fundamentally different approach than hardware development. Where hardware design typically follows a waterfall sequence — locked requirements, sequential build, then validation — software benefits from iterative cycles that surface defects early, accommodate the rapid evolution of clinical evidence and platform APIs, and align with regulatory expectations that increasingly recognize iterative software practices.
Agile vs Waterfall
Agile methodology is the dominant SaMD development approach, while waterfall remains common in hardware medical device development. The contrast matters because most regulatory standards were originally written assuming a waterfall approach — meaning that successful SaMD teams need to apply Agile practices in ways that satisfy the documentation and traceability requirements those standards demand.
In this process, one step must be completed before the next can begin. This approach works well to build physical devices but is not optimized for software development.
In SaMD development, Agile methodology is the preferred approach. This circular process allows for constant testing, reviewing, and refining of software. With each pass, bugs are removed to avoid the compounding of issues as new layers are added. An iterative methodology, Agile lends itself incredibly well to SaMD development, including both standalone software products and those that must work directly with hardware.
Agile benefits both developers and customers. For the developer, this iterative approach provides better control, reduces risk, increases flexibility, and enables continuous improvement, resulting in a final product in less time, for less money, and with less risk. For the customer, Agile delivers a superior-quality product that is highly adaptable both during development and after the final product is created. This is key in the medical technology market, as regulations are constantly shifting and technology is advancing rapidly.
Component Architecture
Component architecture is the dominant pattern in modern SaMD development — a framework where software is built from independent, modular components that communicate to form a complete system but can be replaced, repurposed, or rebuilt without affecting the others. For SaMD that needs to interoperate with multiple medical devices, component architecture makes the software flexible across product configurations and adaptable as the device ecosystem evolves.
In SaMD development for software that is meant to work with different medical device products, both hardware and software, this approach allows for broader uses. You can easily build your software with certain products in mind and add or remove devices as the market evolves. And do it all without rebuilding your software from scratch.
Component architecture keeps your product fluid throughout the development process and beyond market launch. Bugs, regulatory changes, and updates to associated software and devices can all be easily accommodated with minimal time and financial investment. Given how quickly the medical technology landscape is changing, component architecture is the only viable approach to SaMD development.
Software Development Kits
A Software Development Kit (SDK) is the integration layer that lets SaMD connect to other medical devices, third-party apps, and partner platforms. Most SaMD products do not work in isolation — they read data from biosensors, write data to clinician dashboards, or expose functionality to companion device apps. The SDK is what makes those integrations practical.
Very few SaMD products work in a vacuum. Most are designed to connect to other medical devices in some form. As the biometric landscape continues to evolve, we will only discover more ways to track health through physical and behavioral sensors and data-tracking applications. Each of these products will require software to interpret the data gathered. The best products will be able to integrate multiple devices to provide the most useful data to the end user.
To ensure your product is ready for this degree of interoperability, partner enablement, and scalability, you need to create a highly useful software development kit (SDK). Your SDK enables other companies to integrate your product into their platforms or devices. Likewise, if you want to add functionality to your SaMD using new devices or software, you’ll rely on the SDKs provided by these other companies.
SaMD Regulation and Global Standards
SaMD regulation is harmonized internationally around three standards: ISO 13485 (quality management), ISO 14971 (risk management), and IEC 62304 (software lifecycle). Most national regulators — the FDA, EU Medical Device Regulation (MDR), Health Canada, Japan’s PMDA, Australia’s TGA — recognize these standards as the baseline for SaMD compliance. Building SaMD to all three typically satisfies the foundational requirements of multiple jurisdictions, reducing duplicate regulatory effort.
ISO 13485
ISO 13485 is the international quality management system (QMS) standard for medical device manufacturers, including SaMD developers. Based on the same flow model as ISO 9001 but written specifically for the medical device industry, ISO 13485 establishes the prescriptive QMS processes that satisfy regulatory requirements while supporting the development of safe and effective medical software.
In the medical technology industry, a QMS is vital for meeting regulatory requirements and end-user needs. This standard exists to help med tech companies effectively deploy their own QMS tailored to their company’s framework, while still meeting external requirements and ensuring a safe end product.
ISO 14971
ISO 14971 is the international risk management standard for medical devices, including SaMD. The standard defines a framework for identifying hazards, evaluating risks, implementing risk controls, and monitoring control effectiveness across the entire device lifecycle — from concept through post-market surveillance. ISO 14971 is harmonized with the EU Medical Device Regulation (MDR), FDA design controls, and other major regulatory frameworks worldwide.
This standard helps software development companies reduce risk in many ways. It starts by identifying hazards associated with the medical device software. By assessing those hazards, it can help companies estimate and evaluate the risks associated with each. From there, the standard provides guidance for controlling those risks and monitoring the effectiveness of the applied controls.
IEC 62304 — Medical Device Software Lifecycle
IEC 62304 is the international standard for the medical device software lifecycle. The standard defines what activities must occur during planning, requirements, architecture, detailed design, implementation, integration, system testing, and release — and prescribes documentation requirements that scale with the software’s safety classification.
IEC 62304 defines three software safety classes based on the potential harm a software failure could cause:
- Class A — No injury or damage to health is possible from software failure.
- Class B — Non-serious injury is possible from software failure.
- Class C — Serious injury or death is possible from software failure.
The class drives the depth of documentation, the rigor of testing, the level of architectural decomposition, and the level of regulatory scrutiny. Class C software requires the most comprehensive documentation; Class A the lightest. Critically, IEC 62304‘s safety classes (A/B/C) differ from the IMDRF SaMD risk classes (I/II/III/IV) — a single SaMD product is classified under both schemes.
As a lifecycle standard, IEC 62304 applies from initial planning through post-market software maintenance. SaMD developed outside an IEC 62304-compliant process faces a much steeper path through any major regulatory submission.
International Harmonization
The IMDRF (International Medical Device Regulators Forum) coordinates regulatory harmonization across member jurisdictions, including the FDA, EU, Health Canada, Japan’s PMDA, Australia’s TGA, Brazil’s ANVISA, and others. IMDRF guidance on SaMD risk classification, clinical evaluation, and quality management has been adopted into the regulatory frameworks of most major markets.
For SaMD developers, this means a single development effort built to ISO 13485, ISO 14971, and IEC 62304 typically meets the foundational technical requirements of multiple jurisdictions. Local regulatory pathways and clinical evidence requirements still vary by market — but the core engineering and quality framework is shared across markets.
The FDA Pathway for SaMD
In the United States, SaMD enters the market through one of three FDA premarket pathways. The pathway depends on the SaMD’s risk class, whether a substantially equivalent predicate device exists, and the level of regulatory scrutiny required to assure safety and effectiveness.
Premarket Pathways (510(k), De Novo, PMA)
510(k) Premarket Notification — for SaMD substantially equivalent to a legally marketed predicate device. Requires demonstration of safety and effectiveness comparable to the predicate. Most moderate-risk SaMD enters the U.S. market through 510(k).
De Novo Classification — for novel low-to-moderate risk SaMD with no existing predicate. The De Novo pathway creates a new device classification rather than referencing an existing one. Often used for first-of-its-kind digital therapeutics and AI-based diagnostic tools.
Premarket Approval (PMA) — for high-risk SaMD where general and special controls are insufficient to assure safety and effectiveness. PMA is the most rigorous FDA pathway, typically requiring clinical trial data.
The FDA’s Digital Health Center of Excellence publishes SaMD-specific guidance, including the now-discontinued Software Precertification Program pilot and current guidance on clinical decision support software, AI/ML-based devices, and predetermined change control plans for SaMD updates.
However, NEX can accelerate the FDA’s medical device pathway.
FDA Cybersecurity Premarket Requirements
Since 2023, FDA premarket submissions for SaMD that address cybersecurity must include detailed cybersecurity documentation under section 524B of the Federal Food, Drug, and Cosmetic Act. Required content includes a Software Bill of Materials (SBOM), threat modeling, vulnerability assessment, and a plan for monitoring and addressing post-market vulnerabilities.
SaMD developers building under IEC 62304 within an ISO 13485 QMS already have most of the foundational artifacts needed for cybersecurity submissions — the remaining work is structuring those artifacts to the FDA’s specific format.
Frequently Asked Questions About SaMD Development & Regulation
What standards govern SaMD development?
SaMD development is governed by three international standards: ISO 13485 (quality management system), ISO 14971 (risk management), and IEC 62304 (software lifecycle processes). FDA-regulated SaMD also follows 21 CFR Part 820 design controls and applicable FDA premarket guidance, including cybersecurity premarket requirements. Sequenex builds all of these as standard.
What is the difference between IEC 62304 software classes and IMDRF SaMD classes?
There are two different classification schemes that both apply to a single SaMD product. IEC 62304 defines three software safety classes (A, B, C) based on the potential harm a software failure could cause. The IMDRF defines four SaMD risk classes (I, II, III, IV) based on the significance of the information the software provides and the seriousness of the patient’s healthcare situation. A single SaMD product is classified under both schemes.
Which FDA pathway does most SaMD use?
Most SaMD enter the U.S. market through a 510(k) premarket notification, which requires demonstrating substantial equivalence to a legally marketed predicate device. Novel low-to-moderate risk SaMD with no predicate uses the De Novo classification pathway. High-risk SaMD requiring clinical trial data uses Premarket Approval (PMA).
Can SaMD be developed using Agile methodology?
Yes. Agile is the dominant SaMD development methodology and is recognized by major regulators. The challenge is that most regulatory standards were written assuming waterfall flow, so Agile SaMD teams need to satisfy the documentation and traceability requirements that those standards demand within an iterative process. The solution is typically a hybrid: Agile sprint cycles for the engineering work, with regulatory artifacts (requirements, risk files, V&V records) maintained as living documents updated each sprint.
What FDA cybersecurity requirements apply to SaMD?
Since 2023, SaMD submissions to the FDA that address cybersecurity must include a Software Bill of Materials (SBOM), threat modeling, a vulnerability assessment, and a post-market vulnerability monitoring plan, as required by section 524B of the FD&C Act. The FDA also publishes detailed cybersecurity premarket guidance on what constitutes a sufficient submission.
How long does SaMD development typically take?
SaMD development timelines depend heavily on risk class, regulatory pathway, and whether the team is building from scratch or working from a regulated software foundation. A Class B/IMDRF II SaMD on the 510(k) pathway typically takes 12–18 months from concept to clearance for a team starting fresh; teams using a prebuilt foundation like the Sequenex NEX Platform often cut that by several months by inheriting the IEC 62304 and ISO 13485 groundwork.
Build SaMD With a Partner Who Knows the Path
SaMD development is what Sequenex does every day. Every project is engineered under IEC 62304 within our ISO 13485-certified QMS, with ISO 14971 risk management running in parallel and DHF-ready documentation produced as the engineering work happens — not assembled at submission. Our team has decades of experience across diabetes care, biosensors, CGM, and connected medical devices.
Whether you’re navigating your first SaMD submission or shipping a new release of an existing product, we can help — from regulatory strategy through development to FDA pathway execution.
