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: §SR-2
Requirement text
Identify and document vulnerabilities, threats, and adverse impacts on confidentiality, integrity, and availability. All products shall have a threat model with the following characteristics (where applicable): 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 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)
- 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.