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 recognized it as Consensus Standard 13-122 (date of entry December 19, 2022). FDA's February 2026 cybersecurity guidance, Section V, lists IEC 81001-5-1 among the "possible frameworks to consider" for secure product development, and FDA's recognition record for the standard notes that conformance "may not satisfy all the cybersecurity requirements outlined in Section 524B of FD&C Act".
EU MDR harmonization was originally targeted for May 2024 but postponed to May 2028.
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.