ISO 13485 design review process and IEC 62304 architectural review covering functional correctness and component interfaces.
Formal security architectural review covering software item segregation, secure design best practices from 5.3.2, and security flaws introduced by the architecture itself, with findings actioned.
Architectural review record with security-qualified reviewer participation — reviews by development teams alone without independent security expertise do not satisfy the intent.
Maps to
IEC 81001-5-1: §5.3.3 SECURITY architectural design review
Requirement text
The manufacturer shall implement an architectural review of the health software with respect to behavior under adverse conditions, covering: a) effective segregation of software items; b) the secure design best practices (see 5.3.2); and c) potential security flaws introduced by the architecture. The manufacturer shall document and implement the architectural design review.
Why this clause exists
Architectural security decisions — the choice of trust boundaries, the design of authentication flows, the selection of encryption mechanisms, the partitioning of privilege levels — are difficult and expensive to reverse after implementation begins. A security architectural design review is the gate at which security expertise is applied to these decisions before they become embedded in code. Organizations that rely on penetration testing to identify architectural security weaknesses systematically incur two costs: the cost of implementing the wrong architecture in the first place, and the cost of redesigning or mitigating architectural problems discovered late. IEC 81001-5-1:2021 clause 5.3.3 requires a formal review of the security architectural design by personnel with appropriate security expertise, positioned before detailed design and implementation begin. The review must evaluate whether the architecture implements the defense-in-depth and secure design principles required by clauses 5.3.1 and 5.3.2, and whether it adequately addresses the threats identified in the threat model. The independence of the reviewer from the design team — or at minimum the requirement for demonstrated security expertise — prevents the review from being a formality performed by the designers on their own work.
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)
- Architecture review lacks independent security perspective — Architectural design reviews are conducted by the development team without participation from personnel with security expertise. Reviews focus on functional correctness and performance rather than resistance to attack.