Supplier management for SaMD and AI medical devices: the invisible supply chain
Software companies often overlook the fact that they operate a supply chain. Because they do not deal with physical factories, raw material shipments, vial suppliers, or sterilisation facilities, identifying their supply network can feel non-obvious when no tangible goods are being moved.
A closer look at any Software as a Medical Device (SaMD) product quickly reveals its underlying supply chain. You might rely on a third-party software agency to write code, a cloud supplier for hosting, open-source or commercial libraries in your codebase, an underlying operating system, external QA services, cybersecurity utilities, regulatory advisors, and data providers for training or validating AI models. That is quite an extensive list, and your actual Approved Supplier List may be even broader. Each of these external contributors can directly impact the quality of your SaMD.
This rapid rate of change makes supplier management critical for medical device software. Unlike physical parts, such as a batch of cogs that remain constant until wearing down predictably over time, software components evolve dynamically. The API contracts of cloud services and third-party libraries can shift beneath your application almost instantaneously.
It is doubtful that any business operates entirely without a supply chain. The central question is identifying what that supply chain comprises and how effectively it is governed. While tracking suppliers and managing relevant controls might seem daunting, establishing proper oversight requires only a clear structure rather than an overwhelming effort.
You can outsource the activity but the manufacturer's responsibility stays with you.
Case study: On March 24, 2026, an attacker breached maintainer credentials for LiteLLM – a popular free package many developers use to track LLM usage. Malware (a 'credential harvester') was introduced into the package, and all other packages that pulled latest ('unpinned') LiteLLM as a dependency began to infect their users with this malware.
In the course of developing regular software products, we rarely care about the concept of 'responsibility'. Let's consider the LiteLLM breach. Who was responsible? LiteLLM – for not keeping their library safe? Developers who included LiteLLM into their packages – for compromising their users? The users – for not validating every dependency of every package they use? At the end of the day, no one was really held responsible in any interpretation of this word. In the general unregulated software industry, people believe in 'moving fast and breaking things', as goes the famous motto said to have been coined by Mark Zuckerberg for Facebook.
This is not the case in SaMD. If a device harms a patient, or leads to compromise of their personal data, or otherwise breaches patient trust, someone is always responsible. That someone is the medical device manufacturer, regardless of whose fault ultimately led to an incident. If another company develops half your software, hosts your application or performs verification testing, that does not turn them into a medical device manufacturer – the responsibility stays with you. No pressure. The good news is that fulfilling this responsibility is not as hard as it may sound – more on that in the next section. Below in the rest of this section you can see exactly what and who places this responsibility on the manufacturer, and enjoy the original legalese if you are so inclined.
The international standard for quality management of medical devices ISO 13485 deals with the concept of responsibility directly. Where an organisation outsources a process affecting product conformity, it remains responsible for conformity and must maintain control over the outsourced process. The extent of that control should be proportionate to the risk and to the external party's ability to meet the relevant requirements.
Or, in simpler words: if you outsource a part of the development, manufacture or deployment (logistics) of your device, you have to keep your eyes on the outsourced work. How many eyes exactly you have to keep open depends on how likely a failure of your contractor is to harm the end user.
In the EU, this is not only an ISO 13485 point. The MDR and IVDR require the manufacturer's QMS to address the selection and control of suppliers and subcontractors.
The clauses: what each standard and regulation requires on suppliers Click to expand Click to collapse
| Standard / regulation | Requirement |
|---|---|
| BS EN ISO 13485:2016+A11:2021 |
§4.1.5 General requirements
When the organisation chooses to outsource any process that affects product conformity to requirements, it shall monitor and ensure control over such processes. The organisation shall retain responsibility of conformity to this International Standard and to customer and applicable regulatory requirements for outsourced processes. The controls shall be proportionate to the risk involved and the ability of the external party to meet the requirements in accordance with 7.4. The controls shall include written quality agreements. §7.4.1 Purchasing process
The organisation shall document procedures (see 4.2.4) to ensure that purchased product conforms to specified purchasing information. The organisation shall establish criteria for the evaluation and selection of suppliers. The criteria shall be:
The organisation shall plan the monitoring and re-evaluation of suppliers. Supplier performance in meeting requirements for the purchased product shall be monitored. The results of the monitoring shall provide an input into the supplier re-evaluation process. Non-fulfilment of purchasing requirements shall be addressed with the supplier proportionate to the risk associated with the purchased product and compliance with applicable regulatory requirements. Records of the results of evaluation, selection, monitoring and re-evaluation of supplier capability or performance and any necessary actions arising from these activities shall be maintained (see 4.2.5). §7.4.2 Purchasing information
Purchasing information shall describe or reference the product to be purchased, including as appropriate:
The organisation shall ensure adequacy of specified purchasing requirements prior to their communication to the supplier. Purchasing information shall include, as applicable, a written agreement that the supplier notify the organisation of changes in the purchased product prior to implementation of any changes that affect the ability of the purchased product to meet specified purchase requirements. To the extent required for traceability given in 7.5.9, the organisation shall maintain relevant purchasing information in the form of documents (see 4.2.4) and records (see 4.2.5). §7.4.3 Verification of purchased product
The organisation shall establish and implement the inspection or other activities necessary for ensuring that purchased product meets specified purchasing requirements. The extent of verification activities shall be based on the supplier evaluation results and proportionate to the risks associated with the purchased product. When the organisation becomes aware of any changes to the purchased product, the organisation shall determine whether the changes affect the product realisation process or the medical device. When the organisation or its customer intends to perform verification at the supplier’s premises, the organisation shall state the intended verification activities and methods of product release in the purchasing information. Records of the verification shall be maintained (see 4.2.5). |
| BS ISO/IEC 27001:2023+A1:2024 |
Annex A Information security controls reference
|
| EU MDR Article 10(9) / EU IVDR Article 10(8) |
The quality management system shall address at least the following: (d) resource management, including selection and control of suppliers and sub-contractors; |
Note: Notified Bodies may also go beyond the manufacturer's own premises. Under the MDR and IVDR conformity assessment provisions, supplier and subcontractor premises can be included in QMS audits where appropriate, including unannounced audits.
Who actually counts as a SaMD supplier?
Important aside – who even counts as a supplier? With a physical device, the answer is usually reasonably intuitive – whoever ships you ‘the box’ is the supplier. With software, it is less obvious. A software development agency is an easy one; they sell you a ‘unit of software’ in exchange for a payment, with terms specified in a contract. A company running testing on your behalf (QA supplier) is another easy one. Cloud hosting is also fairly straightforward if your device depends on the hosted service for its operations.
Then things become more interesting. Modern software is built from many pieces that go deep down to the machine code executed on your processor. What about the operating system? A runtime library that executes your code? They do not all need the same kind of supplier control, but they cannot simply disappear from the quality management system because nobody sends you an invoice labelled ‘medical device component’.
You as a manufacturer (usually) have no contract with the person maintaining an open-source library, and they are unlikely to respond kindly to an offer to sign your Supplier Quality Agreement. Calling them an 'approved supplier' does not magically create control. Open-source libraries are often abandoned; sometimes they are compromised. The answer is not to control your suppliers – often you simply can't. It is to control whether your dependency on them is soft or critical.
Supplier controls may sound scary – 'am I now responsible for all the bits and pieces that go into my product?' In reality, no one expects a startup to audit every one of its suppliers. What you can and must do is make sure you are not critically dependent on any of them – and only where the dependency is unavoidable do you need to worry about controlling the supplier.
The label doesn’t matter
Make no mistake: certificates and audits possess real value. However, when dealing with software, they should never serve as your starting point. Since direct control over many software dependencies is rarely attainable, the focus must shift to managing your level of exposure.
First: what exactly are we relying on this supplier to provide or do?
Second: what happens if they fail to meet that requirement, stop providing the service, or change it without telling us?
The answer may involve patient safety, clinical performance, availability, cybersecurity, data integrity, regulatory evidence or the manufacturer's ability to maintain the device – and this is the basis for supplier criticality. In layman’s terms, how stressed would you be if a software library is abandoned or suffers a compromise tomorrow?
ISO 13485 follows the same underlying logic. Supplier evaluation and selection criteria are based on the supplier's ability to meet requirements, the effect of what it supplies on device quality, and the risk associated with the device. Monitoring and re-evaluation then follow from that assessment.
This is also why a one-size-fits-all supplier process tends to become either excessive or useless. If your office furniture supplier delivers the wrong chair, that is irritating. If your cloud provider withdraws a security feature on which one of your risk controls depends, that is a different situation altogether. So you structure your supplier controls to be proportionate to risk, which often dramatically reduces the list of things you have to worry about.
A practical way to classify SaMD suppliers
There is no regulation requiring you to call suppliers ‘Category 1’, ‘Category 2p’ or anything else but some risk categories are helpful as an internal control mechanism.
At Hardian, we find categorisation useful because it forces you to decide how much control a supplier actually needs. Developing 4 sets of criteria and controls doesn’t just frontload the work – it reduces it.
Supplier categorization: practical meaning and SaMD examples Click to expand Click to collapse
| Category | What it means in practice | SaMD examples |
|---|---|---|
| Category 1 supplier (critical subcontractor or crucial supplier) | A crucial supplier or outsourced process with significant potential impact on product conformity, safety or performance | Product design and development (software implementation, software verification testing) |
| Category 2p supplier (non-critical subcontractor or non-crucial supplier) | The supplied product or process can affect the device, but is not assessed as critical | For SaMD, edge server or other commercial off the shelf (COTS) hardware installed at customer sites |
| Category 2s supplier (service supplier) | A service can affect quality, safety, performance, availability, cybersecurity or regulatory compliance |
|
| Category 3 (uncontrolled) supplier | No meaningful effect on device quality, safety, performance, cybersecurity or the QMS | General office services and similar business suppliers |
What does supplier qualification actually need to show?
Once you know what the supplier is doing and how much it matters, the rest becomes much easier. Before approval, you need enough evidence to conclude that the supplier can meet the requirements you have set for it.
For a software development company, that could involve its development processes, competence, previous medical device experience, QMS, cybersecurity practices and ability to produce the records you will eventually need. For a cloud service, very different evidence may matter: data locations, backup and recovery, security certifications, etc.
For software component or library suppliers, including open source projects, the license terms of use of the component must be compatible with the commercial and intellectual property protection aims of the SaMD manufacturer, and must not preclude use in the medical safety-critical context.
Some suppliers will be Data Processors under UK/ EU GDPR, or Business Associates under the US HIPAA Privacy Rule, so the appropriate controls need to be established with such suppliers.
The Approved Supplier List
It sounds like a lot of records to keep. Where do you keep them? An Approved Supplier List, or ASL, is a very useful way to maintain visibility into your supply chain. It is worth being precise here: an ASL is a practical QMS mechanism – MDR itself doesn’t require you to use.
In Hardian Core (eQMS), you will have an ASL to record the relevant controlled suppliers and their status, together with the associated Supplier Quality Agreements, Purchasing Specifications or Statements of Work. Much more convenient than doing it in Excel.
Your supplier agreement needs to cover the edge cases.
We all love it when everything is going according to plan. Quality agreements matter when life happens, and you want to make sure these are bulletproof and detailed. Any good lawyer would tell you that the primary value of a contract is not that it can enable you to sue but that it makes the parties agree on the expectations and edge cases in advance. It is tempting to save on legal fees and re-use a boilerplate agreement for all suppliers. It could work – but it’s not the best idea. What is usually the best idea is an agreement template with sections to be filled out. It forces you to think about the edge cases – but it’s easier and cheaper to work with than drafting from scratch.
ISO 13485 requires written quality agreements for outsourced processes within the scope of clause 4.1.5, and its purchasing requirements (clause 7.4.1) also call for purchasing information that defines the relevant specifications, acceptance requirements, personnel qualifications or QMS requirements as appropriate. For an important SaMD supplier, the agreement should leave as little ambiguity as possible about who is responsible for what. That normally includes the agreed deliverables, change management, access to records, handling of nonconformities, cybersecurity incidents, record retention, audit access, arrangements for PMS and vigilance, maintenance and support.
There is an important practical exception. As we remember, you don’t always have a practical and reasonable opportunity to negotiate an agreement with a supplier. One obvious case is open-source projects – you’re bound by whatever license the author chose. In many cases this license is MIT that says “THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND”. Not the sort of language that confidently says “I control my supply chain”. Another – arguably, opposite – case is the big suppliers. Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform (GCP) won’t rewrite their global operating model to accommodate requirements of a small account.
Document the terms and build your own controls if you can’t control them. Review the provider's standard terms and controls and then document how those terms satisfy the device's safety and cybersecurity requirements, together with any additional risk controls the manufacturer needs. It’s worth having a Supplier Quality Agreement in place with some key suppliers that deliver a tailored product to you, like agencies. With most other suppliers the better choice is to document and plan around whatever they promise.
Do you need to audit the supplier?
Sometimes.
ISO 13485 requires supplier control to be proportionate to risk. It does not prescribe one universal supplier audit frequency, and it does not require every supplier to receive the same type of audit. An audit is one way of obtaining evidence. If a company is performing a large part of your device development under your QMS and there is little independent evidence of its capability, an audit may be the most convincing way to establish control.
If you are buying a well-characterised commercial service from a large provider with strong independent assurance and limited ability to negotiate, a desk-based assessment combined with contractual and technical controls may give you better information.
The same thinking applies to re-evaluation. ISO 13485 requires planned monitoring and re-evaluation; it does not say every supplier has to be re-approved once every twelve months. The interval and method should make sense for the supplier's risk and performance. More importantly, do not wait for the calendar if something meaningful changes. A serious defect, security incident, loss of certification, acquisition, major platform change, new subcontractor or repeated failure to meet requirements may justify re-evaluation immediately.
Under Hardian categorisation suppliers that fall under Category 1 and 2p need to be audited.
Outsourcing software development deserves special treatment.
Suppose you contract a software company to build most of your SaMD. They may write the code. They may maintain the repositories. They may run the automated tests and manage the development environment. They sometimes end up being the only people who actually understand how your device works end-to-end.
Earlier on I’ve spent two sections talking about planning around suppliers when you can’t control them. Outsourced development may be just about that one thing you can never plan around. The only option with an external development team is proper controls.
Start with roles. Every activity in your software development plan (SDP) has to have a name against it – and 'the dev team' is not a name. You need to have an assigned person responsible for each step of the development process. Who writes the requirements? Who reviews them? Who decides that a unit test is sufficient? Who signs off the release? It’s a gap if you and your supplier have a different idea about any of these – or if your supplier is being vague about who does what – and gaps tend to surface at the worst possible time.
The supplier must be capable. A company that has never worked under the standards applicable to SaMD development (ISO 13485:2016, ISO 14971:2019, IEC 62304:2006+A1:2015, IEC 82304-1:2016, IEC 62366-1:2015) is unlikely to qualify to lead your engineering efforts. They may be very competent engineers but they also need to understand how medical device engineering works and what controls usually apply. Project management at smaller dev shops usually ends up at Jira – they can still be very capable in software engineering, but getting them to follow your documentation standards may be like pulling teeth.
You need to have a proper contract. A Supplier Quality Agreement is non-negotiable. One thing to be particularly mindful of is who holds the code and the provenance / history documents. The latter one is important and often not controlled enough. Ensure you have full access to Jira, Git repository (wherever hosted), Confluence and any other resources used in the development process. Ensure the supplier can’t revoke your access or corrupt the records. This can backfire catastrophically in case of a business dispute, especially with a supplier overseas.
For a company performing a significant part of SaMD design and development, this would normally place the supplier towards the highest-control end of our supplier categorisation (Category 1).
An ISO 13485 certificate can help, but do not stop there. External engineering is about the most critical supply chain dependency most startups have, and managing this dependency properly requires effort.
Supplier monitoring should tell you whether your original decision is still true
Qualification answers a question at a point in time: do we have enough evidence to trust this supplier for this particular purpose? Monitoring asks whether that answer still holds. What is watched depends on what the supplier does. Delivery defects may be a useful measure for a physical component supplier; for an outsourced software developer, the main concerns would be test quality, overdue corrective actions and adherence to change control. For a cloud provider, security incidents, major service changes and support status are the things to watch.
This is why a generic supplier scorecard or supplier qualification questionnaire borrowed from a hardware manufacturing company rarely works well for SaMD. The rule of thumb is to monitor the things that matter to the service. And if a supplier no longer meets the conditions on which it was approved, do something about it: a discussion, corrective action, tighter oversight, requalification, suspension or, eventually, replacement. All of which has to be demonstrable, which is the mundane but important final point.
A reviewer (or auditor) should be able to follow the story: what you needed; why the supplier mattered; how you classified the risk; what you required of them; why you decided they were capable; what agreement was established and how performance has been monitored.
Conclusion
SaMD does have a supply chain. It is simply less visible than the one attached to a physical device. The supplier may be holding your source code rather than your drawings. They may supply cloud capacity instead of components. They may provide a training dataset instead of raw materials.
The principle does not really change. Know what you are relying on. Decide what could go wrong. Put more control around the suppliers that matter most. Define responsibilities before the work starts. Make changes visible. And keep enough evidence to show why you continue to trust the supplier.
For outsourced software development in particular, remember that the development company can perform the work, but the manufacturer still needs to own the regulatory outcome.
At Hardian Health, we support SaMD and AI medical device manufacturers with supplier classification and evaluation, tools for Approved Supplier Lists, Supplier Quality Agreements, supplier audits and the integration of outsourced development into the manufacturer's QMS.
Need help with supplier management? Get in touch with the expert Hardian team.
