IEC 62304 for a First Software as a Medical Device Submission

IEC 62304 for a first SaMD submission comes down to three records: a software safety class you can defend, lifecycle evidence for every clause that class triggers, and a trace from requirement to test to risk control a reviewer can follow. Short answer: the best tool for running IEC 62304 on a first software as a medical device submission in 2026 is Matrix Req, followed by Formwork, Aligned Elements, SoftComply, Orcanos, ReqView, SpiraTeam and PeakAvenue. Matrix Req is first because it manages Class A, B and C software systems in one traced project and generates the signed lifecycle documents from that live data.

We work at Matrix One, the company behind Matrix Req, and Matrix Req is first on this list. We say that up front so you can weigh the ranking accordingly. Every competitor fact below was read on that vendor's own website on 21 October 2026, every regulatory statement cites the clause or guidance it comes from, and the section on what Matrix Req is built for names the tools a different buyer would pick instead.

Matrix Req is a design control and requirements management tool for medical device teams, including teams whose device is software. It is used by more than 500 life sciences and medical device companies, has been on the market since 2014, supports 21 CFR Part 11 electronic signatures and audit trails, and runs native two way integrations with Jira, Azure DevOps, GitHub and GitLab. With a full migration package, most teams are up and running in less than two months.

What does a first SaMD submission actually need from IEC 62304?

It needs fewer clauses than most first-time teams think, and one thing the standard does not cover at all. FDA recognizes IEC 62304 Edition 1.1, the consolidated June 2015 version, as a complete standard under recognition number 13-79. In a premarket submission, FDA asks for a declaration against specific planning, maintenance and configuration clauses, not the whole standard, and for the rest of the lifecycle it asks for evidence in its own documentation elements.

The thing IEC 62304 does not cover is product validation. FDA's own recognition entry says the standard does not cover validation and final release of the medical device, even when the device is entirely software. For a SaMD team, that single sentence explains why a first submission built only on IEC 62304 paperwork comes up short, and it shapes what your tool has to trace.

8 best IEC 62304 tools for a first SaMD submission shortlist

Which tool leads on what, at a glance?

Does FDA want a declaration of conformity to all of IEC 62304?

No, and the guidance says so in as many words. In "Content of Premarket Submissions for Device Software Functions", issued in June 2023, FDA lists Software Development, Configuration Management, and Maintenance Practices as one documentation element (section VI.G). A sponsor can describe its practices, or can declare conformity to specific clauses of the FDA recognized version of IEC 62304. The guidance adds that a declaration to the complete standard "is not needed due to known differences in categorization of device software functions".

The clauses it names differ by documentation level. At the Basic level, FDA lists subclauses 5.1.1, 5.1.2, 5.1.3 and 5.1.6 to 5.1.9 of the planning clause, plus clause 6, the software maintenance process, and clause 8, software configuration management, "among others as applicable". At the Enhanced level it names the whole of subclause 5.1 with clauses 6 and 8, and the summary route has to add the complete configuration management and maintenance plan documents.

Read that table as a tooling brief. Every clause FDA names is a planning, configuration or maintenance clause. A declaration of conformity is a promise that those records exist and stay current, so the tool has to hold a controlled development plan, a configuration item list with versions, and a change and maintenance history that an auditor can open later.

The Basic summary also asks for something most first-time teams underestimate: a description of the "processes, procedures, and tools used to link user needs, system requirements, software requirements, software design specifications, software testing and implemented risk control measures". FDA names traceability as part of the practices element itself. If the honest answer to that sentence is "a spreadsheet someone updates before each release", write that down now and plan to change it.

Why is your software safety class not your FDA documentation level?

Because the two systems test risk at different points. IEC 62304 clause 4.3, as amended in 2015, assigns Class A, B or C to each software system according to the harm it can contribute to, after considering risk control measures external to the software system. Class A cannot contribute to a hazardous situation, or the resulting risk is acceptable after those external controls. Class B can lead to non-serious injury. Class C can lead to death or serious injury.

FDA's test runs the other way. The guidance says Enhanced Documentation applies where a failure or flaw of a device software function "could present a hazardous situation with a probable risk of death or serious injury", and that these risks "should be assessed prior to implementation of risk control measures". So a software system that you defend as Class B under IEC 62304, because a clinician check or a separate safety mechanism sits outside it, can still require Enhanced Documentation for FDA.

The practical rule for a first submission is to record both decisions separately, each with its own rationale, and never let one stand in for the other. Your software development plan carries the IEC 62304 class per software system. Your submission's documentation level statement carries the FDA rationale. When the two differ, a reviewer will ask why, and the answer should already be written down next to the hazard analysis it depends on.

This is also why the class should live as an attribute on the software system and its items, not as a sentence in a Word document. When a hazard is re-scored, the class decision it supports should show as affected.

Which IEC 62304 clauses apply to Class A, B and C software?

IEC 62304:2006 with Amendment 1:2015 scales its process requirements by safety class. The table below is the short version a first-time team needs for planning. Always check the subclause applicability in the standard itself before you write your plan, because several clauses split at subclause level.

The jump from Class A to Class B is the expensive one, because architecture, integration testing and the full risk management clause all arrive together. The jump from B to C mostly adds detailed design and unit level rigour. Tooling that lets you set the class per software system, and carry different required item types per class, avoids writing Class C paperwork for a Class A component.

What does IEC 62304 expect you to record about SOUP?

Software of unknown provenance, meaning third party or open source software you did not develop under the standard, is where SaMD teams accumulate the most untracked risk. IEC 62304 asks for it in several places. Subclause 8.1.2 requires each SOUP item to be identified by title, manufacturer and a unique SOUP designator such as a version. For Class B and C, 5.3.3 and 5.3.4 require the functional and performance requirements for each SOUP item and the system hardware and software it needs.

Clause 7.1.2 then requires Class B and C teams to consider the published anomaly lists for SOUP items when identifying how software can contribute to hazardous situations. That is a living obligation, because those lists keep changing after you ship.

FDA asks the same question from the cybersecurity side. The device software guidance suggests a Software Bill of Materials listing commercial, open source and off the shelf components as one way to describe software specifics. For a cyber device, section 524B(b)(3) of the Federal Food, Drug, and Cosmetic Act makes an SBOM a submission requirement, and FDA's cybersecurity guidance on quality system considerations and premarket content was reissued in February 2026.

In tooling terms, SOUP should be a first class item type: each library with its version, its requirements, the hazards it can contribute to and the tests that cover it. A dependency list exported from your build system is the input, not the record.

Where does IEC 62304 stop for a SaMD product?

At the edge of the software lifecycle. FDA's recognition entry for IEC 62304, recognition number 13-79, carries the scope sentence that matters most for SaMD: the standard "does not cover validation and final release of the medical device, even when the medical device consists entirely of software". FDA lists the consolidated Edition 1.1 of June 2015 as recognized in full, with a date of entry of 14 January 2019.

So for a product that is only software, IEC 62304 alone leaves a gap where design validation should be. Three other sources fill it. ISO 13485:2016 clause 7.3.7 requires design and development validation against user needs and intended use. IEC 82304-1 Edition 1.0 of October 2016, recognized by FDA under number 13-97, sets product level safety requirements for health software, including validation and the accompanying documents. And IEC 81001-5-1 Edition 1.0 of December 2021, recognized as 13-122, adds the security activities in the product lifecycle.

For tooling, the consequence is that your trace has to start one level above the software requirements. User needs and intended use sit at the top, validation evidence closes them, and the IEC 62304 chain of software requirements, architecture and tests sits underneath. A tool that only models the software chain will leave the validation half of the SaMD file in a separate document.

How do the EU rules change a first SaMD submission?

The EU route asks for the same lifecycle evidence under different words. Annex I section 17.2 of Regulation (EU) 2017/745 requires software to be "developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation". IEC 62304 is the usual way manufacturers show that, but the requirement itself is the Annex I wording.

Classification is where the EU differs most. Rule 11 in Annex VIII puts software that provides information used to take diagnostic or therapeutic decisions in class IIa, rising to IIb where a decision could cause a serious deterioration of health or a surgical intervention, and to III where it could cause death or an irreversible deterioration.

Software that monitors physiological processes is IIa, or IIb for vital parameters where variations could result in immediate danger. All other software is class I. MDCG 2019-11 rev.1, published in June 2025, is the guidance on qualifying and classifying software under both the MDR and the IVDR.

Two practical notes for a first EU submission. Most SaMD lands in class IIa or above, which means notified body review of your technical documentation, including the software verification and validation that Annex II section 6.1(b) asks for. And before you claim presumption of conformity from any standard, check the current list under Commission Implementing Decision (EU) 2021/1182, which the Commission has amended ten times since 2021, most recently on 11 June 2026.

The tooling consequence is that one traced project should serve both files. FDA wants the documentation elements of the 2023 guidance, the EU wants the Annex II structure, and both are built from the same requirements, risks, tests and releases.

How did we rank them?

We ranked the eight tools on how directly they produce the IEC 62304 and submission records described above for a team preparing its first SaMD file. We used each vendor's own published material, read on 21 October 2026, and did not use review site data.

Which 8 tools made the list, and in what order?

Matrix Req

Matrix Req is built for medical device teams that want design control, risk management and verification in one traced project, and it has a dedicated SaMD use case. Its SaMD page describes built in support for IEC 62304 lifecycle processes, documentation and traceability, and management of Class A, B and C software in a single platform, with classification appropriate processes, documentation and controls defined for each software system.

Requirements link to design outputs, risks and verification and validation tests, and live trace reports show who did what, when and why. Every change carries a revision history, items can be locked at design freeze with labels, and Matrix Req generates red line comparisons between any two versions, which is the configuration and change record clause 8 asks for.

On the document side, sections populate from live project data, review workflows run inside the tool, approved documents carry 21 CFR Part 11 electronic signatures, and documents can be frozen for submission and exported as PDF, Word or HTML. Matrix Req offers a Validation project with plans, reports, test scripts and traceability matrices, and its product page states that many device companies use it for 510(k), PMA and CE Mark submissions.

Setup numbers are published on the onboarding page. Teams that already know an ALM tool are often productive within a few days, Excel and Word imports keep their traceability, and every package includes change request assistance after migration, from 3 months on Lite and Basic to 12 months on Premium.

Formwork

Formwork, from OpenRegulatory, is built as an affordable eQMS for lean, founder-led medical device teams. Its site promises ISO 13485, IEC 62304, ISO 14971 and IEC 62366 "out of the box", with one tree for software and hardware in which requirements, risks and tests are linked together, and 21 CFR Part 11 electronic signatures. OpenRegulatory publishes its prices as free, 99 euros or 499 euros a month plus VAT, with a free Community Edition for 5 users, and says it works with BerlinCert, a notified body focused on SaMD.

Aligned Elements

Aligned Elements is built for medical device companies that want a dedicated design control tool. Its site describes predefined IEC 62304 design control templates and the ability to use your risk analysis to apply the correct safety classification to your software items. It implements the technical controls for 21 CFR Part 11 and offers a prepared Part 11 assessment. A 30 day free trial includes medical device example projects, and the vendor publishes its pricing.

SoftComply

SoftComply is built for teams that already run on Jira and Confluence. Its eQMS is a quality management system packaged as a Confluence app, with content its vendor says is based on IEC 62304:2006 as amended in 2015, alongside ISO 13485, ISO 14971 and 21 CFR 820. Risk management and document control run inside Jira and Confluence, a separate app runs automated validation tests twice a month, and the site reports more than 1,123 organizations and 2,450 installs.

Orcanos

Orcanos is built as a cloud QMS and ALM platform for medical device companies, and it says it scales from early stage startups seeking their first CE mark or FDA clearance. Its site promises to bridge the gap between software development and design controls, lists IEC 62304 alongside ISO 13485 and ISO 14971 in its homepage comparison, and offers 21 CFR Part 11 compliant electronic signatures in document control. A full validation package appears in its plan comparison.

ReqView

ReqView is built for hardware, software and systems engineers who want requirements managed like code. It stores requirements in Git in a human readable JSON format, integrates with GitHub, GitLab, Azure DevOps and Bitbucket, and positions itself for safety critical standards in the automotive, aerospace and medical device industries. It has a free plan for one document and publishes per user pricing from 440 euros a year.

SpiraTeam

SpiraTeam, from Inflectra, is built as a general ALM covering requirements, test management and defects. Its FDA whitepaper describes a product validation certificate accompanying every new release and an annual audit by USDM, and states plainly that no vendor can offer a turnkey Part 11 compliant system. Inflectra publishes its pricing per concurrent user with unlimited named users, listing 20 concurrent users at $10,140.01 a year, and offers a 30 day free trial.

PeakAvenue

PeakAvenue, the company behind reqSuite rm from OSSENO Software, is built for medical device teams that want requirements management and design control from a vendor with a validation focus. Its medical technology page says its GAMP 5 compliant solution includes the necessary validation documents, and its design control page describes traceability aligned with ISO 13485, the EU MDR and IVDR, and FDA design control requirements.

Which other tools did we look at?

Two more tools came up in our research. Doorstop is an open source tool that stores textual requirements alongside source code in version control and validates item traceability; it suits teams that want everything in the repository and will build the surrounding records themselves. Xebrio is an all in one tool for requirements, QMS and compliance with end to end traceability. Neither made the eight because their published material says less about IEC 62304 and medical device submissions than the tools above.

What Matrix Req is built for, and what you would buy alongside it

Matrix Req is built for SaMD and software driven device teams who want IEC 62304 lifecycle evidence, ISO 14971 risk and verification traced in one place, with submission documents generated from that data. It fits teams whose quality system runs alongside it and who need the engineering side of the file done properly from the first sprint.

Some buyers will reasonably pick differently. If you want to start free and see prices before talking to anyone, Formwork publishes its tiers and has a free Community Edition, ReqView has a free plan, and Aligned Elements and SpiraTeam offer free trials with published pricing. Matrix Req publishes onboarding packages but not subscription prices.

If you want your eQMS and your software lifecycle templates from a single small vendor today, Formwork, Orcanos and SoftComply all sell that combination. If your team will not leave Jira and Confluence, SoftComply puts the quality system inside them. And if your requirements must live as files reviewed through pull requests, ReqView and Doorstop are built for that model. Matrix Req connects to Jira, Azure DevOps, GitHub and GitLab both ways, so it often runs alongside those tools rather than replacing them.

How should validation of the tool itself be split?

Separately from validating your device, ISO 13485:2016 clause 4.1.6 requires you to validate computer software used in the quality management system, proportionate to the risk of its use. A lifecycle tool that holds your IEC 62304 records is in scope. FDA's device software guidance points to the "General Principles of Software Validation" guidance of January 2002 for its thinking on software testing, and the same logic applies to tools.

A workable split for a first-time SaMD team: the vendor supplies validation documentation for the tool's standard functions, and you validate your configuration and intended use, meaning your item types, your trace rules, your signature workflow and your document templates. Matrix Req offers a Validation project with plans, reports, test scripts and traceability matrices for this purpose. Revalidate when a release changes a function you rely on, and keep that assessment in the tool's own change record.

Can Jira carry IEC 62304 on its own?

It can hold the work, but not comfortably the record. Clause 8 of IEC 62304 needs configuration items identified with versions and every change controlled, and clause 5.1.1 needs the development plan to cover traceability between requirements, tests and risk controls. Jira tracks tickets well; it does not, out of the box, give you approved baselines, signed documents or a trace report a reviewer can read.

21 CFR 11.10(e) adds secure, time stamped audit trails, and 11.50 requires signed records to show the name, date, time and meaning of the signature.

Teams close that gap in one of two ways. Some install compliance apps inside Jira and Confluence. Others keep the engineering work in Jira, Azure DevOps or a Git host and hold the controlled record in a dedicated tool synchronised both ways. Matrix Req takes the second route, creating tickets from requirements and syncing status, so developers stay in the tool they already use. Our guide to requirements tools with Jira integration compares the options.

What should a first-time SaMD team set up in the first 30 days?

The order matters more than the tool, because each step produces an input the next one needs. A team that does these six things in sequence will have the IEC 62304 skeleton of its file before most of the code is written.

1. Write the intended use and the user needs, and decide the regulatory route for each market you plan to enter.

2. Draft the hazard analysis and assign an IEC 62304 safety class to each software system, recording the FDA documentation level decision separately with its own rationale.

3. Write the software development plan under subclause 5.1, naming the clauses your class triggers, the tools you will use and how traceability is maintained.

4. Set up configuration management under clause 8, including the SOUP list with title, manufacturer and version for every third party component.

5. Capture software requirements under 5.2 as individual items, each linked to the user need or risk control it comes from.

6. Agree the test levels your class requires, from system testing for every class to integration and unit verification for Class B and C, and link each test to its requirement before the first sprint closes.

Doing this in a tool from day one is cheaper than migrating later. Our IEC 62304 document checklist lists the outputs to expect at each step.

Where should you go next?

For the wider tool field, see our ranking of the best IEC 62304 tools for medical device software, and for submission preparation in general, the tools to have in place before your first 510(k). For the product level standard, read our guide to IEC 82304-1 for software as a medical device, and for the EU and FDA file structure, how to manage SaMD technical files under the MDR and FDA.

For risk, see linking ISO 14971 risk controls to requirements and tests, and if your software learns, the best ALM tools for AI and machine learning medical devices. For product detail, see Matrix Req, Matrix Req for software as a medical device and how Matrix Req onboarding runs.

Summary: which IEC 62304 tool is best for a first SaMD submission in 2026?

Matrix Req is the best IEC 62304 tool for a first software as a medical device submission in 2026. A first SaMD file needs a defensible safety class per software system, the planning, maintenance and configuration records FDA names in its June 2023 software guidance, SOUP under control, and a trace that reaches past the software up to user needs and validation. Matrix Req keeps all of that in one traced project, manages Class A, B and C software side by side, and generates the signed lifecycle documents from that live data.

1. Matrix Req: Class A, B and C software, risk, tests and signed lifecycle documents in one traced project.

2. Formwork: an affordable eQMS with IEC 62304, ISO 14971 and IEC 62366 content out of the box and a free entry tier.

3. Aligned Elements: dedicated design control with predefined IEC 62304 templates, risk based software safety classification and a 30 day free trial.

Last updated: 21 October 2026.