Maps to
IEC 81001-5-1: §5.4.3
Requirement text
The health software design shall identify and characterize each interface of the health software including physical and logical interfaces. As appropriate, the manufacturer identifies as part of the design: a) whether the interface is externally or internally accessible; b) security implications of the health software security context on the external interface; c) potential users of the interface and the assets accessible through it; d) whether the static design includes access across trust boundaries; e) security considerations, assumptions and/or constraints including applicable threats; f) security roles, privileges/rights and access control permissions; g) security capabilities and/or compensating mechanisms to safeguard the interface including run-time validation of inputs and error handling; h) use of third-party software items for the interface and their security capabilities; i) documentation for externally accessible interfaces; and j) description of how the design mitigates threats from the threat model.
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 64 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-112 in December 2022 and references it as providing a framework for the Secure Product Development Framework (SPDF) required by Section 524B.
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.
Atomic constraints
- •All interfaces (physical and logical) must be identified and characterized in the design.
- •External vs. internal accessibility must be documented for each interface.
- •Security implications of the security context on external interfaces must be documented.
- •Potential users and accessible assets for each interface must be documented.
- •Access across trust boundaries must be identified.
- •Security considerations, assumptions, constraints, and applicable threats must be documented per interface.
- •Security roles, privileges, and access control permissions must be documented per interface.
- •Security capabilities and input validation/error handling mechanisms must be documented per interface.
- •Third-party software items used for interfaces and their security capabilities must be documented.
- •Documentation for externally accessible interfaces must be provided.
- •How the design mitigates threat model threats at each interface must be described.
Common gaps
Interface security requirements incomplete
majorExternal interfaces (APIs, network protocols, user interfaces, removable media ports) are designed for functionality without specifying security requirements for each interface — authentication, authorization, encryption, input validation, and rate limiting. FDA states all interfaces must be enumerated as potential attack surfaces.
Evidence signals
- •
FILE_EXISTS
Interface.*Design|Interface.*Specification|Security.*Interface|API.*Security|Interface.*Control
- •
CONTENT_MATCH
Does this document characterize all health software interfaces identifying their accessibility, trust boundary crossings, security roles, input validation, access controls, and how each interface mitigates threats from the threat model?
Audit defense
The Interface Design specification for [your product] (Doc ID: [your document ID]) characterizes all physical and logical interfaces across all ten required dimensions per clause 5.4.3, including trust boundary analysis, access controls, and traceability to threat model mitigations.