ISO 13485 product scope documentation and software item inventory from IEC 62304 software development planning.
Formal per-product applicability determination for the secure lifecycle, with documented criteria and threat-based assessment of connectivity and data sensitivity.
Applicability register or SBOM annotating each product’s in-scope determination — undocumented assumptions about scope are a common gap area.
Maps to
IEC 81001-5-1: §4.1.3 Identification of applicability
Requirement text
The manufacturer shall identify which products or parts of products the secure life cycle applies to. This is about product types and their components (e.g., software items), not individual product instances.
Why this clause exists
Applicability scoping failures take two forms: over-inclusion — applying the full secure lifecycle to software items that have no security implications — or, more dangerously, under-inclusion — assuming that a medical device's embedded software is not 'networked enough' to warrant security lifecycle governance. The under-inclusion failure is the historically harmful one. Devices with no user-visible network interface have frequently contained Bluetooth stacks, JTAG debug interfaces, or firmware update mechanisms that create exploitable attack surfaces. IEC 81001-5-1:2021 clause 4.1.3 requires a documented, criteria-based determination — not an assumption — of which products and software items are subject to the secure lifecycle, precisely because the assessment must survive scrutiny on audit. The ISH1:2025 interpretation sheet further emphasizes that the determination should be made at the product-type level, not per individual instance, creating a durable record that covers product families. FDA inspectors reviewing 510(k) cybersecurity submissions frequently find that manufacturers have not performed this scoping exercise at all, treating security lifecycle compliance as a documentation overlay rather than a genuine risk-based applicability determination.
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)
- No documented applicability determination per product — Manufacturers fail to document which products and software items are subject to the secure lifecycle. The determination of applicability is assumed rather than formally assessed through threat modeling and documented with explicit inclusion/exclusion rationale.