IEC 62304 §9.1 problem reporting and ISO 13485 complaint handling processes already receiving and tracking product issues from multiple sources.
Published vulnerability intake channel (CVD policy), PSIRT-style tracking covering seven defined source categories including security researchers and audit log indicators.
Published CVD policy with intake channel and vulnerability tracking records from all source categories — security issues routed through complaint handling without a dedicated intake are a major gap.
Maps to
IEC 81001-5-1: §9.2 Receiving notifications about VULNERABILITIES
IEC 62304: §9.1 Prepare problem reports
Requirement text
Enable reporting of vulnerabilities to the manufacturer from internal and external entities or via complaint handling. Receive and track to closure reports from: a) security verification and validation testers, b) third-party component suppliers, c) product developers and testers, d) product users (integrators, operators, administrators, maintenance personnel), e) audit event log information, f) security researchers (vulnerability reporters), g) data and notifications about widespread vulnerabilities (per 6.2).
Why this clause exists
Manufacturers who have no formal mechanism for receiving vulnerability notifications from external parties — security researchers, operators, healthcare information sharing and analysis organizations — will systematically learn about vulnerabilities in their products later than organizations that have established intake channels. External vulnerability reporting is a complementary source of intelligence to the proactive monitoring required by clause 6.2.1: monitoring catches vulnerabilities in components by cross-referencing the SBOM; external notifications identify vulnerabilities that arise from the specific product implementation, integration, or deployment — vulnerabilities that only someone who has encountered the product in context might discover. IEC 81001-5-1:2021 clause 9.2 requires that the manufacturer establish a formal mechanism for receiving vulnerability notifications, which is the same requirement expressed in the coordinated vulnerability disclosure (CVD) policy referenced in clause 4.1.7 and explicitly expected by FDA premarket cybersecurity guidance. The two requirements are complementary: clause 4.1.7 defines the disclosure obligation outward to regulators and users; clause 9.2 defines the intake mechanism inward from external reporters.
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)
- No designated intake channel for vulnerability reports — Manufacturers have no published mechanism (security.txt, dedicated email, web form) for external parties to report vulnerabilities. Reports arrive through customer support where they are triaged as product complaints, not security issues, causing delays.