ISO 13485 §7.4 supplier qualification, quality agreements, and purchasing controls already in place for component suppliers.
Security lifecycle obligations flow-down to custom-developed third-party software items, with contractual requirements for threat modeling, vulnerability management, and security evidence.
Supplier quality agreements for custom-software vendors — absence of security lifecycle clauses is a major non-conformity, especially for cloud service integrations.
Maps to
IEC 81001-5-1: §4.1.5 SOFTWARE ITEMS from third-party suppliers
ISO 13485: §7.4 Purchasing
Requirement text
The manufacturer shall ensure that third-party suppliers perform applicable security life cycle activities for each software item that is: (a) mainly developed specifically for the manufacturer and for a specific purpose, AND (b) can have an impact on security. The manufacturer shall communicate security requirements to such third-party suppliers.
Why this clause exists
Supply chain blindness is a persistent and structurally predictable failure mode: a manufacturer builds a compliant secure development process for its own code while the highest-risk components — custom-developed modules from contract engineering firms or specialized software vendors — are developed under no security lifecycle obligations at all. The manufacturer's SBOM lists these items; the manufacturer's threat model references their interfaces; but the development process that produced them has never undergone threat modeling, never applied secure coding standards, and has no vulnerability management discipline. IEC 81001-5-1:2021 clause 4.1.5 closes this gap with a targeted obligation: when a third-party software item is developed specifically for the manufacturer and can have a security impact, the manufacturer must both communicate security requirements to the supplier and ensure the supplier performs applicable security lifecycle activities. The standard deliberately limits this to custom-developed items — COTS software items are handled through SBOM classification and monitoring — but the custom-development pathway is where the greatest unmanaged risk concentrates, because generic IT vendor assessments do not interrogate medical-device security lifecycle activities.
What changed
IEC 81001-5-1:2021 is the first standalone cybersecurity standard purpose-built for health software and medical device software. Published in December 2021, it was adapted from IEC 62443-4-1 (industrial control systems security) to address the unique safety and regulatory context of medical devices — adding health-specific requirements that account for patient safety, clinical workflows, and the manufacturer-HDO relationship.
The standard mirrors IEC 62304's lifecycle structure but adds security-specific activities at every phase — planning, development, testing, release, and maintenance. It requires security risk management to be integrated with ISO 14971 safety risk management, not treated as a separate IT concern. FDA formally recognized it as Consensus Standard 13-122 on December 19, 2022 and references it as providing one acceptable framework for satisfying the cybersecurity requirements of Section 524B(b)(2), which requires manufacturers to design, develop, and maintain processes and procedures to provide a reasonable assurance that cyber devices and related systems are cybersecure.
EU MDR harmonization was originally targeted for May 2024 but postponed to May 2028. Despite this delay, Notified Bodies and Competent Authorities universally recognize it as "state of the art" for health software cybersecurity under MDR GSPR Annex I, Section 17.2. Missing or inadequate cybersecurity documentation is already a top cause of Notified Body major non-conformities for SaMD. A December 2025 Interpretation Sheet (ISH1:2025) clarified software item classification into maintained, supported, and required software categories, affecting risk transfer and post-market obligations.
Common gaps (what we see in audits)
- Supplier security evaluation missing or superficial — Manufacturers rely on supplier self-assessments or ISO 27001 certificates without evaluating whether suppliers' security practices are adequate for the specific software components supplied. Cloud providers (AWS, Azure) are qualified as standard OTS suppliers without assessing their security-specific Shared Responsibility Model or uptime/patching SLAs.