Medical Device Software Development: A Compliance Guide

Reviewed September 17, 2026

Building software for a medical device is different from building software for almost any other purpose, because the process itself, not just the finished product, is what regulators evaluate. A development team that writes clean, working code but cannot produce the requirements traceability, risk analysis, and verification records the FDA expects will still face delays or deficiencies at submission. This guide walks through the full lifecycle: design controls, the IEC 62304 process framework and its three safety classes, requirements and architecture, verification and validation, third-party component and SOUP management with SBOM, the interaction between software development and ISO 14971 risk management, secure coding as a design input, configuration management, and the documentation package a submission expects.

Why This Matters

A medical device software project that treats documentation as a paperwork exercise separate from engineering work will produce documentation that does not match what was actually built, and that mismatch is exactly what an FDA reviewer or an internal audit finds first. The FDA's Cybersecurity in Medical Devices final guidance, dated February 3, 2026, reinforces that cybersecurity and quality documentation are expected to be generated as a byproduct of the development process itself, not created retroactively to satisfy a checklist. Under the QMSR, which harmonizes FDA quality system requirements with ISO 13485, design controls remain the backbone of how a manufacturer demonstrates that software was developed under a controlled, traceable process. Many manufacturers that fail an FDA submission on software grounds do not fail because their code does not work. They fail because they cannot produce the traceability between requirements, risk controls, architecture, and test results that the review process is built to check.

What Do Design Controls Require Under the QMSR?

Design controls require a documented, traceable path connecting user needs, design inputs, design outputs, verification, and validation, and this structure moved largely intact from the former 21 CFR 820.30 into the QMSR's incorporation of ISO 13485 clause 7.3. Under the QMSR, many of the old Part 820 subparts are reserved, with their substance folded into the ISO 13485 structure, but 820.35 remains in force as a records requirement covering the design history file. This means the underlying expectation has not changed: a manufacturer needs to be able to show, item by item, that every design input traces to a verified output and that every output traces back to a documented input.

For software specifically, design controls apply at the system level and cascade down through the IEC 62304 process, so software requirements are a subset of the overall device's design inputs, and software verification and validation activities feed into the device-level design history file rather than existing as a separate, disconnected artifact.

What Does the IEC 62304 Lifecycle Require?

IEC 62304 defines the software development lifecycle processes a manufacturer must follow, including planning, requirements analysis, architectural design, detailed design, unit implementation and verification, integration and integration testing, system testing, and release, and the depth of each process scales with the software's safety classification. The standard assigns each software item one of three safety classes based on the severity of harm that could result from a software failure: Class A where no injury is possible, Class B where non-serious injury is possible, and Class C where death or serious injury is possible.

[KEY REQUIREMENT] Classify software safety class before finalizing architecture, not after. Retroactively discovering that a module needs Class C rigor after development is already underway typically means redoing unit test documentation, architecture rationale, and SOUP evaluation that Class A or B did not require.

A single product often contains software items at more than one class. A patient-facing dosing calculation module might be Class C while a logging or reporting module in the same product is Class A, and IEC 62304 permits this segmentation as long as the manufacturer can justify the boundaries between items and show that a lower-class item cannot compromise a higher-class one.

How Do Software Requirements and Architecture Fit Into the Process?

Software requirements translate the device's overall design inputs into specific, testable statements about what the software must do, and they need to be specific enough that a verification test can objectively confirm whether each one is met. Vague requirements, such as "the software shall be reliable," cannot be verified and will not survive a design review or an FDA reviewer's traceability check. Each requirement needs a unique identifier that can be traced forward to a verification test and, where applicable, back to a risk control measure from the risk management file.

Software architecture describes how the software is decomposed into items and units, and for Class B and C software, IEC 62304 expects the architecture to identify each software item's safety class, the interfaces between items, and how SOUP components fit into the overall structure. Architecture decisions made here, particularly around how a high-risk item is isolated from lower-risk or third-party code, directly affect how much testing and documentation the rest of the project requires.

What Verification and Validation Does the Software Need?

Verification confirms that each level of the software, from unit to integration to system, was built correctly against its own specification, while validation confirms that the finished software meets the actual clinical and user needs it was designed for, and a submission needs documented evidence of both, not just one. Unit verification checks individual functions or modules against their detailed design. Integration testing checks that units work correctly together and that interfaces behave as specified. System-level verification checks the complete software against its requirements, and validation, often performed at the device level rather than purely in software, checks the finished product against user needs in conditions that resemble actual use.

A common gap in verification and validation records is treating them as interchangeable, submitting test results that show the software does what its own specification says without ever demonstrating that the specification itself reflects what clinicians and patients actually need. For a deeper look at how verification and validation activities are structured and documented, see our related article, The Importance of Verification and Validation in Medical Device Software.

How Should SOUP and Third-Party Components Be Managed?

Software of Unknown Provenance, meaning any software item, library, or component not developed under the manufacturer's own IEC 62304 process, requires the same risk evaluation as internally written code, and IEC 62304 explicitly requires manufacturers to identify SOUP items, their versions, and the risks they introduce. This includes commercial libraries, open source components, operating systems, and third-party drivers, and the evaluation needs to consider known anomalies and vulnerabilities in the specific version being used, not just the component in general.

A software bill of materials, or SBOM, is the practical mechanism for tracking this across the software's life, and it needs to be maintained continuously rather than generated once at submission and then left static. As new vulnerabilities are disclosed in a SOUP component after release, the SBOM is what lets a manufacturer quickly determine which of its products are affected and prioritize a response.

How Does Software Development Interact With ISO 14971 Risk Management?

Software development and ISO 14971 risk management are not separate workstreams, because software hazards identified during risk analysis become inputs to software requirements, and software architecture decisions in turn affect what hazards exist and how severe they are. A risk control implemented in software, such as an input validation check that prevents an out-of-range dose entry, needs to be traceable both to the risk analysis that identified the hazard and to the verification test that confirms the control works as intended.

See also: CVSS Scoring for Medical Devices: A Complete Walkthrough, Healthcare Cybersecurity Companies: A Buyer's Selection Guide, and When to Start Medical Device Cybersecurity.

This bidirectional traceability, hazard to requirement to architecture to verification, and back again, is one of the most commonly cited gaps in FDA submissions, because it requires the software team and the risk management team to be working from the same documentation rather than reconciling two separate systems late in the project.

Why Should Security Requirements Be a Design Input, Not an Afterthought?

Security requirements belong in the design input phase because architecture decisions made without security in mind, such as how components authenticate to each other or how data is stored at rest, are expensive and sometimes impossible to fully correct after the architecture is locked. Secure coding practices, including input validation, memory-safe handling of external data, and least-privilege access between software items, need to be specified alongside functional requirements rather than treated as a separate security review that happens after functional development is complete.

For SaMD and connected devices that meet the FDA's cyber device definition under Section 524B, security-related design inputs also need to map to the threat model and risk assessment that will appear in the eSTAR submission's Cybersecurity attachment area. Building this traceability from the start avoids the common scenario where a security team is asked to retrofit documentation onto an architecture that was never designed with those controls in mind. Our related article, Secure Software Development for Medical Devices: Ensuring Safety and Compliance, covers how to build secure coding practices into each stage of the lifecycle.

What Configuration Management Does the Project Need?

Configuration management is what lets a manufacturer demonstrate, at any point after release, exactly which version of every requirement, design document, source file, SOUP component, and test result went into a specific released version of the software. This includes version control for source code, controlled change requests for requirements and design documents, and a defined process for evaluating whether a given change requires re-verification, re-validation, or a new risk assessment.

Without disciplined configuration management, a manufacturer investigating a postmarket issue may not be able to reliably reconstruct what was actually shipped in the version a customer is using, which undermines both the postmarket vulnerability response process and any field investigation into a reported malfunction.

What Documentation Does an FDA Submission Expect?

An FDA submission expects a software description, the assigned IEC 62304 safety class with justification, the software requirements specification, architecture documentation, a summary of verification and validation activities and results, a SOUP list with associated risk evaluations, and, for devices meeting the Section 524B cyber device definition, cybersecurity documentation including a threat model, SBOM, and vulnerability management plan. The level of detail scales with safety class, with Class C software generally requiring the full documentation set described in the FDA's software guidance, while Class A software can be summarized more briefly.

Reviewers are checking not just that each document exists, but that the documents are internally consistent: that the safety class matches the depth of the testing evidence, that the SOUP list matches what appears in the architecture, and that the cybersecurity documentation reflects the same architecture described elsewhere in the submission. Inconsistencies between these documents are one of the more common sources of review cycles and requests for additional information.

How Blue Goat Cyber Approaches This

Blue Goat Cyber works alongside medical device software teams from early design input through submission, focusing on the traceability between requirements, risk controls, architecture, and test evidence that reviewers check most closely. We help teams determine IEC 62304 safety classification early, before architecture decisions lock in a level of process rigor the team was not planning for. Our threat modeling and secure architecture reviews are structured to fit into design input and design review activities rather than arriving as a separate, disconnected security exercise near the end of the project. We also help build and maintain the SBOM and SOUP risk documentation that submissions and postmarket monitoring both depend on. To see how this fits into a broader security engagement, visit our medical device threat modeling services page.

Frequently Asked Questions

What is the difference between verification and validation in medical device software?

Verification confirms that software was built correctly against its own specification at each lifecycle stage, while validation confirms that the finished software actually meets the user's clinical needs. A device can pass every verification test and still fail validation if the requirements themselves did not correctly capture what users needed.

Does every software component need an IEC 62304 safety class?

Yes, every software item within a medical device needs an assigned safety class of A, B, or C based on the potential harm from its failure. A single product can contain items at different classes as long as the manufacturer justifies the segmentation and shows lower-class items cannot compromise higher-class ones.

What counts as SOUP in medical device software?

SOUP includes any software component not developed under the manufacturer's own controlled process, such as open source libraries, commercial off-the-shelf software, operating systems, and third-party drivers. Each SOUP item needs a documented risk evaluation covering known anomalies and vulnerabilities in the specific version used.

How does the QMSR change design controls for software?

The QMSR incorporates ISO 13485 and reserves many of the previous Part 820 subparts, but the core design control expectations for traceability from user needs through verification and validation remain largely intact. 21 CFR 820.35's design history file records requirement stays in force under the QMSR.

When should security requirements be defined in the development process?

Security requirements should be defined during the design input phase, alongside functional requirements, rather than added after architecture and coding are complete. This is because foundational architecture decisions, such as authentication between components and data storage design, are difficult and costly to change later in the lifecycle.

What documentation does a Class C software item need that a Class A item does not?

Class C software items require rigorous unit-level test coverage, detailed design review records, and documented verification of risk control measures at the architecture level, none of which is mandated for Class A. Class A software still needs a development plan and requirements documentation, but without the same depth of unit and architecture-level testing evidence.

CTA

If your team needs help mapping IEC 62304 safety classification, building traceability between risk management and software requirements, or preparing the documentation an FDA submission expects, Blue Goat Cyber can help. Contact us today to talk through your software development lifecycle and what your next submission needs.