ISO 14971 hazard identification and IEC 62304 software item architecture documentation covering functional data flows and component interactions.
Threat model with twelve required elements including physical ports, JTAG/debug headers, external dependencies, and hardware attack vectors — annually reviewed for released products.
Threat model currency and physical interface coverage — models limited to software-layer threats without hardware attack vectors and debug port enumeration are a major submission gap.
Maps to
IEC 81001-5-1: §7.2 Identification of VULNERABILITIES, THREATS and associated adverse impacts
IEC 62443-4-1: §TM-1
Requirement text
Identify and document vulnerabilities, threats, and adverse impacts on confidentiality, integrity, and availability. All products shall have a threat model including: a) correct flow of categorized information, b) trust boundaries, c) processes, d) data stores, e) interacting external entities, f) internal and external communication protocols, g) externally accessible physical ports including debug ports, h) circuit board connections (JTAG, debug headers), i) potential attack vectors including hardware, j) potential threats, k) security-related issues, l) external dependencies (drivers, third-party apps). The threat model shall be reviewed by the development team and reviewed periodically (at least annually) for released products. Issues shall be addressed per 9.4 and 9.5.
Why this clause exists
Threat and vulnerability identification is the intellectual core of the security risk management process — the stage at which the security engineering team must reason about adversarial intent and capability, not just system failure modes. Safety risk management identifies hazards through failure mode analysis; security risk management must additionally ask who would want to cause harm, how they might do it, and whether the system's design makes that easier or harder. Without a structured methodology — STRIDE, PASTA, LINDDUN, or an equivalent framework applied to a data flow diagram — threat identification defaults to brainstorming, which is inconsistent, team-knowledge-dependent, and produces gaps in coverage that only become visible when an unidentified threat is later exploited. IEC 81001-5-1:2021 clause 7.2 requires structured threat and vulnerability identification using a recognized methodology applied to the product's security context. The SBOM is the vulnerability identification input: by cross-referencing the SBOM against public vulnerability databases, known vulnerabilities in third-party components are identified systematically rather than discovered reactively.
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)
- Threat identification limited to a single methodology — Organizations use only one threat identification method (typically STRIDE or informal brainstorming) without cross-referencing with attack libraries (MITRE ATT&CK), vulnerability databases, or medical device-specific threat catalogs. MITRE's Medical Device Playbook recommends combining multiple techniques.