Clause 6 of IEC 62304 is where most teams get hurt. We covered that last month — the maintenance traps, the frozen risk files, the patch backlogs that become audit findings.

But Clause 6 problems are almost always Clause 5 problems in disguise.

Clause 5 is the software development lifecycle — the eight sub-processes that govern everything from initial planning to release. If you run Clause 5 well, Clause 6 is manageable. If you cut corners in Clause 5, you spend the back half of your product’s life in remediation.

Here’s the practitioner’s read on Clause 5: what each sub-process actually requires, where teams consistently go wrong, and the patterns that hold up when an auditor starts asking questions.

What Clause 5 actually requires

Clause 5 has eight sub-processes. They’re sequential in structure but overlapping in practice, and all of them produce artifacts that end up in your FDA submission.

5.1 — Software development planning

Before development starts, you commit in writing to how it will run. Your Software Development Plan defines the lifecycle model, identifies software items and their safety classes, specifies deliverables and who owns them, and describes how the process connects to risk management and configuration management. This is the document that governs everything else. Auditors read it first, then check whether what follows actually matches it.

5.2 — Software requirements analysis

Requirements get documented before code gets written. Each requirement carries a unique identifier, is testable, and traces upward to system requirements and downward to design and test. This is not a description of the software you built. It’s the specification the software was built against. That distinction matters enormously when an FDA reviewer asks how you verified the device does what it claims.

5.3 — Software architectural design

You identify the software items that compose the system, assign a safety class to each, define the interfaces between them, and document the architectural rationale — particularly for decisions that affect safety or risk. This is where the compliance dividend from modular design pays off. Teams that built a monolith have to assign Class C treatment to everything. Teams that isolated safety-critical components get to apply proportionate rigor.

5.4 — Software detailed design

For each software item — or at least each Class B and C item — you document the detailed design with enough specificity that someone could implement and verify it without inventing requirements along the way. Interfaces, data flows, error handling, state transitions. The standard doesn’t mandate a format. It mandates the content.

5.5 — Software unit implementation and verification

Code gets written. Units get tested. The verification evidence gets captured. For Class C software items, this means unit tests with pass/fail records, coverage appropriate to the safety class, and traceability from each test back to the requirement it exercises. The tests themselves are not enough. The evidence that they ran and passed is what FDA sees.

5.6 — Software integration and integration testing

Software items get assembled and tested together. Integration test protocols are written before testing runs. Anomalies — any unexpected behavior — get documented and resolved. The integration test report becomes part of the submission package. Teams that run integration testing informally, without protocols, produce results that can’t be referenced in a submission without explanation.

5.7 — Software system testing

The complete software system gets tested against the Software Requirements Specification. System test protocols are pre-approved. Every test has a pass/fail criterion. Anomalies are recorded, evaluated, and closed — or formally accepted with rationale if residual. The system test report is one of the most-reviewed documents in a 510(k) submission.

5.8 — Software release

Before release, you confirm that release criteria are met, document known anomalies and their risk-evaluated status, establish a configuration baseline, and create a release record. The release record is the final artifact that closes the Clause 5 lifecycle. Teams that skip it — or create it retroactively — have a gap that’s hard to explain.

Clause 5 doesn’t just require that you run a process. It requires that you can prove you ran it.

Where teams get stuck

After supporting medtech software teams through development and FDA submission, the same failure patterns appear:

1. The SDP that describes intent, not reality

The Software Development Plan is written at the start of a project when everything is still theoretical. Six months later, the team has adapted — different lifecycle phases, different deliverable owners, sprint rhythm that doesn’t match the plan. Nobody updated the SDP. Now the plan says one thing and the actual artifacts say another. Auditors reconcile these. The gaps become findings.

2. Requirements written after the fact

Development runs ahead of documentation. Features get built, then someone writes the requirements to match what was built. The SRS describes the software, not the specification it was developed against. The traceability chain looks intact on paper, but any reviewer who pulls on a thread finds that requirements and design decisions are not actually in the right order. This is one of the most common — and most detectable — problems in submissions.

3. Safety class applied to the system, not the items

A team correctly identifies that their device contains Class C software. But instead of decomposing the system into items and classifying each, they apply Class C treatment to everything. This is technically defensible but practically expensive — and it usually means the team hasn’t done the architectural work to isolate components. The missed opportunity is proportionality: Class C rigor where it’s warranted, Class A speed everywhere else.

4. Test evidence that exists somewhere but isn’t organized

Teams run unit tests. CI pipelines generate results. Integration tests happen in a staging environment. System tests get run by a QA team. All of this produces evidence — but none of it is organized against the requirements it’s supposed to verify. When submission time arrives, the evidence exists but can’t be presented coherently. The traceability matrix is built backward from the test runs, not forward from the requirements.

5. Integration test protocols that don’t exist before testing starts

FDA expects protocols to be written, reviewed, and approved before testing runs — not created to document testing that already happened. Teams that run integration testing informally, without pre-approved protocols, can’t reference the results in a submission without a qualification. Writing protocols after the fact is re-testing on paper. It’s detectable, and it erodes confidence in the submission.

Five patterns that work

1. Keep the SDP alive

Designate an owner for the SDP and treat it like any other regulated document — versioned, updated when the process changes, approved at each revision. The SDP is not a project artifact you file and forget. It’s the governing document for everything Clause 5 produces. A living SDP that accurately reflects how the team worked is a strong audit signal. A stale one is a liability.

2. Write requirements before sprints, not after

This is the hardest discipline to establish in an Agile team and the most valuable one. Requirements don’t need to be waterfall-style documents — they can live in your ticket system. But they need to exist, carry unique IDs, and be approved before the sprint that implements them. The traceability chain runs forward from requirements. If requirements are written after implementation, that chain doesn’t exist — it’s simulated.

3. Decompose software items and classify each one

Do the architectural work to separate safety-critical from non-critical components before development starts. Define the interfaces. Assign safety classes at the item level. This creates the proportionality that makes Clause 5 tractable — and makes Clause 6 maintenance significantly cheaper. A well-decomposed architecture generates the Clause 5.3 artifact naturally. A monolith requires a retrofit.

4. Build verification evidence collection into your CI pipeline

Unit test results, coverage reports, static analysis output — configure your pipeline to capture and archive these automatically, tagged to the requirement IDs they cover. The goal is not just to run tests. It’s to generate evidence that can be referenced in a submission without manual reconstruction. Teams that build this in from the start have their 5.5 package ready when they need it. Teams that don’t spend weeks organizing output from dozens of CI runs.

5. Write integration test protocols before the integration test sprint

Schedule a protocol-writing phase before integration testing starts. Protocols don’t have to be long — but they need to specify what’s being tested, how, and what constitutes pass/fail. Approved before execution. Results recorded against the protocol. Anomalies documented. This is the difference between integration test evidence that holds up in a submission and test output that has to be re-characterized.

What this looks like in practice

The teams that move fastest through FDA review have one thing in common: they generated Clause 5 evidence as a natural byproduct of how they worked, not as a submission-preparation exercise.

Their CI pipeline produced archived test evidence. Their ticket system carried requirement IDs. Their sprint retrospectives caught SDP drift before it accumulated. Their release records existed because someone put them on the sprint checklist.

The teams that struggle treated Clause 5 as a documentation checklist to be completed before submission. By the time they started checking boxes, the development was done and the evidence was missing.

Clause 5 is not a documentation exercise. It’s a development discipline. The documentation is the residue.

The submission you file is a retrospective account of how the software was built. If the process was right, the documentation is easy. If the process wasn’t right, no amount of documentation can fix it retroactively — it can only obscure it, and not for long.

If you’re in pre-development: the time to design for Clause 5 is now, before sprint 1.

If you’re mid-development: run a gap assessment against each sub-process. Find out what’s missing while you can still generate it organically.

If you’re pre-submission: you need an honest inventory of what exists and what was reconstructed. Reviewers can tell the difference.

Most engineers reading IEC 62304 for the first time stop at Clause 5. That’s where the framework is interesting. Architecture. Verification. Traceability. Risk-classed unit testing. You can build a development process around it.

Clause 6 is where most teams get hurt.

Clause 6 is the software maintenance process — the rules that govern what happens to your software after you put your name on the development closure. Post-submission, post-clearance, post-deployment. It’s the part of 62304 that turns every git commit into a regulated event. And it’s the part nobody writes about, because it lives in the unglamorous middle of the product lifecycle.

Here’s a practical read on Clause 6 — what trips teams up, and the patterns that actually work.

What Clause 6 actually requires

Clause 6 has three sub-processes, and you need all three.

6.1 — Establish a software maintenance plan. Before you release, you commit in writing to how you’ll handle maintenance throughout the product lifecycle. How problems get reported. How they get evaluated. How modifications get implemented. Who has authority. What records get kept.

6.2 — Problem and modification analysis. Every reported problem — an internal bug, a customer complaint, a CVE in a dependency, a regulatory change — gets formally analyzed. Is this a defect? Does it affect safety? Does it warrant a corrective action? Does it require an MDR? Does it require notification to the FDA? The output is a documented decision with traceable inputs and reasoning. This is not Jira triage. This is a regulated process whose artifacts get audited.

6.3 — Modification implementation. If you decide to change the software, you re-enter the development process at the appropriate point. Not from the top. Not from where it’s convenient. From wherever the change actually affects. A change to a Class C component may require you to redo unit tests, integration tests, system tests, and risk analysis. A change to an isolated UI string may not. The judgment about where to re-enter is itself a documented decision.

That’s the shape of it. Three sub-processes, all of them required, all of them auditable.

Where teams get stuck

Some typical failure patterns are:

1. The patch backlog. Security patches, dependency updates, minor fixes pile up because nobody on the team is sure whether they "trigger" the Clause 6 process. The team is afraid that addressing them will start a chain of work that won’t end. So they don’t address them. Then a CVE lands on something they were already behind on, and now there’s no time to do it right.

2. The frozen risk file. ISO 14971 risk management is supposed to be a living document, updated for every change that affects risk. In practice, the risk file gets locked at submission and never reopened. Auditors notice. Patches that materially change the device’s risk profile go in without risk re-evaluation, and the audit trail can’t justify the decision.

3. Maintenance branches that drift. A "hotfix" branch gets created, ships once, and stays alive. Six months later there are three of them, each with different patches, none merged back to main, none with verification re-runs documented. The configuration management story falls apart fast.

4. Undocumented re-entry decisions. A team decides a change is small enough to skip re-running system tests. That decision may be right. But if it’s not written down with the reasoning, an auditor will assume it wasn’t made — which is worse than a wrong decision documented.

5. No criteria for the 510(k) line. Clause 6 doesn’t tell you when a software change requires a new FDA submission. That’s a separate question, informed by the FDA’s "Deciding When to Submit a 510(k) for a Software Change" guidance. But your Clause 6 process needs to trigger that question. Teams that don’t have a documented criterion end up making the call ad-hoc, under pressure, with the security patch already shipped.

Five patterns that work

Treat your bug tracker as a regulatory artifact. Every ticket gets fields for severity, regulatory impact, risk assessment status, and decision rationale. Templates enforce this. Reviewers reject tickets that skip them. It’s friction, but it’s the friction that keeps the audit trail intact when you need it eighteen months later.

Make Clause 6.2 a step in your standard ticket flow. Don’t bolt on a "regulatory review" process after the fact. Bake it in. Every bug, every dependency update, every customer complaint enters the same evaluation pipeline. The output of that pipeline is either "address through standard development" or "address through expedited maintenance" — never "skip."

Pre-define your re-entry rules. Decide, before you need to know, what kinds of changes require re-running which tests.
Architectural changes → full integration + system.
Component changes → integration.
Bugfixes within a unit → unit + relevant integration.
UI string changes → unit + smoke.

Write this into your maintenance plan. Then follow it.

Update the risk file like it’s code. Every modification goes through a risk impact analysis. If risk changes, the file changes, with traceability back to the modification request. Treat it like any other deliverable — versioned, reviewed, signed off.

Document the 510(k) criterion separately, and apply it always. Have a written decision framework for when a change crosses the threshold for FDA notification. Apply it to every change request, not just the obvious ones. The discipline of running the analysis even on changes that clearly don’t trigger a submission is what builds the audit story for the ones that do.

What this looks like in production

The teams that get this right have one thing in common: they designed for Clause 6 during development. They built their CI/CD to generate the evidence Clause 6 requires, not just run the tests. They built their ticket templates around the analysis Clause 6 demands. They built their release process around the re-entry rules Clause 6 implies.

The teams that struggle treated maintenance as an ops problem and discovered, around month four of post-market, that it was a regulatory one.

Clause 5 gets you cleared. Clause 6 is what keeps you cleared.

If your team is about to ship, or has recently shipped, the audit you should be most worried about isn’t the one for the device that launched. It’s the one for the device that’s been in the field for eighteen months — and your bug tracker has just become evidence.

Building or supporting a medical device software team? Hattrick helps medtech companies design FDA-compliant software processes — from IEC 62304 from scratch to retrofitting a maintenance process that will survive the next audit. Get in touch at hello@hattrick-it.com.

For years, the compliance question for AI-powered Software as a Medical Device was relatively straightforward: get CE marking under EU MDR or IVDR. That is no longer sufficient.

The EU AI Act (Regulation (EU) 2024/1689) entered into force on August 1, 2024. Its high-risk AI obligations apply from August 2026 for new products, and August 2027 for existing CE-marked products. For any SaMD that includes AI or machine learning components, this introduces a second, overlapping regulatory framework on top of MDR and IVDR.

This guide explains what the AI Act requires from SaMD developers, how it interacts with existing EU medical device regulations, where your current IEC 62304 documentation falls short, and what your team should be doing right now.

What is the EU AI Act and how does it differ from what you already comply with

The EU AI Act is the world's first comprehensive regulatory framework specifically for artificial intelligence. It establishes a risk-based classification system with four tiers: prohibited practices, high-risk AI, limited-risk AI, and minimal-risk AI.

Medical AI almost universally falls into the high-risk category. Under Article 6(1)(b) of the Act, any AI system that is a component of a medical device regulated under MDR or IVDR and requires a Notified Body conformity assessment is automatically classified as high-risk AI. This is not a judgment call. If your SaMD requires Notified Body review, it is high-risk AI.

The key difference from what you already do under MDR and IEC 62304:

→  MDR and IEC 62304: govern how you build safe, functional software for a medical device. They focus on the development process, risk management, and clinical performance.

→  The EU AI Act: adds requirements specific to AI systems: data governance, algorithmic transparency, bias testing, human oversight architecture, and AI-specific post-market monitoring.

The two frameworks are designed to be complementary, not competing. But compliance with one does not imply compliance with the other. There are requirements in the AI Act — particularly around training data governance and explainability — that have no direct equivalent in MDR or IEC 62304.

The compliance timeline — including the detail most teams are missing

The AI Act is being phased in progressively. Here is the complete timeline relevant to medical device AI:

What high-risk AI classification requires: the 8 obligation areas

Providers of high-risk AI systems (which includes SaMD developers) must meet requirements across eight areas under the Act. Here is what each means in practice for a medical device team:

1. AI quality management system (Article 17)

High-risk AI providers must maintain a quality management system that covers the AI lifecycle — from data governance and model development through deployment and monitoring. The good news: if you already operate under ISO 13485, you do not need a parallel AI QMS. The Act explicitly allows AI QMS requirements to be incorporated into your existing medical device quality system. You will need to extend your QMS to cover the AI-specific areas below, but you are not starting from scratch.

2. Technical documentation (Article 18 and Annex IV)

The AI Act requires a technical documentation file for the AI system. For medical devices subject to MDR or IVDR, this can be integrated into your existing technical file or Design History File rather than maintained as a separate document set. The AI Act technical documentation must cover:

• A general description of the AI system and its intended purpose
• A detailed description of the system's elements and its development process
• Information on training, validation, and testing data and methodology
• Monitoring, functioning, and control measures
• A description of the changes made through the lifetime of the system
  

The critical new addition here is the training and testing data documentation. This is not covered by your current DHF and will require new artifacts.

3. Data governance and training data requirements (Article 10)

This is the area where SaMD developers most commonly find gaps against their existing IEC 62304 documentation. The Act requires that training, validation, and testing datasets:

• Are subject to documented data governance practices
• Are relevant, representative, and free of errors to the extent possible
• Are examined for potential biases that could lead to health risks or discrimination
• Cover the geographic, behavioral, or functional settings in which the system is intended to be used
  

In practice, this means you need to document your training data sources, versioning, preprocessing decisions, and the bias analysis methodology you applied — before deployment, not retrospectively.

4. Human oversight (Article 14)

High-risk AI systems must be designed so that human operators can effectively oversee them. This is not a labeling or instruction-for-use requirement — it must be built into the product architecture. The Act requires that the system includes the ability for operators to interpret outputs, override or interrupt the system, and understand when output reliability may be limited.

For clinical decision support AI, this means the product design must actively support human judgment rather than presenting AI outputs as definitive conclusions. How oversight is implemented needs to be documented in your technical file.

5. Transparency and provision of information to deployers (Article 13)

High-risk AI systems must be sufficiently transparent that deployers — hospitals, clinicians, healthcare institutions — can understand the system's capabilities and limitations. The Act requires documentation covering intended purpose, performance levels, accuracy metrics, and known limitations.

For AI in medical devices, this overlaps with your Instructions for Use requirements under MDR — but the AI Act goes further by requiring documentation of the conditions under which the system may be expected to fail or produce unreliable outputs.

6. Robustness, accuracy, and cybersecurity (Article 15)

High-risk AI systems must achieve an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle. For medical AI, this includes resilience against adversarial inputs and the ability to detect out-of-distribution inputs that could affect model reliability. This intersects with FDA's SBOM requirements and cybersecurity guidance for cyber devices — if you are building for both markets, your cybersecurity architecture needs to satisfy both frameworks.

7. Post-market monitoring (Article 61)

AI Act post-market monitoring goes beyond the PMS plan required under MDR. It must specifically track AI performance metrics over time, including the detection of model drift — the gradual degradation in model performance as real-world data distributions shift away from training data. Your PMS plan needs AI-specific monitoring indicators, not just general clinical performance metrics.

8. Registration in the EU AI database

Providers of high-risk AI systems must register their product in the EU AI database before placing it on the market. A similar database to EUDAMED — it is not yet publicly accessible as of early 2026, but registration will be required. This is an administrative step but one that requires planning, as your technical documentation must be ready to support registration.

How the AI Act maps to your existing MDR and IEC 62304 documentation

The following table summarizes where your existing compliance documentation satisfies AI Act requirements, and where it does not. The right column identifies genuine gaps that need new work.

What SaMD developers should be doing right now

If your product is AI-powered and targets the EU market, the following steps are not optional — they are the minimum viable compliance preparation for August 2026 and August 2027.

Step 1: Classify every AI component in your product

Not all software that uses statistics or rules-based logic qualifies as an "AI system" under the Act's definition. The EU AI Act defines an AI system as a machine-based system that infers from inputs how to generate outputs — predictions, recommendations, decisions — that can influence real or virtual environments.

Walk through your product and identify every component that meets this definition. Some components you may have thought of as AI may fall outside the Act's scope. Others you might not have flagged may be in scope. Classify before you plan.

Step 2: Conduct a gap assessment against AI Act Annex IV

Map your existing technical file and DHF against the AI Act's Annex IV documentation requirements. The gaps for most teams are concentrated in: training data documentation, bias analysis records, and human oversight architecture documentation. These are the areas that require the most lead time to address properly.

Step 3: Extend your ISO 13485 QMS to cover AI Act Article 17 requirements

You do not need a separate AI QMS. You do need to extend your existing quality system to explicitly cover: data governance processes, AI model validation procedures, post-market AI performance monitoring, and change control for model updates. This is procedural work that can be done systematically — but it takes time and needs to happen before your next conformity assessment.

Step 4: Update your PMS plan with AI-specific monitoring metrics

Your current PMS plan almost certainly does not include model drift detection, subpopulation performance monitoring, or AI-specific incident reporting thresholds. These need to be added. If your product is already on the market, this is the highest-urgency item — post-market monitoring for AI must be active, not retrospective.

Step 5: Engage your Notified Body early

Notified Bodies designated under MDR are beginning to incorporate AI Act compliance verification into their assessments. How they will conduct this in practice is still being defined — which is exactly why early engagement matters. Contact your Notified Body now to understand their current approach to AI Act integration and whether your planned timeline is realistic given their capacity.

The window to prepare is closing

The EU AI Act is not a future compliance horizon for SaMD developers. For new products, August 2026 is four months away. For existing CE-marked products, August 2027 provides more runway — but Notified Bodies are already incorporating AI Act considerations into their MDR assessments today.

The teams that will move smoothly through this transition are the ones doing gap assessments and documentation planning now, not the ones scrambling to retrofit compliance into a product that is already on the market.

We once heard: "The Software Development Plan is the first document FDA reviewers open. If it's unclear, they assume the rest of the submission will be too."

That single document sets the tone for everything that follows in your FDA submission. Yet for most teams building medical device software, it's either written too late, treated as a formality, or both.

This guide explains exactly what FDA-compliant software development requires in a Software Development Plan: the sections that matter, the language that works, and the gaps that cause additional information requests. We have also included a free downloadable template at the end.

What is a Software Development Plan — and why FDA cares

The Software Development Plan (SDP) is your upfront commitment to FDA that you knew how you were going to build safe software before you wrote the first line of code. It is required under IEC 62304, the international standard for medical device software development, and it plays a central role in your Design History File.

The key word is plan. An SDP is not a description of what you built. It is documentation that you had a controlled, intentional process for building it and that process was appropriate for the risk class of your device.

What FDA is really looking for

A thin SDP signals a thin development process. Reviewers are experienced enough to read between the lines.

Specifically, FDA wants to see three things from your SDP:

→  That you made deliberate, documented decisions about how to develop safe software — before development began.

→  That those decisions were appropriate for your device's IEC 62304 safety class.

→  That your development approach integrates compliance activities — risk management, verification, configuration control — rather than treating them as a separate phase.

A well-written SDP doesn’t need to be long. It needs to be specific, internally consistent, and clearly connected to the rest of your technical documentation.

The 7 sections of a compliant Software Development Plan

The following sections are expected in any SDP for a Class B or Class C device under IEC 62304. Class A devices have lighter requirements, but a complete SDP is still best practice and typically expected by FDA reviewers regardless of class.

1. Product and intended use overview

This is not a marketing paragraph. It is a precise, technical statement that anchors the entire document. It must answer:

• What does the software do and what clinical function does it support?
• Who is the intended user — clinician, patient, or technician?
• What is the potential harm if the software fails to perform as intended?
  

This section drives your safety class determination and your risk identification. A vague intended use statement produces a vague risk analysis — and FDA will notice.

2. IEC 62304 software safety class determination

State your class (A, B, or C) and provide a brief, evidence-based justification from your preliminary hazard analysis. FDA wants to understand how you arrived at the classification, not just which box you checked.

A common mistake is stating Class A or Class B with no supporting rationale. Reviewers will ask for the hazard analysis that supports it. Include a summary here and reference the full risk analysis in your risk management documentation.

The FDA has slowly moved away from this classification and now aligns with two types of documentation levels. Read more about it in their Content of Premarket Submissions.

3. Development lifecycle approach

This section is where most teams are vague and where FDA reviewers spend the most time. You need to explain not just what methodology you are using, but how regulatory requirements are integrated into it.

If you are using Agile — which is both acceptable and common under AAMI TIR45 — you must address:

→  Design controls: explain how they map to your sprint cadence

→  Risk management: describe how it is integrated into sprint planning and backlog refinement

→  Verification evidence: explain how it is generated during development, not assembled retrospectively

→  Definition of Done: state how IEC 62304 compliance requirements are part of it

"We use Agile" is not sufficient. FDA does not automatically understand what that means for your compliance activities. The connection must be made explicit in your SDP.

4. Roles and responsibilities

Name the roles responsible for development, verification and validation, risk management, and regulatory documentation. This does not require an org chart, but it should be specific enough that a reviewer can identify accountability for each compliance activity.

For small teams, one person may hold multiple roles. That is acceptable — but for Class C devices, the separation between development and independent verification activities should be clearly articulated.

5. Configuration management approach

Explain how code changes are tracked, how builds are controlled, and how you manage SOUP  (Software of Unknown Provenance), meaning third-party libraries, open-source components, and commercial off-the-shelf software included in your device.

IEC 62304 Section 8 has specific SOUP management requirements that many teams underestimate. Your SDP should reference your SOUP inventory and describe how component risk is assessed both at adoption and when updates occur.

6. Verification and validation plan

Describe what you will test, at what level (unit, integration, system), and how pass/fail criteria will be defined. This section can reference a separate V&V plan, but the SDP should summarize your overall approach clearly.

For Class C devices, FDA expects full traceability between requirements, test cases, and risk controls. Your SDP should state how that traceability will be maintained throughout the project, not just at submission time.

7. Risk management integration

The SDP must explicitly reference your ISO 14971 risk management plan and describe how risk management connects to your development process. Risk management is not a separate workstream that runs alongside development, it must be woven into it.

Specifically: explain how risk controls identified in your risk analysis become software requirements, and how you verify that those controls are implemented and effective in the final product.

Common gaps FDA reviewers flag

These are the SDP issues that most reliably generate questions or hold letters from reviewers:

How to keep your SDP current throughout development

The SDP is a living document. Write it at the start of the project, update it as significant decisions change, and finalize it as part of your Design History File before submission.

FDA reviewers can often tell the difference between an SDP that guided development and one written retrospectively to describe what happened. The former is specific about decisions, timelines, and rationale. The latter tends to be generic and abstract, the document equivalent of describing a journey after you have already arrived.

In practice, this means:

→  Write the initial SDP before development begins — even a first draft is better than nothing.

→  Update it when your lifecycle approach changes significantly, your team structure changes, or your safety class is revised.

→  Maintain a version history. Changes to the SDP should be controlled under your configuration management process.

Not sure if your current SDP will hold up under FDA review? We offer a complimentary review for MedTech teams preparing for submission.  Get in touch: maria@hattrick-it.com

Section 524B of the FD&C Act requires Software Bills of Materials for cyber devices. Most teams know they need one. Very few know how to actually create one that works.

The common approach: build the software, generate an SBOM before FDA submission, discover critical vulnerabilities in components you've been using for months, then spend months in remediation mode. By the time you're ready to submit, your timeline has increased significantly.

There's a better way. But it requires understanding what FDA actually requires versus recommends, why they want it, and how to build SBOM generation into your development process from day one.

The 2026 update aligned the cybersecurity guidance with the new Quality Management System Regulation (QMSR), which replaced the old Quality System Regulation (QSR) and incorporates ISO 13485. This matters for SBOM because it explicitly frames SBOM as part of configuration management under ISO 13485, not a standalone requirement.

Translation: SBOM requirements didn't get stricter. But the FDA made clearer that SBOM is part of your quality system, not separate paperwork.

The Cyber Device Distinction: Required vs. Recommended

Here's what most teams miss: for some devices, SBOMs are required. For others, they're recommended. The difference comes down to whether your device qualifies as a "cyber device" under Section 524B.

A cyber device meets three criteria: it includes software validated by you as the manufacturer, it has the ability to connect to the internet, and it contains technological characteristics vulnerable to cybersecurity threats.

The "ability to connect" phrase is where confusion starts. FDA is explicit: if your device has the technical capability to connect to the internet through any means at any point, it qualifies. This includes Wi-Fi, Bluetooth, USB ports, ethernet, or serial ports. Even if you never intended internet connectivity, if the capability exists, your device likely qualifies.

For cyber devices, providing an SBOM isn't best practice, it's a requirement under Section 524B(b)(3). Failure to provide it is a prohibited act under Section 301(q) of the FD&C Act.

What FDA Actually Requires

The NTIA minimum elements are table stakes: component name, supplier, version, unique identifier, dependency relationships, and SBOM author. The FDA wants more.

You need the software support level for each component. Is it actively maintained, in maintenance mode, or abandoned? You need end-of-support dates when known. And critically, you must identify vulnerabilities in CISA's Known Exploited Vulnerabilities Catalog, these are vulnerabilities actively being exploited in the wild.

For each known vulnerability, you must describe how it was discovered, provide safety and security risk assessments, and detail your risk controls. The SBOM must be machine-readable (SPDX or CycloneDX format) so it can be queried quickly when new vulnerabilities emerge.

Here's what teams often miss: your SBOM isn't just for FDA. You should make it available to users on a continuous basis. Healthcare facilities need this to manage cybersecurity risks within their own frameworks. When you update components, users need updated SBOM information.

The Right Way vs. The Way Most Teams Do It

Most teams select components based on functionality and developer familiarity, write code for months, then generate an SBOM for the first time during submission prep. That's when they discover a core library reached end-of-life six months ago, or a dependency has critical vulnerabilities, or licensing terms are incompatible with medical device distribution.

The better approach treats component evaluation as a gated decision before adding anything to your codebase. Check the National Vulnerability Database, GitHub Advisory Database, and CISA's Known Exploited Vulnerabilities Catalog. Verify support status and end-of-life timelines. Check licensing. Assess the supplier's security track record. Document this as part of your design rationale.

This isn't about when you generate the SBOM file. It's about when component security becomes part of decision-making.

The Hard Problems Nobody Talks About

Everything above assumes complete visibility into your software supply chain. In practice, you often don't have it.

Third-party software where vendors won't share SBOMs: The solution starts with procurement contracts. Before committing to a vendor's component, your agreement should require SBOM disclosure, not just their SBOM, but SBOMs for components they're using, plus commitments to notify you of vulnerabilities and provide security updates within defined timeframes. If a vendor refuses, that's critical risk information.

Deep dependency trees: Your SBOM must capture "upstream dependencies", the software your software depends on, and that your dependencies depend on. Automated tools can traverse these for common package managers, but they're not perfect. For critical paths where vulnerabilities could directly impact patient safety, manual verification is worth the effort.

Unknown support status: For open-source projects, commit frequency and issue response times serve as proxies for support level. But you may need to document status as "unknown" and make a risk-based decision about acceptability. If it's a critical component with unknown support that you can't replace, that's a risk you're accepting and documenting.

Components you can't replace: You're using a library with a known vulnerability, but no alternative exists, or replacing it requires fundamental architecture changes. You're looking at compensating controls: isolating the vulnerable component, adding authentication layers, implementing exploitation monitoring. Document these in your cybersecurity risk assessment. Communicate residual risk clearly in device labeling.

When you can't provide complete information: If you cannot provide complete SBOM information to FDA, you must justify why. This isn't a free pass, you need a compelling reason and the FDA will assess whether your inability creates unacceptable risk.

What This Actually Prevents

When Log4Shell was announced, teams without SBOMs spent weeks conducting code archaeology, checking every dependency, searching build configurations, hoping they didn't miss anything. Teams with SBOMs queried for Log4j, knew their status in minutes, and focused on remediation instead of discovery.

When a vendor announces component end-of-life, an SBOM gives immediate impact assessment. You know which products are affected and can plan migration as a scheduled update rather than an emergency.

When CISA adds vulnerabilities to its Known Exploited Vulnerabilities Catalog, your SBOM lets you assess impact immediately. These are vulnerabilities being actively exploited. Your response speed could prevent a security incident affecting patient safety.

Getting Started

For new devices, integrate SBOM generation from day one. Choose your format, set up tooling, establish component evaluation including CISA KEV Catalog checks, and make SBOM maintenance part of your definition of done.

For existing devices, start with automated tools to generate a baseline, then manually verify. Focus on components in critical paths. Document support status. Remediate anything in CISA's Known Exploited Vulnerabilities Catalog. Then establish ongoing maintenance so your SBOM stays current.

For cyber devices, remember: SBOM is a legal requirement under Section 524B(b)(3), not optional. For all other software-containing devices, FDA strongly recommends it as part of demonstrating safety and effectiveness.

The teams that handle SBOMs well don't see them as submission paperwork. They see them as operational intelligence that makes software more maintainable, risks more manageable, and FDA submissions more straightforward. Treat your SBOM as living documentation, not a compliance artifact.

Where This Is Headed

The February 2026 guidance update isn't the end of FDA's SBOM requirements. It's the beginning of a broader shift in how medical device cybersecurity is regulated.

By requiring SBOMs for cyber devices and tying them to ISO 13485 configuration management, FDA is moving from "tell us what's in your device" to "show us you can manage what's in your device throughout its lifecycle." This aligns with international regulatory trends. The EU's Medical Device Regulation has similar expectations. Other regulatory bodies are watching FDA's approach.

The teams that will thrive in this environment aren't the ones looking for minimum viable compliance. They're the ones who recognize that SBOM infrastructure solves real operational problems by faster vulnerability response, clearer supply chain visibility, easier security questionnaires, and better risk management.

Build your SBOM processes now while you have time to do it thoughtfully. The regulatory expectations will only increase, and retrofitting is expensive. The question isn't whether you need robust SBOM infrastructure. It's whether you build it proactively or reactively.

The tension between moving fast and staying compliant keeps many MedTech founders awake at night. You need to iterate quickly to stay competitive, but regulatory compliance can't be an afterthought. The good news? Innovation and regulatory compliance in medical device software development don't have to be at odds. With the right approach, you can build groundbreaking products while meeting FDA-compliant software standards from day one.

In this guide, we'll explore practical strategies that help you bridge the gap between rapid innovation and the rigorous requirements of IEC 62304, FDA regulations, and other critical standards. Whether you're building your first SaMD product or scaling an established medical device platform, these insights will help you move faster without compromising safety or compliance.

Why This Balance Matters More Than Ever in 2026

The medical device software landscape has evolved dramatically. Regulatory bodies are paying closer attention to cybersecurity, AI-powered features, and real-world performance data. Meanwhile, patient expectations for intuitive, digital-first experiences continue to rise.

Traditional waterfall development approaches can't keep pace with these demands. Yet regulatory compliance requirements haven't disappeared, they've intensified. The challenge is finding a development methodology that satisfies both innovation timelines and regulatory scrutiny.

Companies that crack this code gain a significant competitive advantage. They bring products to market faster, adapt to user feedback more readily, and maintain compliance without grinding development to a halt.

The Real Tension Points Between Innovation and Compliance

Before we dive into solutions, let's acknowledge where friction typically occurs in medical device software development:

Documentation burden versus development velocity. Every requirement change, design decision, and code modification demands documentation under IEC 62304. This can feel like it doubles or triples development time, especially for teams accustomed to moving fast in unregulated environments.

Risk management overhead. FDA-compliant software requires ongoing risk analysis throughout development. For innovative features, particularly those using AI or novel algorithms, risk assessment can become complex and time-consuming.

Design control requirements. The FDA's design control framework requires formal verification and validation at multiple stages. Agile teams struggle with this structure when they want to ship incremental updates and gather real-world feedback.

Change control processes. In regulated environments, you can't just push updates when you're ready. Every change needs evaluation, approval, and documentation, which conflicts with the rapid iteration cycles that drive innovation.

The key isn't eliminating these requirements, they exist to protect patients. The key is integrating them seamlessly into your development workflow.

Strategy 1: Embrace Agile Within a Compliant Framework

Many teams assume agile methodologies and regulatory compliance are incompatible. They're not. AAMI TIR45 provides explicit guidance for using agile practices in medical device software development while maintaining IEC 62304 compliance.

Start by structuring your sprints around regulatory milestones rather than fighting against them. Map your development phases to IEC 62304 lifecycle activities. For example, your first few sprints might focus on software requirements analysis, while later sprints tackle architectural design and implementation.

Build verification and validation activities directly into each sprint rather than saving them for the end. This "shift-left" approach catches compliance issues early when they're cheaper and easier to fix. It also prevents the dreaded scenario where you complete development only to discover fundamental compliance problems.

Document iteratively using templates and automation tools. Rather than treating documentation as a post-development burden, create living documents that evolve with your code. Modern tools can auto-generate traceability matrices, test reports, and other required artifacts, dramatically reducing manual effort.

The payoff is significant. Teams using compliant agile approaches report 30-40% faster time-to-market compared to traditional waterfall methods, while maintaining full regulatory compliance.

Strategy 2: Implement Risk-Based Development from Day One

Here's a counterintuitive insight: thorough risk management actually accelerates innovation when done correctly. How? By helping you focus resources on what matters most.

Start every project with risk classification. Is your software a Class I, II, or III medical device? This classification determines your regulatory burden. Many teams over-engineer their processes by treating everything as high-risk when a more nuanced approach would suffice.

Use risk levels to prioritize features and allocate resources intelligently. High-risk functions require extensive verification, validation, and documentation. Lower-risk features can move faster with streamlined processes. This tiered approach lets you innovate rapidly in lower-risk areas while maintaining rigor where patient safety demands it.

Build a risk management file that grows with your product. Don't wait until the end to compile risk documentation. Maintain an active risk file that captures hazards, risk controls, and mitigation strategies throughout development. This living document informs design decisions in real-time and keeps regulatory compliance visible to the entire team.

Modern medical device software development requires continuous risk assessment, especially as you add features or respond to cybersecurity threats. Schedule quarterly risk reviews and update your risk management file accordingly. This proactive approach prevents nasty surprises during regulatory submissions.

Strategy 3: Create Modular Architecture That Simplifies Compliance

Your software architecture decisions have massive compliance implications. A well-designed modular architecture can reduce your regulatory compliance burden by 50% or more compared to monolithic systems.

Separate your safety-critical functions from non-critical ones at the architectural level. This isolation means you can innovate rapidly in non-critical areas without triggering full regression testing and re-verification of safety-critical components. Update your user interface freely while your core diagnostic algorithms remain stable and validated.

Use API boundaries to create clear demarcation points between modules. Well-defined interfaces make it easier to verify individual components, simplify change control, and accelerate validation testing. They also enable parallel development streams—different teams can work on different modules simultaneously without stepping on each other's toes.

Consider Software of Unknown Provenance (SOUP) management from the start. Every third-party library and open-source component requires evaluation and documentation under IEC 62304. A modular architecture with clear dependency tracking makes SOUP management far less painful.

Plan for future regulatory changes by building flexibility into your architecture. Requirements will evolve. New cybersecurity standards will emerge. An adaptable architecture lets you respond to these changes without rebuilding from scratch.

Strategy 4: Automate Testing and Verification Processes

Manual testing and verification processes are the enemy of innovation velocity. Automation is your best friend for maintaining FDA-compliant software while moving fast.

Invest in comprehensive automated testing infrastructure early. Unit tests, integration tests, and system tests should run automatically with every code commit. This continuous verification catches problems immediately and provides documentation of testing activities required for regulatory submissions.

Build automated traceability between requirements, code, and tests. Tools that automatically link user requirements to test cases and verification results eliminate hours of manual traceability work. They also make it trivial to demonstrate requirement coverage during regulatory reviews.

Implement continuous integration and continuous deployment (CI/CD) pipelines adapted for regulated environments. Yes, you can use CI/CD in medical device software development, you just need appropriate controls. Automated checks for documentation completeness, code reviews, and verification test passage ensure that only compliant code progresses through your pipeline.

Consider automated static code analysis to catch potential issues before they become problems. Tools that check for security vulnerabilities, coding standard violations, and potential hazards integrate seamlessly into development workflows and reduce manual code review burden.

Strategy 5: Front-Load Regulatory Strategy Planning

The biggest mistake MedTech innovators make is treating regulatory compliance as something to worry about later. By the time "later" arrives, you've made architectural and design decisions that create unnecessary compliance complications.

Engage regulatory experts during concept development, not after you've built a prototype. Early regulatory input helps you identify the optimal regulatory pathway, understand classification implications, and make design decisions that streamline rather than complicate compliance.

Create a regulatory roadmap that runs parallel to your product roadmap. Know which submissions you'll need and when. Understand predicate device selection if you're pursuing 510(k) clearance. Plan for clinical evaluation or performance studies if required. This visibility helps you allocate resources appropriately and avoid last-minute scrambles.

Build relationships with regulatory bodies early when possible. The FDA offers pre-submission meetings that can provide valuable feedback on your approach. These interactions help align expectations and reduce the risk of surprises during formal submissions.

Don't underestimate international regulatory requirements if you plan to sell globally. CE marking under the Medical Device Regulation (MDR), PMDA requirements in Japan, and other international standards add complexity. Factor these into your development strategy from the beginning rather than treating them as afterthoughts.

Here's a strategic consideration many teams overlook: the regulatory pathway you choose first can significantly ease or complicate your journey to other markets. Some companies strategically pursue CE marking before FDA clearance because the MDR's emphasis on clinical evaluation and risk management establishes documentation frameworks that streamline subsequent FDA submissions. Others find that achieving FDA clearance first creates a strong foundation for international expansion, as many regulatory bodies recognize FDA's rigorous standards.

Fun fact (or not): most recently HSBC Venture Healthcare reported the average time for a PMA from their first VC funding until FDA approval was 9.5 years!

Strategy 6: Invest in Team Expertise and Training

Your team is your most valuable asset for balancing innovation and regulatory compliance. Investing in their expertise pays enormous dividends.

Cross-train developers on regulatory requirements so they understand the "why" behind documentation and verification activities. Developers who grasp the patient safety rationale behind IEC 62304 requirements write better code and create better documentation the first time.

Ensure your team includes or has access to regulatory expertise. Whether through full-time regulatory affairs staff, consultants, or fractional resources, having someone who deeply understands FDA requirements, IEC 62304 standards, and submission processes is non-negotiable.

Create a culture that views compliance as a quality advantage rather than a burden. Teams that embrace regulatory rigor as a competitive differentiator build better products and move faster because they catch issues early and maintain clean documentation throughout development.

Stay current with evolving standards and guidance. Cybersecurity requirements, AI/ML regulatory frameworks, and software validation expectations continue to evolve. Regular training and industry engagement keep your team ahead of these changes.

Common Pitfalls to Avoid

Even with solid strategies, certain mistakes can derail your efforts to balance innovation and compliance:

Treating compliance as a checkbox exercise. Going through the motions without understanding underlying principles leads to weak systems that collapse under regulatory scrutiny. Invest in true understanding, not just process compliance.

Underestimating documentation time. Even with automation and templates, proper documentation takes time. Budget 20-30% of development effort for documentation activities and you'll avoid unpleasant surprises.

Skipping early verification activities. Pushing all verification to the end creates massive rework when issues surface late. Integrate verification throughout development for better outcomes and faster progress.

Ignoring cybersecurity until late in development. Medical device cybersecurity is now a critical regulatory focus. Build security in from the start rather than bolting it on later.

Frequently Asked Questions

What is IEC 62304 and why does it matter? IEC 62304 is the international standard for medical device software lifecycle processes. It provides the framework for developing safe, effective medical device software from initial concept through maintenance and retirement. Compliance with IEC 62304 is typically required for FDA submissions and CE marking.

How long does FDA-compliant software development take? Timelines vary significantly based on device classification, risk level, and regulatory pathway. Class II devices pursuing 510(k) clearance typically require 6-12 months of development plus 3-6 months for FDA review. Class III devices with PMA requirements need significantly longer.

Can you use agile methodologies for regulated medical device development? Absolutely. AAMI TIR45 provides specific guidance for applying agile practices while maintaining IEC 62304 compliance, more on this in our post on medical device software development. The key is adapting agile practices to incorporate required verification, validation, and documentation activities throughout development rather than treating them as separate phases.

What's the difference between verification and validation in medical device software? Verification asks "did we build the product right?" by confirming software meets specified requirements. Validation asks "did we build the right product?" by confirming software meets user needs and intended uses. Both are required under FDA design controls and IEC 62304, but they serve different purposes in ensuring safe, effective medical devices.

Why Choose Hattrick IT for Your MedTech Software Development

At Hattrick IT, we specialize in medical device software development that doesn't compromise between innovation and regulatory compliance. We've helped MedTech companies navigate the complexities of IEC 62304, FDA requirements, and international regulatory frameworks while maintaining aggressive development timelines.

Our team brings deep expertise in agile development within regulated environments, using AAMI TIR45 methodologies to deliver FDA-compliant software faster without cutting corners on safety or quality. From initial concept through validation and regulatory submission, we provide comprehensive support that keeps your project moving forward.

Whether you're building a new SaMD product, updating legacy systems to meet current standards, or expanding into international markets, we bring the technical and regulatory expertise you need. Contact us to learn how we can help you bridge innovation and compliance in your next medical device software project.

On February 3, 2026, the FDA quietly reissued its cybersecurity guidance for medical devices. If you're in the middle of a development cycle or preparing for FDA submission, you might be wondering: do I need to change everything I've been working on?

The short answer: probably not.

The longer answer: it depends on whether you were already following the previous version, and whether you understand what actually changed.

What Actually Changed

The February 2026 update to "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" made one primary change: replacing references to the Quality System Regulation (QSR, 21 CFR 820) with the new Quality Management System Regulation (QMSR).

That's it. The core cybersecurity requirements remain the same.

Understanding the QSR to QMSR Shift

In February 2024, the FDA finalized a rule modernizing its quality system requirements by harmonizing with international standards. Specifically, the QMSR incorporates by reference ISO 13485:2016, the internationally recognized standard for quality management systems in medical devices.

This change took effect February 2, 2026—just one day before the cybersecurity guidance update.

What this means in practice:

Instead of following FDA's standalone quality system regulation, manufacturers now need to comply with ISO 13485 as incorporated into 21 CFR Part 820. For cybersecurity, this is significant because ISO 13485 explicitly requires risk management throughout the product lifecycle (Subclause 7.1) and software validation (Subclause 7.3.7).

The updated cybersecurity guidance simply aligns its references and recommendations with this new regulatory framework.

What Stayed the Same (Everything That Matters)

All the substantive cybersecurity requirements from the June 2025 guidance remain in effect:

1. Secure Product Development Framework (SPDF)

The recommendation to use an SPDF, a set of processes that reduce vulnerabilities throughout the device lifecycle, is unchanged. The guidance still recommends frameworks like AAMI TIR45, IEC 81001-5-1, or ANSI/ISA 62443-4-1.

2. Software Bill of Materials (SBOM)

Section 524B of the FD&C Act still requires SBOMs for "cyber devices"—which includes most connected medical devices. The guidance continues to recommend machine-readable SBOMs following NTIA's minimum elements, plus additional information like:

• Software support level (actively maintained, abandoned, etc.)
• End-of-support dates for components
• Known vulnerabilities, including those in CISA's Known Exploited Vulnerabilities Catalog

3. Security Architecture Requirements

The guidance still expects detailed security architecture documentation, including:

• Global system views
• Multi-patient harm views
• Updateability/patchability views
• Security use case views

4. Threat Modeling and Risk Assessment

The requirement for comprehensive threat modeling and security risk assessments separate from (but connected to) safety risk assessments remains fully intact.

5. Cybersecurity Testing

Recommendations for penetration testing, vulnerability scanning, fuzz testing, and other security validation activities are unchanged.

6. The Five Core Security Objectives

Your device still needs to address:

• Authenticity (including integrity)
• Authorization
• Availability
• Confidentiality
• Secure and timely updatability and patchability

Why This Update Matters

Even though the changes are primarily administrative, this update signals something important: the FDA's commitment to international harmonization while maintaining rigorous cybersecurity expectations.

The ISO 13485 Connection

By tying cybersecurity guidance to the QMSR (and therefore ISO 13485), the FDA is making cybersecurity an explicit part of your quality management system—not a separate compliance exercise.

This has practical implications:

Design and Development (ISO 13485 Subclause 7.3): Cybersecurity controls must be integrated into your design inputs, design outputs, design verification, and design validation. You can't bolt on security at the end.

Risk Management (ISO 13485 Subclause 7.1): Your risk management processes must now explicitly address cybersecurity risks alongside traditional safety risks. This means documenting how security threats could lead to patient harm.

Change Management (ISO 13485 Subclause 8.5): When cybersecurity vulnerabilities are discovered post-market, your corrective and preventive action (CAPA) processes must address them systematically.

What This Means for Global Markets

If you're pursuing both FDA clearance and CE marking (or other international regulatory approvals), the alignment with ISO 13485 reduces duplicative work. The quality processes you build for FDA compliance will largely satisfy international requirements.

What You Should Do Now

If You Were Already Following the June 2025 Guidance

Continue what you're doing. Update any internal documentation that references "21 CFR 820" or "QSR" to reference "QMSR" or "ISO 13485" instead, but your actual processes and deliverables remain valid.

Quick checklist:

• ✅ Review your quality procedures for correct regulatory citations
• ✅ Ensure your design and development procedures reference ISO 13485 subclauses
• ✅ Update any submission templates to reference QMSR instead of QSR
• ✅ Verify your risk management process addresses both safety and security

If You Haven't Started Yet

Now is actually a good time to begin. Here's why:

1. The requirements are stable. After multiple iterations (2014, 2023, 2025, and now 2026), the core expectations are well-established. The February 2026 update suggests the FDA isn't planning major substantive changes in the near term.

2. The framework is clear. The guidance provides specific recommendations for what FDA expects in premarket submissions. Use it as a roadmap.

3. Earlier is cheaper. Building security into your architecture from day one is exponentially less expensive than retrofitting it later. We've seen projects spend 4-6 months and hundreds of thousands of dollars fixing security issues discovered mid-development.

Key areas to focus on:

Security Architecture (Start Here): Design your system with security in mind from the beginning. Define trust boundaries, authentication mechanisms, and data flow security before writing code.

Threat Modeling: Identify potential security risks early. This informs your entire development approach and helps you make architecture decisions that reduce vulnerabilities.

SBOM Management: Start tracking your software components now. Don't wait until submission to discover you don't know what's in your product or can't get vulnerability information from third-party suppliers.

Testing Strategy: Plan for security testing throughout development, not just at the end. Include penetration testing, vulnerability scanning, and fuzz testing in your verification and validation plans.

If You're Mid-Development

Assess where you stand against the guidance recommendations:

Gap Analysis Questions:

• Do you have a documented security risk management process separate from your safety risk assessment?
• Can you produce an SBOM for all software components in your device?
• Have you performed threat modeling for your system architecture?
• Do you have documented security architecture views (global system, multi-patient harm, updateability)?
• Have you conducted security testing beyond standard software verification?

If you answered "no" to any of these, address those gaps before submission. FDA reviewers will look for this documentation.

The Bigger Picture: FDA's Quality Management Evolution

This cybersecurity guidance update is part of a broader FDA initiative to modernize its quality system requirements and align with international standards.

What's driving this:

Global Harmonization: By adopting ISO 13485, the FDA is reducing regulatory divergence between markets. This benefits both manufacturers (less duplicative work) and patients (faster access to safe devices globally).

Risk-Based Approach: The QMSR emphasizes risk management throughout the product lifecycle—perfectly aligned with how cybersecurity must be managed. Security risks evolve over time and require continuous monitoring and response.

Modern Development Practices: The updated framework better accommodates agile development, iterative design, and continuous improvement—all essential for medical device software in 2026.

Common Questions

Do I need to resubmit if I received clearance under the old guidance?

No. Devices cleared or approved under previous versions of the guidance remain valid. However, if you submit modifications or new versions, expect FDA to apply current expectations.

Does this affect my postmarket cybersecurity obligations?

No. Postmarket cybersecurity requirements remain as outlined in FDA's "Postmarket Management of Cybersecurity in Medical Devices" guidance. You still need to monitor for vulnerabilities, release patches, and report incidents as appropriate.

What if I'm using a different quality framework than ISO 13485?

The QMSR requires compliance with ISO 13485 as incorporated by reference in 21 CFR 820. If you were previously following only the old Part 820, you'll need to transition to ISO 13485. If you're already ISO 13485 certified, you're ahead of the game.

How does this affect IDE submissions?

The cybersecurity recommendations for IDE submissions (outlined in Appendix 3 of the guidance) remain unchanged. You still need to include cybersecurity risks in informed consent, provide architecture views for safety-critical functionality, and include an SBOM.

What Hasn't Changed: The Challenge Remains the Same

Whether you call it QSR or QMSR, the fundamental challenge hasn't changed: building medical device software that is both innovative and secure, that moves quickly through development while maintaining rigorous documentation, that integrates seamlessly into clinical workflows while defending against sophisticated cyber threats.

The updated guidance doesn't make this easier or harder. It simply reinforces that cybersecurity is not optional, not secondary, and not something you can defer until later in development.

The Path Forward

The February 2026 update is primarily a housekeeping exercise—aligning cybersecurity guidance with the new QMSR framework. But it serves as a useful reminder: FDA expects cybersecurity to be an integral part of your quality management system, not a separate compliance activity.

Three takeaways:

1. If you're already compliant: Keep doing what you're doing. Update your references, but your processes remain valid.
   
   
2. If you're starting now: Use the current guidance as your roadmap. The requirements are stable, the framework is clear, and building security in from the start will save you time and money.
   
   
3. If you're mid-development: Conduct a gap analysis against the guidance recommendations. Address gaps before submission, not during FDA review.
   
   

The good news? The path to FDA cybersecurity compliance is clearer than ever. The challenging news? The bar remains high, and for good reason—patient safety depends on it.

Need Help Navigating FDA Cybersecurity Requirements?

At Hattrick, we're building our quality management system specifically to support secure, compliant medical device software development. We understand both the technical challenges of building secure systems and the regulatory requirements of demonstrating that security to the FDA.

Whether you're just starting development, mid-project and need guidance, or preparing for submission, we can help you build FDA-ready medical device software.

Get in touch: hattrick-it.com/contact

ECRI's recent announcement placing AI chatbot misuse at the top of its 2026 health technology hazards list sent shockwaves through the medtech community. For developers building AI in medical device software, this warning underscores a critical reality: the race to innovate with artificial intelligence must never outpace our commitment to patient safety and regulatory compliance.

The timing of this announcement couldn't be more significant. As AI capabilities expand and healthcare organizations increasingly adopt these technologies, the gap between what AI can do and what it should do in medical contexts has never been more apparent. For medtech companies developing AI-powered solutions, this creates both a challenge and an opportunity to differentiate through responsible, FDA-compliant software development.

In this guide, we'll explore what ECRI's warnings mean for medical device software development teams, how to build AI systems that meet regulatory standards, and the practical steps you can take to ensure your AI-powered medical devices prioritize patient safety above all else.

Understanding ECRI's AI Safety Concerns

ECRI's warning focuses on how AI chatbots generate responses by predicting word sequences based on training data patterns rather than truly understanding medical context. This fundamental limitation has real consequences. The organization documented instances where chatbots suggested incorrect diagnoses, recommended unnecessary testing, promoted subpar medical supplies, and even invented body parts in response to medical questions.

One particularly alarming example illustrates the stakes. When asked about placing an electrosurgical return electrode over a patient's shoulder blade, a chatbot incorrectly stated the placement was appropriate, advice that could have resulted in patient burns.

These aren't theoretical risks. They're documentation of failures happening now, as AI tools proliferate throughout healthcare without adequate oversight or validation. For companies developing AI in medical device software, these examples serve as critical learning opportunities about what can go wrong when AI systems lack proper design controls and regulatory compliance frameworks.

The broader context makes this even more concerning. ECRI notes that higher healthcare costs and hospital closures could drive more people to rely on AI chatbots as substitutes for professional medical advice, potentially amplifying the impact of any safety issues.

Why Most AI Tools Escape Medical Device Regulation

Here's a reality that surprises many developers entering the healthcare AI space: most AI chatbots and healthcare tools currently operate without medical device regulation. They exist in a regulatory gray area that allows deployment without the rigorous verification, validation, and clinical evidence required for FDA-compliant software.

This regulatory gap creates several problems for the industry. First, it sets unrealistic expectations among healthcare providers and patients about what AI can reliably do. Second, it creates competitive pressure on companies trying to build properly regulated AI medical devices, as unregulated alternatives reach the market faster and cheaper. Third, it ultimately undermines trust in AI healthcare technologies when inevitable failures occur.

For developers committed to building responsible AI in medical device software, understanding the difference between unregulated AI tools and properly validated medical device software is crucial. The distinction comes down to intended use, claims, and risk classification.

If your AI system diagnoses conditions, recommends treatments, or influences clinical decision-making, you're likely developing a medical device that requires FDA clearance or approval. If your system provides general health information without specific clinical recommendations, you might fall outside medical device definitions, but that doesn't eliminate your ethical obligation to ensure accuracy and safety.

The Regulatory Framework for AI Medical Devices

The FDA has been working to establish clearer frameworks for AI and machine learning in medical devices, but the landscape remains complex and evolving. Understanding current regulatory expectations is essential for any team building AI in medical device software.

The FDA's approach to AI medical devices centers on several key principles. First, risk-based classification determines your regulatory pathway. AI systems that pose higher risks to patients face more stringent requirements. Second, the agency distinguishes between "locked" algorithms that don't change after deployment and "adaptive" algorithms that continue learning from new data.

For most AI medical device developers, the 510(k) pathway offers the most practical route to market, requiring demonstration that your AI system is substantially equivalent to a legally marketed predicate device. However, De Novo classification provides another option for novel AI technologies without appropriate predicates.

Software as a Medical Device (SaMD) guidance applies to many AI applications, establishing expectations for documentation, risk management, and clinical evaluation. Your medical device software development process must demonstrate how you've addressed potential AI-specific risks, including algorithmic bias, data quality issues, and model drift over time.

Regulatory compliance for AI medical devices demands robust documentation of your training data, model architecture, validation methodology, and performance metrics across diverse patient populations. You need to show not just that your AI works, but that you understand why it works and can predict when it might fail.

Building Trust Through Transparent AI Development

ECRI's Dr. Marcus Schabacker emphasized that while chatbots are powerful tools, algorithms cannot replace the expertise, education, and experience of medical professionals. This principle should guide every aspect of AI medical device design.

Transparency starts with honest communication about what your AI can and cannot do. Resist the temptation to oversell capabilities or downplay limitations. Clear documentation of your AI's intended use, training data sources, and performance boundaries builds trust with regulators, clinicians, and patients.

Consider implementing explainable AI approaches that help users understand how your system reaches its conclusions. Black box algorithms that provide recommendations without rationale create risks in medical contexts where understanding the reasoning behind clinical decisions matters enormously.

Build human oversight into your system design from the beginning. AI should augment clinical decision-making, not replace it. Design workflows that keep qualified healthcare professionals in the loop for critical decisions, with your AI serving as a decision support tool rather than an autonomous decision maker.

Address algorithmic bias proactively through diverse training data and systematic testing across different patient demographics. ECRI warns that biases embedded in training data can distort how models interpret information, leading to responses that reinforce stereotypes and inequities. This isn't just an ethical concern but a regulatory one, as the FDA increasingly scrutinizes bias and generalizability in AI medical devices.

Essential Development Practices for Safe AI Medical Devices

Building FDA-compliant software with AI components requires disciplined engineering practices that may differ from typical AI development approaches. The stakes in medical device contexts demand rigor that goes beyond achieving impressive accuracy metrics in controlled testing.

Start with comprehensive requirements analysis that addresses not just functional performance but also safety requirements, edge cases, and failure modes. Your AI system needs defined operating boundaries, situations where it should decline to provide output rather than risk an unreliable prediction.

Implement robust data management practices that ensure training and validation data quality, representativeness, and traceability. Document data sources, preprocessing steps, and any exclusions or transformations. This documentation becomes critical during regulatory submissions and post-market surveillance.

Establish verification and validation protocols specifically designed for AI systems. Traditional software testing approaches don't fully capture AI-specific risks. You need validation strategies that assess performance across diverse patient populations, evaluate robustness to input variations, and test behavior at the boundaries of your training data distribution.

Create monitoring systems that track your AI's real-world performance after deployment. Unlike traditional software where bugs are relatively deterministic, AI systems can experience degraded performance as real-world data distributions shift from training data. Continuous performance monitoring enables early detection of problems before they impact patient safety.

Build version control and traceability into your AI development pipeline. You need to know exactly which model version is deployed where, what data trained it, and how it performed during validation. This traceability proves essential for regulatory compliance and post-market surveillance.

Risk Management for AI Medical Devices

Traditional medical device risk management under ISO 14971 provides the foundation, but AI introduces unique hazards that demand special attention in your risk analysis. Your risk management file needs to address AI-specific failure modes that wouldn't occur in conventional software.

Consider risks from training data issues, including insufficient data, biased data, or data that doesn't represent your intended use population. Each of these can cause your AI to perform poorly in real-world deployment despite strong validation results.

Address risks from model limitations, including tendency to overfit training data, sensitivity to input variations, and inability to recognize out-of-distribution inputs. Your risk controls should include strategies for detecting when inputs fall outside your model's reliable operating range.

Evaluate cybersecurity risks specific to AI systems, including adversarial attacks designed to fool your model and data poisoning attempts that could corrupt training data. As AI medical devices become more prevalent, they become more attractive targets for bad actors.

Document risks from over-reliance on AI outputs by clinicians or patients. Even accurate AI systems create risks if users trust them too much and fail to apply appropriate clinical judgment. Your instructions for use and training materials should reinforce the AI's role as a decision support tool.

Preparing for Post-Market Surveillance and Updates

One of the most challenging aspects of AI medical device regulation involves post-market responsibilities. Your regulatory compliance obligations don't end when you receive FDA clearance; they intensify as you gather real-world performance data.

Establish systems for collecting and analyzing field performance data that can detect degradation in AI performance over time. Changes in patient populations, evolving clinical practices, or drift in input data characteristics can all impact your AI's real-world effectiveness.

Plan for a predetermined change control protocol that the FDA increasingly expects for adaptive AI systems. If your algorithm will learn from new data post-deployment, you need pre-specified processes for validating updates, controlling changes, and notifying the FDA when modifications exceed predefined bounds.

Create feedback mechanisms that enable healthcare providers to report concerns or unexpected AI behaviors. This qualitative feedback often provides early warning of problems that quantitative metrics might miss.

Document everything throughout post-market surveillance. If issues arise requiring corrective actions, you need comprehensive records showing what you knew, when you knew it, and what actions you took. This documentation protects both patient safety and your company's regulatory standing.

Common Pitfalls to Avoid in AI Medical Device Development

Even experienced medical device developers stumble when adding AI to their products. Recognizing common mistakes helps you avoid them.

Treating AI development like traditional software development. AI systems require different verification approaches, different risk management considerations, and different post-market monitoring. Your quality management system needs AI-specific procedures.

Optimizing for performance metrics without considering clinical utility. An AI that achieves 95% accuracy on a validation dataset isn't necessarily clinically useful if those 5% errors occur in critical situations or if users can't effectively integrate it into clinical workflows.

Insufficient attention to training data quality and documentation. Your training data represents a critical component of your medical device. Treat it with the same rigor you'd apply to source code, with version control, quality checks, and comprehensive documentation.

Neglecting edge cases and failure modes. AI systems can fail in surprising ways, particularly when encountering inputs unlike their training data. Robust testing includes adversarial examples and systematic exploration of boundary conditions.

Inadequate communication about limitations. Be explicit about what your AI cannot do, situations where it may perform poorly, and appropriate uses. Overpromising on capabilities creates both safety risks and regulatory problems.

Frequently Asked Questions

Does my AI healthcare tool need FDA clearance? It depends on your intended use and claims. If your AI diagnoses conditions, guides treatment decisions, or otherwise functions as a medical device, FDA oversight likely applies. The FDA provides guidance on determining whether software functions as a medical device, but when in doubt, consulting with regulatory experts early in development saves time and prevents costly mistakes.

How long does FDA clearance take for AI medical devices? For 510(k) submissions, expect 3-6 months for FDA review after submission, though the clock stops whenever the FDA has questions requiring additional information. Total time from development start to clearance typically spans 12-18 months for well-planned projects. De Novo pathways and PMA submissions require significantly longer timelines.

Can AI medical devices continue learning after FDA clearance? Yes, but with important limitations. The FDA has established frameworks for predetermined change control plans that allow certain types of updates and adaptations without new submissions. However, these require pre-specification of modification boundaries and validation approaches. Unlimited, uncontrolled learning post-clearance isn't currently acceptable.

What makes AI risk management different from traditional medical device risk management? AI introduces unique failure modes related to training data quality, algorithmic bias, model overfitting, and performance degradation over time. Traditional risk management focuses on hardware failures and software bugs; AI risk management must also address statistical uncertainty, data distribution shifts, and emergent behaviors not easily predicted from code review.

At Hattrick IT, we understand that building AI in medical device software requires balancing innovation with patient safety and regulatory compliance.

We can help you navigate the complexities of FDA-compliant software development for AI applications. From initial concept through regulatory submission and post-market surveillance, we provide the perfect mix of technical excellence and regulatory knowledge you need to bring safe, effective AI medical devices to market.

Our approach integrates AI development best practices with medical device quality systems, ensuring your innovation meets both performance goals and regulatory requirements.

Whether you're adding AI capabilities to an existing medical device, building a new AI-powered SaMD product, or updating your AI system to address new regulatory guidance, we deliver the expertise that bridges innovation and compliance.

For medical device companies developing softPostsware-driven products, verification and validation (V&V) often feels like navigating a maze of regulatory requirements, testing protocols, and documentation demands. Yet V&V represents far more than a compliance checkbox, it's the systematic process that demonstrates your software does what it's supposed to do and actually meets user needs in real-world clinical settings.

Whether you're building standalone Software as a Medical Device (SaMD) or embedded software for a diagnostic instrument, understanding how to structure V&V activities can mean the difference between a smooth FDA submission and months of costly delays. This guide breaks down what teams need to know about software V&V, from planning through submission-ready documentation.

What Does the FDA Expect from Software V&V?

The FDA's guidance on software validation emphasizes that verification and validation are distinct but complementary activities throughout the software development lifecycle. Understanding this distinction is fundamental to building an effective V&V strategy.

Verification answers the question: "Are we building the product right?" It confirms that software outputs from each development phase meet the inputs and requirements for that phase. Verification activities include code reviews, unit testing, integration testing, and requirements traceability. You're essentially checking that the implementation matches the design specifications.

Validation addresses: "Are we building the right product?" It ensures the final software product meets user needs and intended use requirements in the actual environment where it will be deployed. Validation happens at the system level and includes activities like user acceptance testing, clinical validation studies, and human factors validation.

The FDA's expectations for V&V rigor scale with software risk classification. For Class III devices or moderate-risk Class II software, expect comprehensive documentation including detailed test protocols, traceability matrices linking requirements to tests, and formal validation reports. Lower-risk devices may warrant a more streamlined approach, but the fundamental V&V principles remain constant.

IEC 62304, the international standard for medical device software lifecycle processes, provides the framework most teams follow. The standard requires V&V planning before development begins, defines specific activities for each software safety class, and mandates traceability throughout. FDA reviewers increasingly expect submissions to demonstrate IEC 62304 compliance, making it the de facto roadmap for medical device software development.

How V&V Fits into the IEC 62304 Software Lifecycle

IEC 62304 structures software development into distinct phases, each with corresponding V&V activities that build upon one another. Understanding this progression helps teams plan resources and avoid the common trap of treating V&V as an afterthought.

Planning Phase: Before writing a single line of code, you'll develop your Software Development Plan and Software Verification and Validation Plan. These documents define your development approach, V&V strategy, risk management activities, and documentation standards. The V&V plan specifies which verification methods you'll use (code reviews, static analysis, unit tests), validation approaches (system testing, user studies), and acceptance criteria for each phase.

Requirements Phase: Software requirements must be verified to ensure they're complete, unambiguous, and testable. Verification activities include requirements reviews, traceability to system requirements and risk controls, and establishing test conditions. This is where you create your traceability matrix that will follow the product through submission.

Architectural and Detailed Design Phase: Design verification confirms that your architecture addresses all requirements and that detailed designs correctly implement the architecture. Activities include design reviews, interface verification, and SOUP (Software of Unknown Provenance) evaluation for third-party components.

Implementation Phase: Unit-level verification happens during coding through peer reviews, static code analysis, and unit testing. For higher safety classes, you'll need documented evidence of these activities with defect tracking and resolution. Integration testing verifies that software units work together correctly according to the architectural design.

System Testing Phase: This is where verification transitions into validation. System testing verifies that integrated software meets all software requirements. System validation demonstrates that the complete medical device (software plus hardware if applicable) meets user needs and intended use requirements in representative conditions.

Throughout each phase, you're building a documentation trail that demonstrates systematic development and risk management, which is exactly what FDA reviewers need to see during premarket review.

Practical V&V Activities for SaMD vs Embedded Software

While V&V principles apply universally to medical device software, practical implementation differs significantly between standalone Software as a Medical Device and embedded software systems.

SaMD V&V Considerations: For cloud-based diagnostic tools, mobile health applications, or clinical decision support software, your V&V strategy must address cybersecurity, interoperability, and diverse deployment environments. Testing includes validating software across multiple operating systems, browsers, or mobile platforms. Network security testing, data encryption verification, and authentication/authorization testing become critical verification activities. You'll need documented evidence that the software performs consistently across all claimed environments and maintains data integrity throughout the intended workflow.

Performance testing takes on added importance for SaMD, you're not just verifying algorithmic accuracy but also demonstrating acceptable response times, scalability under realistic patient loads, and graceful handling of network disruptions or data anomalies.

Embedded Software V&V: For software embedded in medical devices like infusion pumps, imaging systems, or patient monitors, V&V must account for hardware-software integration, real-time performance requirements, and often safety-critical failure modes. Hardware-in-the-loop testing verifies that software correctly controls physical actuators and processes sensor inputs. Timing analysis confirms that real-time software meets deadline requirements. Failure mode testing validates that software responds appropriately to hardware faults, power interruptions, or environmental conditions.

Regardless of software type, risk-based testing depth is essential. IEC 62304 defines three software safety classes (A, B, C) based on the potential for software failure to result in harm. Class C software requires the most rigorous V&V, including complete requirements traceability, comprehensive unit testing, and extensive system validation. Class A software, where failure cannot contribute to a hazardous situation, allows a more streamlined approach focused on system-level validation.

Your test strategy should explicitly tie test depth and methods to risk analysis. High-risk software functions demand more exhaustive testing, boundary condition analysis, and fault injection testing. Lower-risk features can be verified through sampling or reduced test cases, provided your rationale is documented.

How We Document V&V for FDA and CE Submissions

FDA and Notified Body reviewers need clear evidence that your V&V activities were planned, executed systematically, and demonstrated acceptable results. This documentation forms a critical component of your 510(k), De Novo, PMA, or CE technical file.

Test Protocols: Before executing V&V activities, you'll create test protocols that specify test objectives, test configurations, test cases with expected results, pass/fail criteria, and procedures. Protocols should be reviewed and approved before testing begins. Each test case traces back to specific requirements, creating the bidirectional traceability that regulators expect.

Test Reports: After test execution, formal test reports document test results, any deviations or anomalies observed, defect tracking, and final acceptance conclusions. Reports must be signed by appropriate personnel, typically the test engineer and quality representative. Any test failures require documented investigation, corrective action, and confirmation of resolution through retesting.

Traceability Matrices: Perhaps the most critical V&V documentation, traceability matrices link system requirements to software requirements, software requirements to design elements, design elements to source code modules, and requirements to verification tests and validation activities. This web of traceability demonstrates that every requirement has been implemented and verified, and that every test traces to specific requirements. Modern tools can automate much of this traceability, but the relationships must be carefully maintained as requirements evolve.

Defect Management: All defects discovered during V&V must be logged, classified by severity, investigated for root cause, and tracked through resolution. Your defect management process demonstrates that issues were systematically addressed and that fixes were verified effective without introducing new problems. Regulatory submissions typically include defect summaries showing types of defects found, resolution approaches, and any known anomalies or limitations in the released software.

Software Version Documentation: Your V&V documentation package must clearly identify which software version was validated, including version control information, configuration management records, and SOUP/OTS component versions. This enables regulators to understand exactly what was tested and confirmed.

For 510(k) submissions, this V&V documentation typically appears in the Software Description Document or as supporting documentation demonstrating substantial equivalence. For CE marking, the technical file must include comprehensive V&V documentation as evidence of conformity to essential requirements and harmonized standards.

Common V&V Mistakes in MedTech Startups (and How to Avoid Them)

Even experienced medical device teams encounter predictable V&V pitfalls that can derail submissions or create expensive remediation cycles. Here are the most common mistakes and practical strategies to avoid them.

Starting V&V Too Late: The most costly mistake is treating V&V as a post-development activity. When teams build software first and then try to retrofit V&V documentation, they discover untested requirements, missing traceability, and insufficient verification evidence. Instead, establish your V&V plan before development begins, create test cases alongside requirements, and verify incrementally throughout development.

Inadequate Requirements Traceability: Losing track of the relationships between requirements, design, code, and tests creates massive problems during submission preparation. Implement traceability from day one using tools or rigorous documentation practices, and maintain it as requirements evolve. Every requirement change should trigger evaluation of affected design, code, and tests.

Insufficient Test Coverage Documentation: Running tests isn't enough, you must document test coverage and demonstrate that coverage is appropriate for the software's risk classification. For Class B and C software, expect reviewers to scrutinize whether your testing adequately addresses high-risk functions, edge cases, and failure modes. Maintain coverage metrics and document rationale for areas with reduced testing.

Weak Validation Evidence: Verification alone isn't sufficient. FDA reviewers want to see that you validated software with representative users in realistic conditions that approximate the intended use environment. This doesn't always require full clinical studies, but you need documented evidence that the software meets user needs. User acceptance testing, formative usability studies, or validation studies with clinical partners provide this evidence.

Inadequate SOUP Management: Third-party libraries, open-source components, and commercial off-the-shelf software require specific V&V attention. Teams often fail to adequately document SOUP identification, evaluate SOUP risks, verify SOUP functionality, and maintain SOUP configuration records. Create a SOUP inventory early, assess each component's risk contribution, and verify that SOUP functions critical to your device work correctly.

Poor Change Management: As software evolves through development and after initial release, V&V must address changes systematically. Implement regression testing strategies, maintain impact analysis for changes, and update V&V documentation to reflect the current software version. FDA increasingly scrutinizes whether post-market software updates have been adequately validated.

At Hattrick, we structure V&V from the ground up so it supports smoother submissions rather than becoming a last-minute scramble. Our team brings expertise in IEC 62304 software lifecycle processes, risk-based development approaches, and the specific documentation requirements that reviewers expect. If you’d like to learn more or discuss different V&V approaches don’t hesitate to reach out to us.

The medtech sector continues its rapid evolution, with digital innovation reshaping how medical devices are designed, manufactured, and deployed. As this transformation accelerates, staying informed about breakthrough technologies and industry shifts has become critical for professionals seeking to maintain their competitive edge. Success in this industry requires deliberate engagement with the latest developments, emerging methodologies, and innovative solutions.

Attending premier industry conferences remains one of the most valuable ways to stay ahead of the curve. These gatherings provide direct access to pioneering technologies, thought leadership, and meaningful professional connections. We've carefully compiled this guide to the most impactful medical device and MedTech conferences happening in 2026, organized chronologically with detailed insights into why each event deserves your attention, including our standout recommendations for the year ahead.

MD&M WEST 2026

Feb 3-5, 2026 | Anaheim, CA

As the leading medical device exhibition in North America, MD&M West continues to draw over 14,000 participants and 1,600+ exhibiting companies annually. This cornerstone event showcases breakthrough innovations across medical devices, digital health platforms, hospital infrastructure, cardiovascular technologies, and pharmaceutical solutions. MD&M West fosters collaboration that drives healthcare forward and delivers measurable improvements in patient care worldwide. Hattrick considers this a must-attend event for 2026.

LSI Emerging Medtech Summit - Hattrick Favorite!

Mar 18-22, 2026 | Monarch Beach, CA

Join the LSI Emerging Medtech Summit this March for unparalleled access to early-stage investment opportunities and strategic partnerships. Designed for innovative medtech, healthtech, and digital health ventures, this Life Science Intelligence (LSI) gathering brings together industry visionaries committed to healthcare transformation. The Monarch Beach setting provides an ideal backdrop for meaningful connections.  

DeviceTalks

May 27-28, 2026 | Boston, MA

DeviceTalks serves as the definitive meeting place for MedTech professionals dedicated to pushing the boundaries of medical device innovation. With 1,600+ engaged participants, this Boston event connects you with funding sources, showcases emerging technologies, and provides the momentum needed to bring your next device breakthrough to market.

MedTech World North America

May 11-13, 2026 | West Palm Beach, FL

MedTech World North America brings together the entire healthcare innovation ecosystem at one of the industry's fastest-growing conferences. This three-day summit attracts 2,000+ attendees including startup founders, investors, healthcare leaders, and service providers from over 50 countries. The event features 300+ speakers, curated 1:1 matchmaking through their MedTech Match platform, startup pitch competitions, and the prestigious MedTech Awards Night. Positioned uniquely at the intersection of media, events, and capital, MedTech World creates unparalleled opportunities for meaningful connections and strategic partnerships. We haven't attended before but it's on our radar this year!

AAMI Exchange

May 29- June 1 | Denver, CO

AAMI eXchange stands as the world's most comprehensive healthcare technology management exhibition. This essential event provides unmatched access to health technology systems, products, and services that are shaping the future of healthcare delivery and patient safety.

FIME

Jun 17-19, 2026 | Miami, FL

The Florida International Medical Expo returns to Miami Beach Convention Center in June 2026, welcoming 13,000+ healthcare professionals from over 116 countries alongside 1,158+ exhibitors. FIME provides an unmatched international stage for networking, knowledge exchange, and business development across the healthcare spectrum. This event ranks among Hattrick's top recommendations for medical device conferences in 2026.

MEDevice Boston

August 26-27, 2026 | Boston, MA

This premier medical device exposition brings together engineers, technology executives, and innovators in the nation's third-largest MedTech hub. MEDevice Boston accelerates product development timelines, delivers crucial regulatory guidance, and facilitates vital OEM partnerships—all within a focused, efficient format designed for breakthrough collaboration.

MedTech Conference - Hattrick Favorite!

Oct 18-21, 2026 | San Diego, CA

The MedTech Conference delivers exceptional networking opportunities for industry executives and decision-makers. This fall gathering convenes global leaders, policy experts, and pioneers from across medtech specialties. Expect world-renowned speakers and exposure to transformative technologies that will define the industry's future.

American Medical Device Summit

Oct 26-27, 2026 | Chicago, IL

This executive-focused summit brings together 250+ medical device leaders to explore frontier innovations in wearables, robotics, and artificial intelligence. Participants gain strategic perspectives through expert presentations covering product development approaches, regulatory navigation, and international MedTech market dynamics.

MD&M Minneapolis

Oct 21-22, 2026 | Minneapolis, MN

Part of Advanced Manufacturing Minneapolis, MD&M Minneapolis represents the premier medical design and manufacturing gathering for the region. Situated in Medical Alley—a recognized healthcare innovation corridor—this conference delivers exceptional networking with medtech pioneers while highlighting Minnesota's unique capacity to advance healthcare through technological innovation and specialized talent. This promises to be one of the standout medical device conferences of 2026.

MEDevice Silicon Valley

Nov 19-20, 2026 | Silicon Valley, CA

BIOMEDevice Silicon Valley assembles 1,200 professionals and 170 exhibiting companies to examine the latest medical device breakthroughs. Featuring 40+ industry authorities delivering educational content and facilitating networking opportunities, this conference provides comprehensive perspectives on the advancing medical technology ecosystem.

The medical device sector shows no signs of slowing its innovation trajectory. Technological advancement and an unwavering commitment to enhanced patient outcomes continue to propel the industry forward. The MedTech conferences featured in this guide represent exceptional opportunities for industry professionals to remain current with emerging capabilities and market developments. Each gathering provides distinct insights into medical technology progress, spanning next-generation devices to digital health breakthroughs.

For professionals committed to leading rather than following in medical device innovation, these MedTech conferences deliver the strategic relationships and industry intelligence essential for navigating an increasingly sophisticated marketplace.

We've highlighted several events where Hattrick team members may be present throughout 2026. Which conferences are on your calendar for the year ahead? Share your plans in the comments or reach out to explore potential collaboration opportunities!

The pace of change in health technology keeps accelerating — from AI-enabled clinical workflows to XR-infused care delivery and predictive analytics reshaping patient outcomes. For professionals in MedTech, digital health, and healthcare strategy, conferences are far more than networking stops — they’re launchpads for insight, partnership, investment, and real transformation.

To help you navigate a bustling 2026 events calendar, we’ve gone beyond dates and venues to highlight gatherings that deliver strategic value — places where thought leadership, product innovation, market trajectory, and real business outcomes intersect.

Whether you’re a startup founder, a digital health executive, a MedTech engineer, or an investor scouting trends and deals, here’s where the industry will be thinking big in 2026.

CES

📍Las Vegas • January 6-9

This is the biggest consumer tech event. It’s where global brands get business done, meet new partners and where the industry's sharpest minds take the stage to unveil their latest releases and boldest breakthroughs. Digital Heal is one of their biggest summits. This is one of the top healthcare conferences of 2025.

JPM Healthcare conference

📍San Francisco, CA • January 12-15

The J.P. Morgan Healthcare Conference is the world’s largest and most influential healthcare investment symposium. Now in its 44th year, this invitation-only gathering brings together global industry leaders, emerging growth companies, innovators, investors, and policymakers across biotech, pharma, digital health, MedTech, and healthcare services.

Why it matters: Your only option isn’t scoring an elusive invite, there are a ton of side events around the city during the whole week!

ViVE 2026

📍 Los Angeles, USA • February 22–25, 2026

ViVE has rapidly become a pivotal event for healthcare executives and digital leaders. Learning, curated business match-making, and real-world case studies on interoperability, AI implementation, and operational transformation are key themes.

Why it matters: an ecosystem approach tailored to interoperability strategies, digital first care, and real deal-making beyond buzzwords.

Health.Tech Global Summit

📍 Basel, Switzerland • March 3–5, 2026

A major destination for European and global health innovation leaders. health.tech brings together policymakers, investors, system leaders, pharma, and startups to advance digital transformation, decentralized care delivery, consumer health, and data-driven healthcare.

Why it matters: strategic cross-sector dialogue, regulatory insight, deep digital health conversations with Europe’s life sciences hub as a backdrop.

HIMSS Global Health Conference & Exhibition

📍 Las Vegas, NV • March 9–12, 2026

A perennial leader in health IT and transformational strategy. From interoperability and governance to digital infrastructure scaling, HIMSS is the backbone event for healthcare technology leaders.

Why it matters: deep technical content + strategic frameworks to bridge innovation and execution.

Pharma USA 2025

📍March 18-19 • Philadelphia, PA

For over two decades, Reuters Pharma USA has served as a cornerstone gathering for leaders across pharma, biotech, commercialization, market access, and patient strategy. The 2026 edition continues that legacy with a program built around interactive discussions, practical frameworks, and forward-looking insights.

Why it matters: Brings together the full pharmaceutical value chain

Women’s Health Week

📍 New York, NY • May 13–14, 2026

A pivotal gathering for leaders and innovators in women’s health innovation. Hosted at the New York Academy of Medicine in Manhattan, this two-day summit brings together founders, investors, multinationals, policymakers, clinicians, and tech innovators with a shared mission: to accelerate solutions that close gaps in women’s health outcomes and unlock commercial opportunities across the ecosystem.

Why it matters: The program blends expert panels, startup showcases, strategic workshops, and curated networking sessions

Digital Health World Congress

📍 London, UK • May 26–27, 2026

A European hub for digital health innovation with a program focused on AI in MedTech, real-world data, chronic care management, and digital ecosystems.

Why it matters: strong global speaker lineup and actionable insight on market adoption and next-generation care models.

HLTH 2026

📍 Las Vegas, NV • November 15-18, 2026

HLTH has firmly established itself as the premier healthcare innovation conference; the place where the entire health ecosystem comes together to set the agenda for what’s next. Each year, it draws an unmatched mix of executives, startups, payers, providers, life sciences leaders, investors, policymakers, and tech giants, all converging to discuss the trends, technologies, and business models shaping the future of care.

Why it matters: Signature blend of big-stage keynotes, deep-dive tracks, product showcases, curated networking, investor–startup matchmaking, and ecosystem-wide collaboration

6th Digital Health Conference

📍 Barcelona, Spain • November 25–26, 2026

A deep dive into digital transformation in pharma and digital therapeutics, regulatory trends, data-enabled care models, and cross-industry collaboration.

Why it matters: tailored conversations on digital therapeutics, regulatory strategy, and patient-centric innovation.