Software company qualified for IEC 62304: what to request in 2026
TL;DR
A software company qualified for IEC 62304 work in 2026 is one that can show you records, not badges. The standard binds your device, not the vendor, so the useful evidence is whatever drops into your design history file without a rewrite.
- Quality system: an ISO 13485 certificate you can look up in IAF CertSearch, or a written agreement to work under your procedures as a controlled supplier.
- Safety class: what the team produced differently for class B or C than for class A.
- Artifacts: a redacted software development plan, risk file, traceability matrix, SOUP list and anomaly list.
- 510(k) history: a K-number in FDA's database, held by the client, with a reference who will confirm the vendor's role.
- Cybersecurity: an SBOM, required for cyber devices under section 524B.
The FDA's QMSR took effect on February 2, 2026, so supplier control now sits on an ISO 13485 base.
No vendor is IEC 62304 compliant on its own
IEC 62304 sets life cycle requirements for medical device software, and the FDA accepts a declaration of conformity to it in a premarket submission. The declaration is yours. The manufacturer files the 510(k), owns the risk file and answers the inspector.
So the real question is whether a vendor's work survives being pulled into your quality system, recorded so an auditor can follow a requirement to the test that proves it.
Hattrick lists eight qualifications and eleven documentation items. CMD MedTech lists eight deliverables, from the software development plan to post-market bug tracking. Neither says how to check any of it.
Two 2026 changes and one that has not happened
The quality system rule changed first. The FDA's Quality Management System Regulation became effective on February 2, 2026 and incorporates ISO 13485:2016 by reference. Supplier control is now its clause 7.4: evaluation criteria proportionate to device risk and, per a QMSR audit guide from LSO, a written agreement that the supplier reports changes before making them.
Cybersecurity moved the next day. On February 3, 2026 the FDA reissued Cybersecurity in Medical Devices, superseding the June 2025 version. For a cyber device, which includes any device with sponsor-validated software that can connect to the internet, section 524B requires an SBOM.
The standard itself has not moved. The Johner Institute expects the final draft of Edition 2 not before 2028. Qualify vendors against Amendment 1 of 2015, the version in force.
How we built this evidence list
- Every requirement below traces to a standard, an FDA guidance or the FDA's own databases, linked in Sources.
- Each item answers one question: what document do you ask for, and how do you check it without trusting the vendor.
One disclosure. Mercury Development builds healthcare software, so one section below describes our own record and what it does and does not prove.
The evidence to request at a glance
| Evidence | What to ask for | How you verify it | Red flag |
|---|---|---|---|
| Quality system | ISO 13485 certificate with scope, or a signed quality agreement under your QMS | IAF CertSearch, or your supplier audit | A badge with no certificate number |
| Safety class experience | Projects by class with the artifacts that changed | Redacted samples per class | Only class A work offered for a class C device |
| Development plan | A redacted software development plan | It names a life cycle model and the records it produces | "We are agile" with no plan |
| Risk management | A redacted ISO 14971 risk file excerpt | Risk controls trace to requirements and tests | Risk handled by a separate consultant only |
| Traceability | A traceability matrix excerpt | Pick one requirement and follow it to a test | Matrix built at the end of the project |
| SOUP | A SOUP list with versions and evaluations | Versions match the build | "We use open source" with no list |
| 510(k) history | K-numbers and a reference at the manufacturer | FDA 510(k) database lookup | A clearance claimed in the vendor's own name |
| Cybersecurity | A sample SBOM and threat model | Components match the SOUP list | No vulnerability monitoring process |
Quality system: two models that both work
Hattrick says a vendor should run an ISO 13485 QMS. That is one valid model of two.
Model one is a vendor with its own certificate. Ask for the number, the body and the scope. ISO's help centre is explicit that ISO certifies no one and points to IAF CertSearch, which lists accredited certificates only. A certificate scoped to hardware assembly says nothing about software.
Model two is a vendor that works inside your quality system as a controlled supplier. Clause 7.4 does not require the supplier to hold a certificate. It requires you to evaluate the supplier against criteria proportionate to risk and to put change notification in writing. The evidence is behavior: the vendor trains on your procedures and accepts your audit.
Safety class: ask what changed because of it
IEC 62304 sorts software by what a failure can do. Greenlight Guru summarizes the classes: A when no injury is possible, B when injury but not serious injury is possible, C when death or serious injury is possible. Class B adds documented architecture and unit testing. Class C adds detailed design and unit verification on top.
"We have done class C work" is a claim about paperwork you can sample. Ask what the team produced for class C that it skipped for class A. A team that has been there names detailed design records and unit verification against acceptance criteria. A team that has not describes its testing culture.
Artifacts: ask for the files your submission will carry
The FDA's Content of Premarket Submissions for Device Software Functions guidance, issued June 14, 2023, sets two documentation levels. Enhanced applies when a software failure could present a hazardous situation with a probable risk of death or serious injury. Basic covers everything else.
Your vendor's records feed its list: software description, risk file, requirements, architecture, design specification, development practices, test records, version history and unresolved anomalies. At Basic level the design specification stays in your design history file. At Enhanced level it goes in the submission, along with unit and integration test protocols and reports.
For development practices, the guidance lets you submit a declaration of conformity to named clauses of IEC 62304 instead of a narrative. That declaration is only as good as the vendor records behind it, so ask for redacted samples of exactly those records.
510(k) history: check the K-number, not the logo
A 510(k) is filed by the manufacturer. The vendor's name will not appear as applicant, so "we have 510(k) experience" can mean anything from writing the cleared software to building a marketing site for the company that did.
Verification takes ten minutes. Ask for the K-number, look it up in the FDA 510(k) database, confirm the device and the decision date, then ask the vendor for a reference at the manufacturer who will say what the vendor built. The database entry proves the clearance. Only the reference proves the role.
Cybersecurity: the SBOM is a statutory requirement
Section 524B requires a software bill of materials for a cyber device, and plans and processes that give reasonable assurance the device and related systems are cybersecure.
Hattrick asks for threat modeling, secure code review and penetration testing. Add one check: the SBOM components and the SOUP list should name the same libraries at the same versions. When they disagree, two people maintained two lists, and neither is the build.
What to request by safety class
| Safety class | What a failure can do | Minimum evidence to request | FDA documentation level, usually |
|---|---|---|---|
| A | No injury possible | Development plan, requirements, system test records, SOUP list | Basic |
| B | Non-serious injury possible | Class A set plus architecture and unit test records | Basic, unless a probable serious hazard exists |
| C | Death or serious injury possible | Class B set plus detailed design and unit verification against acceptance criteria | Enhanced |
Safety class and documentation level are separate decisions. The class comes from IEC 62304 and your risk analysis. The level comes from FDA's criterion, assessed before risk controls. They often line up. Check rather than assume.
What device buyers send us, and what our record proves
A device maker with a prescription device still in prototyping asked for a Bluetooth companion app, and the brief said only that the app must comply with FDA regulations. A second buyer, for a consumer stimulation device, listed FDA, IEC 62304 and IEC 82304 by name, and those three requirements forced a hybrid plan: waterfall at the start and end, agile in the middle. The first brief is where vendor qualification goes wrong, because nobody has said what evidence the work must produce.
Read our own record the same way. We built the original Windows desktop version of MatchedFlicker for EyeIC, a retinal image comparison application, and later moved it to a multi-user web version with HIPAA-compliant online access in three months. The clearance is K090266, decided May 6, 2009, and the FDA database lists Eyeic Corporation as applicant, not us. The record proves a cleared product we built. It does not prove a quality system certificate. Our IEC 62304 compliance cost breakdown covers what that evidence adds to an estimate.
Ask for one redacted artifact before any capabilities deck
A capabilities deck is written for the sale. A traceability matrix is written for the auditor, and is hard to fake because every row points at a dated test record.
Make the first request one redacted excerpt: a requirement, its risk control, the test that verifies it and the result. A qualified vendor sends it within days and explains its own redactions. A vendor that offers a call instead has told you what you needed to know.
Agile is not the red flag. AAMI TIR45 is an FDA-recognized consensus standard on agile practice for medical device software, and MedDeviceGuide maps sprint ceremonies to design control records. The red flag is agile with no plan saying which records each increment produces.
Written by Rob Devereaux, Chief Operating Officer at Mercury Development. Rob has run the firm's operations from Hudson, Ohio since 2019 and has over 20 years of operational and financial experience. The pipeline records behind this article's device buyer section sit in the operations he oversees.
Send us your safety class and your submission plan
Tell us the device, your working safety class and whether you expect Basic or Enhanced documentation. We will send back the evidence list for that class and the questions your quality team should put to every vendor on the shortlist.